Comment by cogman10 | Hacker News Reader

Comment by cogman10 | Hacker News Reader

Parent Full thread

> C language toolchain

I'm sorry, but the C language toolchain is not great. The only part of the C language toolchain that is good is it's platform support. Every platform has a C compiler.

However, that's hardly something most devs will care about. At this point, we are pretty much all targeting Arm or x86 (Sorry PIC and MIPS devs). And every new language that's cropped up at a minimum supports both those platforms and the major OSes for those platforms.

So once you dismiss that point, what are you left with? Tools for catching memory leaks? Well, sorry, but pretty much every language has those tools and better. Particularly GCed languages. Profiling tools? Debug tools? To say the C debug tools are "good" is to say you've not used any other toolchain.

But let's also point out C's horror story that is "dependency management and building". How do you grab dependencies for and build javascript? npm install, npm build. How about C? Well... are you using auto tools? Cmake? Ninja? Scion? makefiles? etc... Oh, and how do you get dependencies? Well, hope you like reading readme files and decipher cryptic "symbol not found xyz" compiler errors.

Suffice it to say C's toolchain isn't anything to be proud of. It's a relic of the 70s that to this day gets in the way because the community has practically given up on the idea of fixing the glaring issues (Too hard, everything already depends on X working the way X does).

So why risk switching languages? Well, because the C toolchain is a dumpster fire and you likely aren't trying to write new code for IBM RPG servers.

> trying to write new code for IBM RPG servers

Hey, I know that! Challenge accep... Eeeeh, nevermind.

All the modern AS/400 servers can run unmodified AIX programs these days anyway.

You keep enumerating words that I will never put in my CV lest employers know that I have been paid to suffer at their contact.

> I'm sorry, but the C language toolchain is not great. The only part of the C language toolchain that is good is it's platform support. Every platform has a C compiler.

Please take a few days to review John Regehr’s excellent blog. I’m certain that you’ll find dispelling your ignorance rewarding.

> How do you grab dependencies for and build javascript? npm install, npm build.

Npm is the poster child for supply chain attacks.

> Please take a few days to review John Regehr’s excellent blog.

Haven't heard of him but will certainly give a read. Thanks for the heads up.

> Npm is the poster child for supply chain attacks.

The only reason C doesn't (often) have similar supply chain attacks is because pulling in dependencies is so hard that you aren't likely to end up with a 10k dependency project.

Hard to say that's really a plus.

Other ecosystems have their own problems and certainly aren't perfect. However, the toolchains are generally leaps and bounds ahead of what C currently has.

> you aren't likely to end up with a 10k dependency project.

> Hard to say that's really a plus.

I'll definitely call that a plus. All dependencies introduce risk. Sure, we can't avoid all dependencies, but carefully evaluating them and keeping the list small is a big win for maintainability and security.

If a random library has a 0.1% chance of having malicious code (I'd say it's more like 1%, but let's be generous), a 10K-dependency program is guaranteed to be pulling in at least something malicious.

>The only reason C doesn't (often) have similar supply chain attacks is because pulling in dependencies is so hard that you aren't likely to end up with a 10k dependency project.

Or the lack of canonical package manager means the developer has to actually spend time to inspect the quality of each dependency instead of `npm install is-odd`ing like there is no tomorrow.

It also acts as a "filter" to prevent adding complexity to the dependency tree.

They will do `apt-get install is-odd` instead, or yum, pacman, or...

I do most of my heavy lifting with Git commit hashes via FetchContent and it's been pretty good to be fair, surprising number of well written CMakeLists in popular lib repos.

> Please take a few days to review John Regehr’s excellent blog. I’m certain that you’ll find dispelling your ignorance rewarding.

Just a heads up, this reads to me as condescending.

> Please take a few days to review John Regehr’s excellent blog. I’m certain that you’ll find dispelling your ignorance rewarding.

I regularly read his blog and I found nothing to back you up. He mostly work on a generic compiler toolchain (LLVM) other than C-specific tools and his work easily translates to many other languages using LLVM. And even a rare C-specific tool like C-Reduce is not that hard to adapt for other languages; C-Reduce is actually language-agnostic and works well for many other curly-brace languages as well.

Good eye. I might add: the blind praise of garbage collection, and the "symbol not found xyz" bit raised an eyebrow for me.

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.

> 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.

Reply on news.ycombinator.com