Good article. I think I can sum up its main points as:
Non-AMM (automatic memory managed) languages (C, Rust) are good for a particular class of problems. Outside that class, and with increased complexity, they become unmanageable.
The space of systems programming used to be just C, but now AMM languages are moving into systems programming because of availability and maturity.
The systems space will bifurcate into hard realtime (handled by Rust and C) and “other” which will be Go and other AMM systems programming languages.
As /u/singpolyma writes correctly, Rc and Arc are strictly library concerns outside of the language core. Several pieces of software (e.g. Servo) use their own versions of them.
The interesting thing here is that both Rc and Arc are managed through Rusts static memory management (they are handles, which work through ownership and dropping).
Data sharing is always a concern of any programming environment, be it manually or automatically managed. What Rcs are there for in Rust is multiple immutable ownership.
Sure, but does it change anything? Shared ownership of memory is not handled by borrow checker/at compile time. Don’t get me wrong - I like rust and use it but calling it “compile-time garbage collection” is not correct - but might be nice PR move ;)
Yes, it is. The potential allocation and de-allocation points are quite precise and handled by Ownership. Any situation of shared ownership must be dynamic and thus be evaluated at runtime, but the language handles acquiring and removing handles from memory for you transparently.
One of the issues here is that “garbage collection” isn’t a rigorously defined term, so anyone claiming that there is such a thing as static garbage collection is just as right as people that say such a thing doesn’t exist.
With most people using it and attaching meaning to it in some form or the other, I couldn’t care less about that distinction.
You don’t care about what you mean when you say that rust has “compile-time garbage collection”? What is this - Rust Evangelism Strike Force? ;)
If we are talking about compile time guarantees for resource reclamation than there is very little difference between rust and modern c++ and I don’t see people saying that c++ has “compile time garbage collection”. Moreover just like in c++, you can easily leak memory in rust. In fact it is considered safe to leak memory (either via (A)Rc cycles or mem::forget) in safe rust.
Dont forget Ada and Real-Time Java used in embedded scene for some time now. Groups like Aonix supplied JVM’s and such for hard, real time. On both ends, they had “profiles” that constituted different levels of functionality so one could trade determinism against power/performance.
I’m no C++ maven, but is memory management THAT much of a problem in C++11 and beyond? I get that you COULD write code that has you micro-managing memory, but you could pretty easily write code that doesn’t need it. C++ gives you that option.
I have very, very little experience with Common Lisp but I’ve had bad experiences with garbage collection in it and with Haskell.
Python’s big attraction was it’s syntax and module system. C++14 and later (with auto and ranged for loops for vectors and maps and custom types) has pleasant enough syntax for the simple things I do. Python’s multiprocessing is … involved … while C++ threading has gotten a little simpler. And nowadays Python’s speed becomes an issue for me very quickly.
I do miss the module system - for example, to read a YAML file I have to do much more in C++ than Python has gotten me expecting to.
However, when I experimented with Common Lisp I really did not see that much of an advantage. For an older language it has many cool concepts, but Python has made me used to that. I realize “Macros!” but that just seems like obfuscation - if I got into Macros a lot I can easily see myself confusing the future me with my code in a way that regular function or class based code would not.
Any how, I appreciate Greenspun’s law, but I do think it’s a little bit, ok, I’ll say it, pretentious.
Any how, I appreciate Greenspun’s law, but I do think it’s a little bit, ok, I’ll say it, pretentious.
Hmm.. maybe, but let’s consider the state of the world in 1993 when the quote originated:
C89/90 is just a few years old.
C++ is 10ish years old.
Common Lisp is 9 years old, on the way to an ANSI standard
Perl has been around for 6 years (and not widely adopted yet)
Lua is just introduced (1993)
PHP, Ruby would come 2 years later in 1995
Python version 1 still didn’t happen (1994)
TCL was a popular scripting language, 5 years old.
Java wouldn’t be for 2 more years
JavaScript is 2 years away.
Haskell existed, but was essentially a research language.
The rest of the functional world, ML, SML, Caml were academic mostly
So, almost all of the (now) commonly used garbage collected languages hadn’t even been invented yet, and there’s years of the precursors to Common Lisp, and Common Lisp on the horizon – this great philosophical and amazing piece of kit, that has super special powers, first class functions, garbage collection, conditions and restart, proven uses in AI research (even though the AI winter happened), and the things that win out are the far inferior and unsafe C and C++ because of the rise of Unix?
Maybe someone with more accurate history can paint a prettier picture, but I think the observation was certainly timely, even if it’s continued usage isn’t as relatable to today’s audience.
I’d argue that it’s usage shouldn’t be that unrelatable today. Common Lisp is still quite competitive with pretty much any modern language. Meanwhile, many languages are still playing catch up with it.
Absolutely agree that CL is still relevant and the original argument holds. The pure fact of matter, though, is that there are many, more in vogue languages, for which the argument would be almost as effective, and therefore more broadly appliable. “… implementation of JavaScript”, or “… Ruby,” would certainly be somewhat valid as there are obviously distinct advantages that programmers of those languages understand.
To a large population, Common Lisp equates to, ancient AI “stuff”, “Lots of Infuriating, Superfluous Parens,” C style pre-preprocessor macros (of course they are misinformed), and first class functions. Surely, JavaScript is better even without those stupid macros that I don’t need anyway!
I think the reason you end up putting CL into C is because the expressiveness gap is so huge you need to implement a language to get anywhere.
I can see the argument for CL being still really better than other languages, but modern languages nowadays solve a lot of the problems that C had. Even extremely basic things in C end up requiring macros. Meanwhile in Python I have metaclasses.
I’m no C++ maven, but is memory management THAT much of a problem in C++11 and beyond?
Some of the comments are back-and-forth between ESR and a proponent of C++17. From the few I read, it seems like there’s a generational gap between understandings of what is modern C++. (ESR says he last used C++ in 2009, on a project whose codebase started in 2003, and he calls that “modern C++” in the comment…)
Good article. I think I can sum up its main points as:
Seems like a decent prediction.
my take is memory management is a lot more automatic in rust than in C
I’ve seen it referenced as compile-time garbage collection in papers.
That’s a really neat way of putting it. I’ll have to think on that more if I learn Rust later.
Which is not correct, since rust still provides ref counted pointers Rc/Arc.
As /u/singpolyma writes correctly, Rc and Arc are strictly library concerns outside of the language core. Several pieces of software (e.g. Servo) use their own versions of them.
The interesting thing here is that both Rc and Arc are managed through Rusts static memory management (they are handles, which work through ownership and dropping).
Data sharing is always a concern of any programming environment, be it manually or automatically managed. What Rcs are there for in Rust is multiple immutable ownership.
what is the version used by servo exactly (is there some documentation somewhere ?)
“provides” in a library
Sure, but does it change anything? Shared ownership of memory is not handled by borrow checker/at compile time. Don’t get me wrong - I like rust and use it but calling it “compile-time garbage collection” is not correct - but might be nice PR move ;)
Yes, it is. The potential allocation and de-allocation points are quite precise and handled by Ownership. Any situation of shared ownership must be dynamic and thus be evaluated at runtime, but the language handles acquiring and removing handles from memory for you transparently.
One of the issues here is that “garbage collection” isn’t a rigorously defined term, so anyone claiming that there is such a thing as static garbage collection is just as right as people that say such a thing doesn’t exist.
Deallocation points are handled by runtime tracked reference count. Almost exactly like raii in c++.
I can agree that term “garbage collection” is vague. But this means that using it is pointless and devoid of any clear meaning.
I wrote about potential points, and those are static.
Also, they happen at runtime, but not through a linked runtime system, which is usually what people care about.
Hand-rolled ref-counted pointers in C have very similar semantics.
With most people using it and attaching meaning to it in some form or the other, I couldn’t care less about that distinction.
You don’t care about what you mean when you say that rust has “compile-time garbage collection”? What is this - Rust Evangelism Strike Force? ;)
If we are talking about compile time guarantees for resource reclamation than there is very little difference between rust and modern c++ and I don’t see people saying that c++ has “compile time garbage collection”. Moreover just like in c++, you can easily leak memory in rust. In fact it is considered safe to leak memory (either via (A)Rc cycles or mem::forget) in safe rust.
I had that issue with his terminology too.
Dont forget Ada and Real-Time Java used in embedded scene for some time now. Groups like Aonix supplied JVM’s and such for hard, real time. On both ends, they had “profiles” that constituted different levels of functionality so one could trade determinism against power/performance.
I wonder if ARC is good enough for the kinds of programs Raymond is discussing.
I will bet that rust will be conviennent for a lot further scope than C or C++. it is really pleasant to play with for a beginner
Some people in the comments ask for a better C garbage collector than Boehm–Demers–Weiser. We already have one in GCC - the one used for the Go backend (yes, it is exposed to C programs if you’re willing to run the whole gccgo runtime): https://github.com/stefantalpalaru/golib/blob/032223293d8e0d8688a8245836e182e9b29eb419/src/utils.c#L126
And the price to pay is launching the runtime in main(): https://github.com/stefantalpalaru/golib/blob/032223293d8e0d8688a8245836e182e9b29eb419/benchmarks/cw-c.c#L83
(and using another function as your main function: “go_main()”)
I’m no C++ maven, but is memory management THAT much of a problem in C++11 and beyond? I get that you COULD write code that has you micro-managing memory, but you could pretty easily write code that doesn’t need it. C++ gives you that option.
I have very, very little experience with Common Lisp but I’ve had bad experiences with garbage collection in it and with Haskell.
Python’s big attraction was it’s syntax and module system. C++14 and later (with
autoand ranged for loops for vectors and maps and custom types) has pleasant enough syntax for the simple things I do. Python’s multiprocessing is … involved … while C++ threading has gotten a little simpler. And nowadays Python’s speed becomes an issue for me very quickly.I do miss the module system - for example, to read a YAML file I have to do much more in C++ than Python has gotten me expecting to.
However, when I experimented with Common Lisp I really did not see that much of an advantage. For an older language it has many cool concepts, but Python has made me used to that. I realize “Macros!” but that just seems like obfuscation - if I got into Macros a lot I can easily see myself confusing the future me with my code in a way that regular function or class based code would not.
Any how, I appreciate Greenspun’s law, but I do think it’s a little bit, ok, I’ll say it, pretentious.
Hmm.. maybe, but let’s consider the state of the world in 1993 when the quote originated:
So, almost all of the (now) commonly used garbage collected languages hadn’t even been invented yet, and there’s years of the precursors to Common Lisp, and Common Lisp on the horizon – this great philosophical and amazing piece of kit, that has super special powers, first class functions, garbage collection, conditions and restart, proven uses in AI research (even though the AI winter happened), and the things that win out are the far inferior and unsafe C and C++ because of the rise of Unix?
Maybe someone with more accurate history can paint a prettier picture, but I think the observation was certainly timely, even if it’s continued usage isn’t as relatable to today’s audience.
I’d argue that it’s usage shouldn’t be that unrelatable today. Common Lisp is still quite competitive with pretty much any modern language. Meanwhile, many languages are still playing catch up with it.
Absolutely agree that CL is still relevant and the original argument holds. The pure fact of matter, though, is that there are many, more in vogue languages, for which the argument would be almost as effective, and therefore more broadly appliable. “… implementation of JavaScript”, or “… Ruby,” would certainly be somewhat valid as there are obviously distinct advantages that programmers of those languages understand.
To a large population, Common Lisp equates to, ancient AI “stuff”, “Lots of Infuriating, Superfluous Parens,” C style pre-preprocessor macros (of course they are misinformed), and first class functions. Surely, JavaScript is better even without those stupid macros that I don’t need anyway!
I think the reason you end up putting CL into C is because the expressiveness gap is so huge you need to implement a language to get anywhere.
I can see the argument for CL being still really better than other languages, but modern languages nowadays solve a lot of the problems that C had. Even extremely basic things in C end up requiring macros. Meanwhile in Python I have metaclasses.
As always, it’s really up to your opinion. I can say that some of us consider it enough of a problem that we built Rust. YMMV :)
Some of the comments are back-and-forth between ESR and a proponent of C++17. From the few I read, it seems like there’s a generational gap between understandings of what is modern C++. (ESR says he last used C++ in 2009, on a project whose codebase started in 2003, and he calls that “modern C++” in the comment…)
C++ is THAT much of problem in C++11 and beyond