Not a summary, but a quote from the text itself that happens to be somewhat free of rhetorics :
You might ask, “Why would someone write code in a grotesque language that exposes raw memory addresses? Why not use a modern language with garbage collection and functional programming and free massages after lunch?” Here’s the answer: Pointers are real. They’re what the hardware understands. Somebody has to deal with them. You can’t just place a LISP book on top of an x86 chip and hope that the hardware learns about lambda calculus by osmosis.
I think it serves as a good abstract for the whole text.
Starting with pointers are real, one then builds abstractions on top of them to ensure they’re either replaced when efficient (eg arrays vs pointers) or used correctly ( eg aliasing). There’s system languages that do that in a variety of ways. Then, one might integrate it with SMT and separation solvers and/or use static analyzers to eliminate these consistent errors.
The above combines the realities of hardware with modern advances in language design. Sticking with C’s limitations anyway becomes harder to justify.
I guess the point of the article is that when your “separation solvers” fail (because they will), somebody has to be able to pick the broken pieces and rebuild civilization in an afternoon. Mankind cannot forget pointers forever, just by using abstractions.
Notice that this is the same in other sciences, unrelated to computers. Even if “high-level” properties of chemical substances are a good abstraction, cell biologists often need to dig deeper and dirty their hands with the fact that molecules are made of atoms. No science has perfect abstractions, and it would be ludicrous to pretend that programming can.
Maybe programerkind can mostly forget about pointers using abstractions, it might not make the bowels still laying down below the abstractions evolve without basic understanding of what gears it.
Meanwhile, I enjoy C for exposing me to the raw insides of a system, and I like the (false?) impression it gives. Wow! Is it C for prototyping and “HighLevel” (evoluted) language for real implementation now? That moved fast!
I wanted to wait till I was home and had time to respond. I definitely have links you might enjoy.
“But then, in which language do we design modern languages ? Is there absolutely no room for bootstrapping needs in the whole thing ?”
If aiming for practicality, I’d say anything that handles strings/trees well, prevents/catches errors well, has metaprogramming, and can be parallelized. These would make build a robust compiler more easy. Standard ML was popular for doing it correctly. Lisp for doing it powerfully. FLINT in SML and Nanopass framework in Scheme are examples.
Maybe you want to bootstrap for simple dependencies and/or diving down the rabbit hold. Others and I have a pile of links on that. Lisp’s help you cheat at it. Tcl has a simple syntax to build on, too.
“Driver in high level languages in a no-frills system are a thing !”
Or in Haskell. A Haskeller told me that’s not typical Haskell by any means. It did take us from “you need C for device drivers” to “you can use a different approach to Haskell.” Lea Wittie also used a type-safe, C alternative for drivers and more interesting work like Laddie here. There’s also people synthesizing drivers from specifications.
“I enjoy C for exposing me to the raw insides of a system”
First, it’s definitely OK to use a language if you’re just doing it for personal enjoyment. Far as C, it kind of gives you both the insides of a system and decades worth of C-related stuff. There’s been attempts that further simplifying it like C–.
Thank you for your detailed and insightful answer, which build on my discovery of “tools to make a hardware actually run software”.
I had vague remembrance of C–. It is good to see that from a given state, it is possible to keep going in all directions including toward simplification.
I guess the most fierce C zealots themselves have bumped onto this language shortcomings, for a language for which the latest revisions are still backward-compatible with the earliest K&R forms.
C sounds much like today landscape, and landscapes evolve. Few C compiler left to compile only C.
With more functional languages, I guess it takes a bit of programming language theory to get static type checking done right, which might be wanted to have it compiled without run-time type checking, maybe useful for low-level works.
At least for me, the zany style is the insight, trying to juxtapose the ridiculousness of low-level C bugs with this meta-narrative about the apocalypse
This is interesting, and I think I agree with many arguments when it comes to the reasons java, OCaml, Haskell, Go, etc. haven’t replaced C. However the author cites rust only briefly (and C++ not at all?) and doesn’t really convince me why rust isn’t the replacement he awaits: almost all you can do in C, you can do in rust (using “unsafe”, but that’s what rust is designed for after all), or in C++; you still have a higherer-level, safer (by default — can still write unsafe code where needed), unmanaged language that can speak the C ABI. Some projects have started replacing their C code with rust in an incremental (librsvg, I think? And of course firefox) because rust can speak the C ABI and use foreign memory like a good citizen of the systems world. Even C compilers are written in C++ these days.
To me that’s more “some were meant for no-gc, C ABI speaking, unsafe-able languages” than “some were meant for C”. :-)
Besides Rust, I think Zig, Nim, and D are strong contenders. Nothing against Rust, of course, but I’m not convinced it’s the best C replacement for every use case. It’s good to have options!
Nonetheless, I imagine C will linger on for decades to come, just due to network effects and economics. Legacy codebases, especially low-level ones, often receive little maintenance effort relative to usage, and C code is incredibly widespread.
I love Rust, but I think Zig and D (in the ‘better C’ mode and hopefully their new borrow checker) are closer to the simplicity and low-level functionality of C. Rust is a much nicer C++, with simpler (hah!) semantics and more room to improve. C++ is, unfortunately, a Frankenstein monster of a language that requires a 2000 page manual just to describe all the hidden weird things objects are doing behind your back. Every time I have to re-learn move semantics for a tiny project, I want to throw up.
i was also wondering, while reading the article, how well ada would fit the author’s use case (i’m not at all familiar with the langauge, i’ve just heard it praised as a safe low-level language)
Maybe I’m the archetype of a C-programmer not going for Rust. I appreciate Rust and as a Mathematician, I like the idea of hard guarantees that aren’t a given in C. However, Rust annoys me for three main reasons, and these are deal-breakers for me:
Compile time: This is not merely the language’s fault, and has more to do with how LLVM is used, but there doesn’t seem to be much push to improve the situation, either. It annoys me as a developer, but it also really annoys me as a Gentoo user when a Firefox compilation takes longer and longer with each subsequent Rust release. Golang is a shining example for how you can actually improve compilation times over C. Admittedly, Rust has more static analysis, but damn is it slow to compile! I like efficiency, who doesn’t? Rust really drops the ball there.
Standard library/external libraries: By trying to please everyone and not mandating certain solutions, one is constantly referred to this or that library on GitHub that is “usually used” and “recommended”. In other cases, there are two competing implementations. Sure, Rust is a young language, but for that reason alone I would never choose it to build anything serious on top of it, as one needs to be able to rely on interfaces. The Rust developers should stop trying to please everybody and come up with standard interfaces that also get shipped with the standard install.
Cargo/Package management: This point is really close to the one before it: Cargo is an interesting system, but really ends up becoming a “monosolution” for Rust setups. Call me old-fashioned, but I like package managers (especially Gentoo’s) and Cargo just works around it. When installing a Rust package, you end up having to be connected to the internet and often end up downloading dozens of small crates from some shady GitHub repos. I won’t make the comparison with node.js, given Cargo can be “tagged” to a certain version, but I could imagine a similar scenario to leftpad in the future. Rust really needs a better standard library so you don’t have to pull in so much stuff from other people.
To put it shortly: What I like about C is its simplicity and self-reliance. You don’t need Cargo to babysit it, you don’t need dozens of external crates to do basic stuff and it doesn’t get in the way of the package manager. I actually like Rust’s ownership system, but hate almost anything around it.
See, I feel the exact opposite when it comes to Cargo vs. system’s package manager: managing versions of libraries using your system’s package manager is a royal pain in the ass or outright impossible when you have multiple projects requiring different versions of a library. In my experience with C and C++, you’ll end up using CMake or Meson to build exactly the same functionality that Cargo deploys for you, at a much higher cost than just adding one line in a configuration file.
In fact, my biggest gripe with C and C++ is that they still depend on a 3-step build system (preprocessing, compiling, linking) each of which requires you to specify the location of a group of files. I get why having header files was attractive in the 1970s when you counted your computer’s memory in KBs, but it makes writing and maintaining code such a pain in the ass when compared with a modern module system.
The funniest bit is I used to consider all these things as ‘easy to deal with’ when all I did was write C/C++ code 15 years ago. Nowadays, having to switch from Go, Rust or any other language to C for a small project makes me want to cry because I know I’ll spend about 20% of the time managing bullshit that has nothing to do with the code I care about.
Build systems in C give a feeling of craftsmanship. It takes a skill to write a Makefile that correctly supports parallel builds, exact dependencies, interruptions and cleanups, etc. And so much work into making it work across platforms, and compilers.
And then Cargo just makes it pointless. It’s like you were king’s best messenger trained to ride the fastest stallions, and Cargo’s like “thanks, but we’ve got e-mail”.
LOL, I guess it’s a matter of age. When I first started programming, I’d love all that stuff. I can’t count how many libraries and tools I re-implemented or extended because they didn’t do something exactly the way I wanted it. Or the nights I spent configuring my Linux machine to work just right. Or the CPU time I spent re-encoding all of my MP3 collection to VBR because it’d save 5% of storage.
Now, I learned Cargo for a tiny project and I keep swearing every time I have to start a Python virtualenv because it’s just not easy enough, goddammit!.
This is a fair criticism of C, personally I would love to see a set commonly used data structures added to the C standard library. However, currently in the C world you either write your own or use something like glib, neither of these cases require the equivalent of Cargo.
However, currently in the C world you either write your own or use something like glib, neither of these cases require the equivalent of Cargo.
Neither does using the Rust standard library, which also has a hash table implementation (and many other useful data structures). You can just use std and compile your project with rustc.
We’re talking about dependencies in general, not just hash tables. FRIGN’s point is that the Rust standard library is lacking, so you end up needing crates.
But you and FRIGN are complaining about the Rust standard library compared to C. The Rust standard library is much more comprehensive than the C standard library or the C standard library + glib. So, the whole point seems to be void if C is the point of comparison.
If you are comparing to the Java standard library, sure!
But you and FRIGN are complaining about the Rust standard library compared to C.
Not really. The point being made is that a typical Rust application has to download a bunch of stuff from Github (crates), where as a typical C application does not.
Other than the initial clone (obviously), nothing should be talking to GitHub or crates.io. You can even do cargo build --release --offline if you’re paranoid.
I set that up in about 3 minutes. All I did was run cargo vendor, setup a .cargo/config to tell it to use the vendor directory, committed everything to a branch and pushed it. Easy peasy. If this were something a lot of people really cared about, you’d see this kind of setup more frequently. But people don’t really care as far as I can tell.
where as a typical C application does not
When was that last time you built a GNU C application? Last time I tried to build GNU grep, its build tooling downloaded a whole bunch of extra goop.
None of the C code I’ve worked on was written by GNU, and most of the C code out in the real world wasn’t written by GNU either. I find it frankly bizarre that you are seriously trying to suggest that GNU’s practices are somehow representative of all projects written in C.
You said “a typical C application.” Now you’re saying “representative” and “what I’ve worked on.”
If the implementation of coreutils for one of the most popular operating systems in history doesn’t constitute what’s “typical,” then I don’t know what does.
Talk about bizarre.
Moreover, you didn’t even bother to respond to the substance of my response, which was to point out that the tooling supports exactly what you want. People just don’t care. Instead, you’ve decided to double down on your own imprecise statement and have continued to shift the goal posts.
and most of the C code out in the real world wasn’t written by GNU either.
^ typical
I don’t have the time or patience to debate semantics though.
As for your other point, see FRIGN’s comment for my response.
(It doesn’t matter what’s possible when the reality is random crates get pulled from github repos)
Why do you say “even”? There are many hash table implementations in C, with different compromises. It would be untoward if any of them made its way into the base language. There are other things missing in C which are arguably more fundamental (to me) before hash tables. It is only fair if all of these things are kept out of the language, lest the people whose favorite feature has not been included feel alienated by the changes.
but there doesn’t seem to be much push to improve the situation
Definitely not true. There are people working on this and there has been quite a bit of progress:
$ git clone https://github.com/BurntSushi/ripgrep
$ cd ripgrep
$ git checkout 0.4.0
$ time cargo +1.12.0 build --release
real 1:04.05
user 1:51.42
sys 2.282
maxmem 360 MB
faults 736
$ time cargo +1.43.1 build --release
real 19.065
user 2:34.51
sys 3.101
maxmem 740 MB
faults 0
That’s 30% of what it once was a few years ago. Pretty big improvement from my perspective. The compilation time improvements come from all around too. Whether it’s improving the efficiency of parallelism or micro-optimizing rustc itself: here, here, here, here, here, here or here.
People care.
The Rust developers should stop trying to please everybody and come up with standard interfaces that also get shipped with the standard install.
That’s one of std’s primary objectives. It has tons of interfaces in it.
This criticism is just so weird, given that your alternative is C. I mean, if you want the C experience of “simplicity and self-reliance,” then std alone is probably pretty close to sufficient. And if you want the full POSIX experience, bring in libc and code like its C. (Or maybe use a safe interface that somebody else has thoughtfully designed.)
When installing a Rust package, you end up having to be connected to the internet
You do not, at least, no more than you are with a normal Linux distro package manager. This was a hard requirement. Debian for example requires the ability to use Cargo without connecting to the Internet.
and often end up downloading dozens of small crates from some shady GitHub repos.
Yup, the way the crates.io model works means the burden of doing due diligence is placed on each person developing a Rust project. But if you’re fine with the spartan nature of C’s standard library, then you should be just fine using a pretty small set of well established crates that aren’t shady. Happy to see counter examples though!
but I could imagine a similar scenario to leftpad in the future.
The leftpad disaster was specifically caused by someone removing their package from the repository. You can’t do that with crates.io. You can “yank” crates, but they remain available. Yanking a crate just prevents new dependents from being published.
Rust really needs a better standard library so you don’t have to pull in so much stuff from other people.
This point is really close to the one before it: Cargo is an interesting system, but really ends up becoming a “monosolution” for Rust setups. Call me old-fashioned, but I like package managers (especially Gentoo’s) and Cargo just works around it.
C has just been in the luxurious position that its package managers have been the default system package managers. Most Linux package managers are effectively a C package managers. Of course, over time packages for other languages have been added, but they have mostly been second-class citizens.
It is logical that Cargo works around those package managers. Most of them are a mismatch for Rust/Go/node.js packages, because they are centered around distributing C libraries, headers, and binaries.
but I could imagine a similar scenario to leftpad in the future.
Rust et al. certainly have a much higher risk, since anyone can upload anything to crates.io. However, I think it is also an illusion that distribution maintainers are actually vetting code. In many cases maintainers will just bump versions and update hashes. Of course, there is some gatekeeping in that distributions usually only provide packages from better-known projects.
Rust really needs a better standard library so you don’t have to pull in so much stuff from other people.
C has just been in the luxurious position that its package managers have been the default system package managers.
This just isn’t true, if you look at how packages are built for Debian for example you will find that languages such as Python and Perl are just as well supported as C. No, the system package managers are for the most part language agnostic.
This just isn’t true, if you look at how packages are built for Debian for example you will find that languages such as Python and Perl are just as well supported as C.
Most distributions only have a small subset of popular packages and usually only a limited number of versions (if multiple at all).
The fact that most Python development happens in virtual environments with pip-installed packages, even on personal machines, shows that most package managers and package sets are severely lacking for Python development.
s/Python/most non-C languages/
No, the system package managers are for the most part language agnostic.
Well if you define language agnostic as can dump files in a global namespace, because that’s typically enough for C libraries, sure. However, that does not work for many other languages, for various reasons, such as: no guaranteed ABI stability (so, any change down the chain of dependencies needs to trigger builds of all dependents, but there is no automated way to detect this, because packages are built in isolation), no strong tradition of ABI stability (various downstream users need different versions of a package), etc.
No, most development happens in virtualenv because python packaging is so broken that if you install a package you cannot reliably uninstall it.
If we didn’t have a package manager for each language then the packages maintained by the OS would be more comprehensive, by necessity. Basically having a different packaging system for each programming language was a mistake in my view. I have some hope that Nix will remedy the situation somewhat.
edit: it’s also difficult to reply to your comments if you substantially edit them by adding entirely new sections after posting…
No, most development happens in virtualenv because python packaging is so broken that if you install a package you cannot reliably uninstall it.
I have no idea what you mean here. Can’t you use dpkg/APT or rpm/DNF to uninstall a Python package?
If we didn’t have a package manager for each language then the packages maintained by the OS would be more comprehensive, by necessity.
We are going in circles. Why do you think languages have package managers? Technical reasons: the distribution package managers are too limited to handle what languages need. Social/political reasons: having the distributions as gatekeepers slows down the evolution of language ecosystems.
I have some hope that Nix will remedy the situation somewhat.
Nix (and Guix) can handle this, because it is powerful enough to implement the necessary language-specific packaging logic. In fact, Nix’ buildRustCrate is more or less an implementation of Cargo in Nix + shell script. It does not use Cargo. Moreover, Nix can handle a lot of the concerns that I mentioned upthread: it can easily handle multiple different versions of a package and ABI-instability. E.g. if in Nix the derivation of say the Rust compiler is updated, all packages of which Rust is a transitive dependency are rebuilt.
As I said, traditional package managers are built for a C world. Not a Rust, Python, Go, or whatever world.
The first problem is a technical one, unless Rust is doing things such that it can’t be compiled efficiently, but the latter two are cultural ones which point up differences in what language designers and implementers are expected to provide then versus now: In short, Rust tries to provide the total system, everything you need to build random Rust code you find online, whereas C doesn’t and never did. Rust is therefore in with JS, as you mention, but also Perl, Python, Ruby, and even Common Lisp now that Quicklisp and ASDF exist.
I was going to “blame” Perl and CPAN for this notion that language implementations should come with package management, but apparently CPAN was made in imitation of CTAN, the Comprehensive TeX Archive Network, so I guess this goes back even further. However, the blame isn’t with the language implementers at all: Packaging stuff is one of those things which has been re-invented so many times it’s bound to be re-invented a few more, simply because nobody can decide on a single way of doing it. Therefore, since language implementers can’t rely on OS package repos to have a rich selection up-to-date library versions, and rightly balk at the idea of making n different OS-specific packages for each version of each library, it’s only natural each language would reinvent that wheel. It makes even more sense when you consider people using old LTS OS releases, which won’t get newer library versions at this point, and consider longstanding practice from the days before OSes tended to have package management at all.
Therefore, since language implementers can’t rely on OS package repos to have a rich selection up-to-date library versions, and rightly balk at the idea of making n different OS-specific packages for each version of each library, it’s only natural each language would reinvent that wheel.
This is right on the mark.
Sorry if this is a bit of a tangent, but I think it is not just a failing of package sets – from the distributor’s perspective it is impossible to package every Rust crate and rust crate version manually – but especially of package managers themselves. There is nothing that prevents a powerful package management system to generate package sets from Cargo.lock files. But most package managers were not built for generating package definitions programmatically and most package managers do not allow allow installing multiple package versions in parallel (e.g. ndarray 0.11.0 and ndarray 0.12.0).
Nix shows that this is definitely feasible, e.g. the combo of crate2nix and buildRustCrate can create Nix derivations for every dependency in a Cargo.lock file. It does not use cargo at all, compiles every crate into a separate Nix store path. As a result, Rust crates are not really different from any other package provided through nixpkgs.
I am not that familiar with Guix, but I bet it could do the same.
Build times are important, and you’re right, Rust takes a while to compile. Given the choice between waiting for rustc to finish and spending a lot longer debugging a C program after the fact, I choose the former. Or, better yet, use D and get the best of both worlds.
rust can be damn fast to compile, most rust library authors just exercise fairly poor taste in my opinion and tend not to care how bad their build times get. sled.rs compiles in 6 seconds on my laptop, and most other embedded databases take a LOT longer (usually minutes), despite sled being Rust and them being C or C++.
rust is a complex tool, and as such, you need to exercise judgement (which, admittedly, is rare, but that’s no different from anything else). you can avoid unnecessary genericism, proc macros, and trivial dependencies to get compile times that are extremely zippy.
As an anecdata, I‘ve immediately recognized the snippet with elf header from the article, because I used one of the same tricks (just memcpying a repr(C) struct) for writing elf files in Rust a couple of months ago.
I though about using rust to implement a byte-code compiler / vm for a gc’d language project, but I assumed that this would require too much fighting to escape rust’s ownership restrictions. Do you have any insight into how well suited rust is for vm implementation? I haven’t used the language much but I’d love to pick it up if I though I could make it work for my needs.
(I see that there’s a python interpreter written in rust, but I’m having trouble locating its gc implementation)
I honestly don’t know, I have never written an interpreter. You probably can fall back on unsafe for some things anyway, and still benefit from the move semantics, sum types, syntax, and friendly error messages. I’m doing a bit of exploring symbolic computations with rust and there are also some design space exploration to be done there.
IMO, Rust is just as good as C and C++ for projects like this, if not better thanks to pattern matching and a focus on safety (which goes far beyond the borrow checker). Don’t be afraid to use raw pointers and NonNull pointers when they are appropriate.
I wrote a ST80 VM in rust just to play around; the result was beautifully simple and didn’t require any unsafe code, though it doesn’t currently have any optimization at all. The result was still reasonably snappy, but I suspect that a big part of that is that the code I was running on it was designed in, well, 1980.
Why not just call it the Lobsters Rust Conference? Flows better off the tongue and is a better description of every discussion thread here that’s supposedly about C.
Every time I see this article, I causes me to go look up and read the one below, and it has yet to fail to improve my day
https://www.usenix.org/system/files/1311_05-08_mickens.pdf
[Comment from banned user removed]
Not a summary, but a quote from the text itself that happens to be somewhat free of rhetorics :
I think it serves as a good abstract for the whole text.
Starting with pointers are real, one then builds abstractions on top of them to ensure they’re either replaced when efficient (eg arrays vs pointers) or used correctly ( eg aliasing). There’s system languages that do that in a variety of ways. Then, one might integrate it with SMT and separation solvers and/or use static analyzers to eliminate these consistent errors.
The above combines the realities of hardware with modern advances in language design. Sticking with C’s limitations anyway becomes harder to justify.
I guess the point of the article is that when your “separation solvers” fail (because they will), somebody has to be able to pick the broken pieces and rebuild civilization in an afternoon. Mankind cannot forget pointers forever, just by using abstractions.
Notice that this is the same in other sciences, unrelated to computers. Even if “high-level” properties of chemical substances are a good abstraction, cell biologists often need to dig deeper and dirty their hands with the fact that molecules are made of atoms. No science has perfect abstractions, and it would be ludicrous to pretend that programming can.
But, maybe one day we can move passed a virtual machine for the PDP-11?
(I happen to like C, but it’s hard to debate against the minimal amount of C necessary, being the correct amount of C, in these modern times)
My belief is that C’s low-level sides are not encountered with execution and CPU but with the memory. I never implemented a compiler though.
But sure, C should not be an occlusion to any improvement. Nothing should.
Maybe programerkind can mostly forget about pointers using abstractions, it might not make the bowels still laying down below the abstractions evolve without basic understanding of what gears it.
But then, in which language do we design modern languages ? Is there absolutely no room for bootstrapping needs in the whole thing ?
Also, yes! Driver in high level languages in a no-frills system are a thing ! https://www.netbsd.org/~lneto/bsdconbr15.pdf
Meanwhile, I enjoy C for exposing me to the raw insides of a system, and I like the (false?) impression it gives. Wow! Is it C for prototyping and “HighLevel” (evoluted) language for real implementation now? That moved fast!
I wanted to wait till I was home and had time to respond. I definitely have links you might enjoy.
“But then, in which language do we design modern languages ? Is there absolutely no room for bootstrapping needs in the whole thing ?”
If aiming for practicality, I’d say anything that handles strings/trees well, prevents/catches errors well, has metaprogramming, and can be parallelized. These would make build a robust compiler more easy. Standard ML was popular for doing it correctly. Lisp for doing it powerfully. FLINT in SML and Nanopass framework in Scheme are examples.
Maybe you want to bootstrap for simple dependencies and/or diving down the rabbit hold. Others and I have a pile of links on that. Lisp’s help you cheat at it. Tcl has a simple syntax to build on, too.
“Driver in high level languages in a no-frills system are a thing !”
Or in Haskell. A Haskeller told me that’s not typical Haskell by any means. It did take us from “you need C for device drivers” to “you can use a different approach to Haskell.” Lea Wittie also used a type-safe, C alternative for drivers and more interesting work like Laddie here. There’s also people synthesizing drivers from specifications.
“I enjoy C for exposing me to the raw insides of a system”
First, it’s definitely OK to use a language if you’re just doing it for personal enjoyment. Far as C, it kind of gives you both the insides of a system and decades worth of C-related stuff. There’s been attempts that further simplifying it like C–.
Thank you for your detailed and insightful answer, which build on my discovery of “tools to make a hardware actually run software”.
I had vague remembrance of C–. It is good to see that from a given state, it is possible to keep going in all directions including toward simplification.
I guess the most fierce C zealots themselves have bumped onto this language shortcomings, for a language for which the latest revisions are still backward-compatible with the earliest K&R forms.
C sounds much like today landscape, and landscapes evolve. Few C compiler left to compile only C.
With more functional languages, I guess it takes a bit of programming language theory to get static type checking done right, which might be wanted to have it compiled without run-time type checking, maybe useful for low-level works.
P.S.: https://bootstrapping.miraheze.org/wiki/Main_Page is definitely a gold mine, which will not help me with insomnia. :)
At least for me, the zany style is the insight, trying to juxtapose the ridiculousness of low-level C bugs with this meta-narrative about the apocalypseSee the comment from @coco
This is an excellent rebuttal that I’d never considered, even though I’ve read and enjoyed both articles multiple times.
oh, there is a shrine for HIM here: https://medium.com/@soobrosa/my-humble-james-mickens-shrine-a-k-a-the-only-real-combined-cs-degree-and-mba-you-will-ever-need-1f437f496d1c
I’m so excited, thank you for sharing this
This is interesting, and I think I agree with many arguments when it comes to the reasons java, OCaml, Haskell, Go, etc. haven’t replaced C. However the author cites rust only briefly (and C++ not at all?) and doesn’t really convince me why rust isn’t the replacement he awaits: almost all you can do in C, you can do in rust (using “unsafe”, but that’s what rust is designed for after all), or in C++; you still have a higherer-level, safer (by default — can still write unsafe code where needed), unmanaged language that can speak the C ABI. Some projects have started replacing their C code with rust in an incremental (librsvg, I think? And of course firefox) because rust can speak the C ABI and use foreign memory like a good citizen of the systems world. Even C compilers are written in C++ these days.
To me that’s more “some were meant for no-gc, C ABI speaking, unsafe-able languages” than “some were meant for C”. :-)
Besides Rust, I think Zig, Nim, and D are strong contenders. Nothing against Rust, of course, but I’m not convinced it’s the best C replacement for every use case. It’s good to have options!
Nonetheless, I imagine C will linger on for decades to come, just due to network effects and economics. Legacy codebases, especially low-level ones, often receive little maintenance effort relative to usage, and C code is incredibly widespread.
I love Rust, but I think Zig and D (in the ‘better C’ mode and hopefully their new borrow checker) are closer to the simplicity and low-level functionality of C. Rust is a much nicer C++, with simpler (hah!) semantics and more room to improve. C++ is, unfortunately, a Frankenstein monster of a language that requires a 2000 page manual just to describe all the hidden weird things objects are doing behind your back. Every time I have to re-learn move semantics for a tiny project, I want to throw up.
i was also wondering, while reading the article, how well ada would fit the author’s use case (i’m not at all familiar with the langauge, i’ve just heard it praised as a safe low-level language)
The lot of them! It was kind of a large gap between C and Python/Perl/Ruby/Java.
You might want to read this brief follow-up:
https://www.cs.kent.ac.uk/people/staff/srk21/blog/2017/10/18/#some-were-meant-for-post-hoc-reflections
Maybe I’m the archetype of a C-programmer not going for Rust. I appreciate Rust and as a Mathematician, I like the idea of hard guarantees that aren’t a given in C. However, Rust annoys me for three main reasons, and these are deal-breakers for me:
To put it shortly: What I like about C is its simplicity and self-reliance. You don’t need Cargo to babysit it, you don’t need dozens of external crates to do basic stuff and it doesn’t get in the way of the package manager. I actually like Rust’s ownership system, but hate almost anything around it.
C doesn’t even have a hash table. It needs more external libraries to do basic stuffs, not less.
See, I feel the exact opposite when it comes to Cargo vs. system’s package manager: managing versions of libraries using your system’s package manager is a royal pain in the ass or outright impossible when you have multiple projects requiring different versions of a library. In my experience with C and C++, you’ll end up using CMake or Meson to build exactly the same functionality that Cargo deploys for you, at a much higher cost than just adding one line in a configuration file.
In fact, my biggest gripe with C and C++ is that they still depend on a 3-step build system (preprocessing, compiling, linking) each of which requires you to specify the location of a group of files. I get why having header files was attractive in the 1970s when you counted your computer’s memory in KBs, but it makes writing and maintaining code such a pain in the ass when compared with a modern module system.
The funniest bit is I used to consider all these things as ‘easy to deal with’ when all I did was write C/C++ code 15 years ago. Nowadays, having to switch from Go, Rust or any other language to C for a small project makes me want to cry because I know I’ll spend about 20% of the time managing bullshit that has nothing to do with the code I care about.
Build systems in C give a feeling of craftsmanship. It takes a skill to write a
Makefilethat correctly supports parallel builds, exact dependencies, interruptions and cleanups, etc. And so much work into making it work across platforms, and compilers.And then Cargo just makes it pointless. It’s like you were king’s best messenger trained to ride the fastest stallions, and Cargo’s like “thanks, but we’ve got e-mail”.
LOL, I guess it’s a matter of age. When I first started programming, I’d love all that stuff. I can’t count how many libraries and tools I re-implemented or extended because they didn’t do something exactly the way I wanted it. Or the nights I spent configuring my Linux machine to work just right. Or the CPU time I spent re-encoding all of my MP3 collection to VBR because it’d save 5% of storage.
Now, I learned Cargo for a tiny project and I keep swearing every time I have to start a Python virtualenv because it’s just not easy enough, goddammit!.
This is a fair criticism of C, personally I would love to see a set commonly used data structures added to the C standard library. However, currently in the C world you either write your own or use something like glib, neither of these cases require the equivalent of Cargo.
However, currently in the C world you either write your own or use something like glib, neither of these cases require the equivalent of Cargo.
Neither does using the Rust standard library, which also has a hash table implementation (and many other useful data structures). You can just use
stdand compile your project withrustc.We’re talking about dependencies in general, not just hash tables. FRIGN’s point is that the Rust standard library is lacking, so you end up needing crates.
But you and FRIGN are complaining about the Rust standard library compared to C. The Rust standard library is much more comprehensive than the C standard library or the C standard library + glib. So, the whole point seems to be void if C is the point of comparison.
If you are comparing to the Java standard library, sure!
Not really. The point being made is that a typical Rust application has to download a bunch of stuff from Github (crates), where as a typical C application does not.
That’s just because it’s convenient and most people don’t really care that it happens. But it’s not inherent to the tooling:
Other than the initial clone (obviously), nothing should be talking to GitHub or crates.io. You can even do
cargo build --release --offlineif you’re paranoid.I set that up in about 3 minutes. All I did was run
cargo vendor, setup a.cargo/configto tell it to use the vendor directory, committed everything to a branch and pushed it. Easy peasy. If this were something a lot of people really cared about, you’d see this kind of setup more frequently. But people don’t really care as far as I can tell.When was that last time you built a GNU C application? Last time I tried to build GNU grep, its build tooling downloaded a whole bunch of extra goop.
Nice strawman, I said a typical C application, not a typical GNU C application.
TIL that a GNU C application is not a “typical” C application. Lol.
None of the C code I’ve worked on was written by GNU, and most of the C code out in the real world wasn’t written by GNU either. I find it frankly bizarre that you are seriously trying to suggest that GNU’s practices are somehow representative of all projects written in C.
You said “a typical C application.” Now you’re saying “representative” and “what I’ve worked on.”
If the implementation of coreutils for one of the most popular operating systems in history doesn’t constitute what’s “typical,” then I don’t know what does.
Talk about bizarre.
Moreover, you didn’t even bother to respond to the substance of my response, which was to point out that the tooling supports exactly what you want. People just don’t care. Instead, you’ve decided to double down on your own imprecise statement and have continued to shift the goal posts.
^ typical
I don’t have the time or patience to debate semantics though.
As for your other point, see FRIGN’s comment for my response. (It doesn’t matter what’s possible when the reality is random crates get pulled from github repos)
Why do you say “even”? There are many hash table implementations in C, with different compromises. It would be untoward if any of them made its way into the base language. There are other things missing in C which are arguably more fundamental (to me) before hash tables. It is only fair if all of these things are kept out of the language, lest the people whose favorite feature has not been included feel alienated by the changes.
Definitely not true. There are people working on this and there has been quite a bit of progress:
That’s 30% of what it once was a few years ago. Pretty big improvement from my perspective. The compilation time improvements come from all around too. Whether it’s improving the efficiency of parallelism or micro-optimizing rustc itself: here, here, here, here, here, here or here.
People care.
That’s one of std’s primary objectives. It has tons of interfaces in it.
This criticism is just so weird, given that your alternative is C. I mean, if you want the C experience of “simplicity and self-reliance,” then std alone is probably pretty close to sufficient. And if you want the full POSIX experience, bring in libc and code like its C. (Or maybe use a safe interface that somebody else has thoughtfully designed.)
You do not, at least, no more than you are with a normal Linux distro package manager. This was a hard requirement. Debian for example requires the ability to use Cargo without connecting to the Internet.
Yup, the way the crates.io model works means the burden of doing due diligence is placed on each person developing a Rust project. But if you’re fine with the spartan nature of C’s standard library, then you should be just fine using a pretty small set of well established crates that aren’t shady. Happy to see counter examples though!
The leftpad disaster was specifically caused by someone removing their package from the repository. You can’t do that with crates.io. You can “yank” crates, but they remain available. Yanking a crate just prevents new dependents from being published.
… like C? o_0
C has just been in the luxurious position that its package managers have been the default system package managers. Most Linux package managers are effectively a C package managers. Of course, over time packages for other languages have been added, but they have mostly been second-class citizens.
It is logical that Cargo works around those package managers. Most of them are a mismatch for Rust/Go/node.js packages, because they are centered around distributing C libraries, headers, and binaries.
Rust et al. certainly have a much higher risk, since anyone can upload anything to crates.io. However, I think it is also an illusion that distribution maintainers are actually vetting code. In many cases maintainers will just bump versions and update hashes. Of course, there is some gatekeeping in that distributions usually only provide packages from better-known projects.
You mean a large standard library like… C?
This just isn’t true, if you look at how packages are built for Debian for example you will find that languages such as Python and Perl are just as well supported as C. No, the system package managers are for the most part language agnostic.
Most distributions only have a small subset of popular packages and usually only a limited number of versions (if multiple at all).
The fact that most Python development happens in virtual environments with
pip-installed packages, even on personal machines, shows that most package managers and package sets are severely lacking for Python development.s/Python/most non-C languages/
Well if you define language agnostic as can dump files in a global namespace, because that’s typically enough for C libraries, sure. However, that does not work for many other languages, for various reasons, such as: no guaranteed ABI stability (so, any change down the chain of dependencies needs to trigger builds of all dependents, but there is no automated way to detect this, because packages are built in isolation), no strong tradition of ABI stability (various downstream users need different versions of a package), etc.
No, most development happens in virtualenv because python packaging is so broken that if you install a package you cannot reliably uninstall it.
If we didn’t have a package manager for each language then the packages maintained by the OS would be more comprehensive, by necessity. Basically having a different packaging system for each programming language was a mistake in my view. I have some hope that Nix will remedy the situation somewhat.
edit: it’s also difficult to reply to your comments if you substantially edit them by adding entirely new sections after posting…
I have no idea what you mean here. Can’t you use dpkg/APT or rpm/DNF to uninstall a Python package?
We are going in circles. Why do you think languages have package managers? Technical reasons: the distribution package managers are too limited to handle what languages need. Social/political reasons: having the distributions as gatekeepers slows down the evolution of language ecosystems.
Nix (and Guix) can handle this, because it is powerful enough to implement the necessary language-specific packaging logic. In fact, Nix’
buildRustCrateis more or less an implementation of Cargo in Nix + shell script. It does not use Cargo. Moreover, Nix can handle a lot of the concerns that I mentioned upthread: it can easily handle multiple different versions of a package and ABI-instability. E.g. if in Nix the derivation of say the Rust compiler is updated, all packages of which Rust is a transitive dependency are rebuilt.As I said, traditional package managers are built for a C world. Not a Rust, Python, Go, or whatever world.
The first problem is a technical one, unless Rust is doing things such that it can’t be compiled efficiently, but the latter two are cultural ones which point up differences in what language designers and implementers are expected to provide then versus now: In short, Rust tries to provide the total system, everything you need to build random Rust code you find online, whereas C doesn’t and never did. Rust is therefore in with JS, as you mention, but also Perl, Python, Ruby, and even Common Lisp now that Quicklisp and ASDF exist.
I was going to “blame” Perl and CPAN for this notion that language implementations should come with package management, but apparently CPAN was made in imitation of CTAN, the Comprehensive TeX Archive Network, so I guess this goes back even further. However, the blame isn’t with the language implementers at all: Packaging stuff is one of those things which has been re-invented so many times it’s bound to be re-invented a few more, simply because nobody can decide on a single way of doing it. Therefore, since language implementers can’t rely on OS package repos to have a rich selection up-to-date library versions, and rightly balk at the idea of making n different OS-specific packages for each version of each library, it’s only natural each language would reinvent that wheel. It makes even more sense when you consider people using old LTS OS releases, which won’t get newer library versions at this point, and consider longstanding practice from the days before OSes tended to have package management at all.
This is right on the mark.
Sorry if this is a bit of a tangent, but I think it is not just a failing of package sets – from the distributor’s perspective it is impossible to package every Rust crate and rust crate version manually – but especially of package managers themselves. There is nothing that prevents a powerful package management system to generate package sets from
Cargo.lockfiles. But most package managers were not built for generating package definitions programmatically and most package managers do not allow allow installing multiple package versions in parallel (e.g.ndarray 0.11.0andndarray 0.12.0).Nix shows that this is definitely feasible, e.g. the combo of
crate2nixandbuildRustCratecan create Nix derivations for every dependency in aCargo.lockfile. It does not usecargoat all, compiles every crate into a separate Nix store path. As a result, Rust crates are not really different from any other package provided throughnixpkgs.I am not that familiar with Guix, but I bet it could do the same.
Build times are important, and you’re right, Rust takes a while to compile. Given the choice between waiting for rustc to finish and spending a lot longer debugging a C program after the fact, I choose the former. Or, better yet, use D and get the best of both worlds.
rust can be damn fast to compile, most rust library authors just exercise fairly poor taste in my opinion and tend not to care how bad their build times get. sled.rs compiles in 6 seconds on my laptop, and most other embedded databases take a LOT longer (usually minutes), despite sled being Rust and them being C or C++.
rust is a complex tool, and as such, you need to exercise judgement (which, admittedly, is rare, but that’s no different from anything else). you can avoid unnecessary genericism, proc macros, and trivial dependencies to get compile times that are extremely zippy.
Thanks for your insights! I’ll keep it in mind the next time I try out Rust.
Feel free to reach out if you hit any friction, I’m happy to point folks in the direction they want to go with Rust :)
As an anecdata, I‘ve immediately recognized the snippet with elf header from the article, because I used one of the same tricks (just memcpying a repr(C) struct) for writing elf files in Rust a couple of months ago.
I though about using rust to implement a byte-code compiler / vm for a gc’d language project, but I assumed that this would require too much fighting to escape rust’s ownership restrictions. Do you have any insight into how well suited rust is for vm implementation? I haven’t used the language much but I’d love to pick it up if I though I could make it work for my needs.
(I see that there’s a python interpreter written in rust, but I’m having trouble locating its gc implementation)
I honestly don’t know, I have never written an interpreter. You probably can fall back on unsafe for some things anyway, and still benefit from the move semantics, sum types, syntax, and friendly error messages. I’m doing a bit of exploring symbolic computations with rust and there are also some design space exploration to be done there.
IMO, Rust is just as good as C and C++ for projects like this, if not better thanks to pattern matching and a focus on safety (which goes far beyond the borrow checker). Don’t be afraid to use raw pointers and
NonNullpointers when they are appropriate.Also, just saw this GC for Rust on the front page: https://github.com/zesterer/broom/blob/master/README.md
Looks like it’s designed specificly for writing dynamic languages in Rust.
Oh cool! This looks super useful
I wrote a ST80 VM in rust just to play around; the result was beautifully simple and didn’t require any unsafe code, though it doesn’t currently have any optimization at all. The result was still reasonably snappy, but I suspect that a big part of that is that the code I was running on it was designed in, well, 1980.
I recently did a simple lisp interpreter in rust. Eventually decided to re-do it in c because of shared mutation and garbage collection.
Rust works well for VM implementation. For GC, you may want to look at https://github.com/zesterer/broom.
Previous discussion here.
Let’s call it the Lobsters’ Some-Were-Meant-for-C-Conference and make it happen every year.
Why not just call it the Lobsters Rust Conference? Flows better off the tongue and is a better description of every discussion thread here that’s supposedly about C.