💾 Archived View for yujiri.xyz › software › c.gmi captured on 2022-07-16 at 14:29:00. Gemini links have been rewritten to link to archived content

View Raw

More Information

⬅️ Previous capture (2022-06-03)

➡️ Next capture (2023-01-29)

-=-=-=-=-=-=-

yujiri.xyz

Software

Against C

There are 2 different forms of this argument:

Many of my arguments against C apply to both cases, hence why I treat them together here.

C is weak

Many on the internet resist the very concept of vertical comparisons between languages. They insist choosing a language is always a matter of taste or use case. But there is a vertical dimension here. Paul Graham's essay Beating the Averages has a great explanation of this point, under "The Blub Paradox", but in summary: the relationship between a high-level language and C is of the same kind as the relationship between C and assembly.

Beating the Averages

There are even other low-level (ie. manual memory mamagement) languages that are much more powerful than C while being nearly as *simple*, such as Zig and Hare (albeit those aren't really production ready yet, I have a lot of hope for them).

C is unreadable

Something that isn't brought up enough is that C has unreadability built into the very standard in a way that no other language does. C stdlib functions have spectacularly inscrutable nomenclature; some highlights:

The harm of such nomenclature is well understood by any experienced programmer.

C is hard to build

C and C++ projects are absurdly difficult to compile. There are many different "build systems" in common use so there's no standard way to compile a project, and even on a mainstream Linux distribution, you almost always have to debug a series of platform-dependent errors about not being able to find libraries or header files or the wrong build tool flags. A story I always share when this topic comes up is of my GTK patch that fixed a GObject Introspection annotation: I spent *12 hours* trying to get GTK to compile, until I gave up and submitted the patch without having seen a successful build. It got merged. That should be terrifying.

Build systems are a scourge

Because the C language has no real concept of a dependency or import, this is a problem with the language itself, not just the ecosystem.

In Rust or Go, you run `cargo build` or `go build` and that's *it*. I have never had any significant difficulty building a project in those languages.

C puts bugs in the lap of the user

This one has been beaten to death by Rust advocates, but I inculde it here just for completeness. Because of not only C's propensity for memory safety bugs, but also the approach it takes to handling errors (silently ignore unless explicitly handled) it is much more likely that bugs end up in the lap of the user rather than the developer (and thus, ultimately back in the lap of the developer but harder to debug).

The C spec is proprietary

The C spec documents are copyrighted by ISO. Yes, the practical importance is very low because there's lots of third-party documentation about C and the implementations are free, but it is simply offensive.

What inspired me to mention this was the Hyperbola devs arguing that Rust has "freedom flaws" (in summary, it's trademarked in a way that prohibits forking it without rebranding it):

https://wiki.hyperbola.info/doku.php?id=en:philosophy:rust_trademark

And they're spot on, that's offensive too and a good reason to not use Rust. But also like the C issue, its practical importance is very low (how likely is it that anyone would *seriously* fork Rust?), so I point this out because I think that if you (like me) consider it a good reason to not use Rust, you should also consider it a good reason to not use C.

Arguments for C

It would only be fair to consider the reasons to use C as well.

Portability

C can be written for *any* platform - any combination of operating system and CPU architecture, no matter how obscure. Every other language has platforms it doesn't support, and most of them have really important omissions like Plan 9.

However. From the perspective of "what language should I write this project in", there aren't actually that many projects where this even matters. Most end-user applications don't support more than a couple platforms anyway because they depend on platform-specific interfaces like window systems.

And as for Plan 9: the entire system is so different that any significant C program is not likely to work without porting or emulation anyway.

ABI

Abiopause

The argument is roughly "any program that's going to interface with code from other languages must speak the C ABI, and providing such an ABI from a high-level language is a cost - you must write extra, unidiomatic code".

This is a valid issue, but is mostly only relevant for libraries, not applications. Application code is not going to be used from another language.

Performance

Other compiled languages are fast, and for most things, the difference between a fast language and a very fast language is just not a priority. After all, it probably could be even faster if you wrote it in assembly, but I don't see many people doing that, even for performance-critical things like OS kernels.

contact

subscribe via RSS