> i might add the blind praise of garbage collection raised an eyebrow for me.
Like it or not, a problem C has is that it's pretty much impossible to determine why a piece of memory is currently being retained. Tools like valgrind and jemalloc can give you good starting points but really can't point to issues where "This memory is being retained because of this linked list over here"
Languages with GCs can, at any point, dump the heap and provide tools for analyzing that heap to point to the exact reason why a bit of memory is currently being retained.
That's not really "blind" praise of GCed languages, simply a fact of how they operate.
You’re not wrong that aliasing presents serious practical problems for building an efficient object graph. The thing is the defining characteristic of a C-like is that it has an ultra lightweight runtime[1]. The way I look at it, every C program has a bespoke garbage collector of variable quality. It’s fair to say the median is pretty dismal sure, but tooling does exist to tame that beast.
I think there’s a wide open research space to work on taming the aliasing problem. There are PhDs to be had, and maybe even Turing awards.
[1] C gets to cheat a little bit here because Unix and friends are its runtime.
> he thing is the defining characteristic of a C-like is that it has an ultra lightweight runtime
Agreed. And with my critique of the toolchain, I didn't mean to imply that C isn't a reasonable choice in many situations. But rather, holding up the C toolchain as a reason to pick C over an alternative isn't reasonable in my opinion.
In particular, because a lot of C alternatives piggy back on the C ecosystem by using LLVM as a backend. So you end up with a superset of tools. The C alternative ecosystem and the C ecosystem.
Pick C if it's all that's available. Pick it if you plan on distributing your app/lib onto that IBM RPG server. Pick it if your software is already written in C. Pick it if your software is a simple app that runs for 1 second then shuts down (and it isn't really mission critical). Pick it if memory safety isn't really a problem. Pick it if that ultra thin runtime is an absolute necessity. Pick it if you have a bunch of C devs that don't want to learn a new language.
But don't pick it because you are afraid new languages won't have something as good as valgrind or gdb. Any semi-popular language born in the last 20 years (that wasn't written yesterday) will almost certainly have better tooling than C.
You can't trust HN comments. Most of them sound good to laymen. But to a trained eye, it's a comment tree of cards.