4 ms·

> but people who _want_ to actually write, and maintain system software want to do so in C. At the time this article was written, you would probably be correct

> but people who _want_ to actually write, and maintain system software want to do so in C. At the time this article was written, you would probably be correct. But for about the past 5 or so years, there's been quite a few people in this space who have entertained the use of Rust instead. This includes people who write firmware, people who write drivers, even some of the people who work on the large operating system kernels themselves--you'll find examples of people who have indicated a desire to at least explore using Rust instead of C. And there's more languages in this space that have come out after Rust (Zig perhaps the most notable of those). While this view is far from universal, it's definitely the case that there's a large number of systems programmers who are interested in no longer writing in C. > C is on paper not a safe language, but almost all of the most trusted safety critical software is written in it, so from a Darwinistic point of view it has produced more trusted software. My understanding of things like MISRA C is that it's almost a completely different language--to turn C into something you can use for safety-critical stuff, you need to start ripping out or at least heavily curtail basically all of C's differentiating features.

wheelerof4te 4y ago
Still, C is far more enjoyable to write than Rust is. Constantly fighting with your compiler is not how I would imagine a good time.
- c-cube 4y ago
  Clearly that's a matter of taste. The popularity of rust shows that some people prefer writing it to writing C or C++, otherwise they'd just write C or C++. And yeah, personally I'd rather spend time fixing compile time errors, directly in the editor as I type, than hunting segfaults with gdb later.
  - torstenvl 4y ago
    Personally — and I know this isn't a good philosophy for secure software, I'm just commenting purely on the enjoyability aspect — I much prefer the logic game of hunting memory errors over the frustration of one of my tools refusing to do what I'm telling it to do. (Like Brian Kernighan, I usually use judicious printf()s rather than gdb or lldb.)
- jcranmer 4y ago
  I care to disagree. I'd much rather fight with my compiler than play the game of "oops, I segfaulted, let me recompile with -g so I can rerun with gdb so I can figure out where I crashed." Or more minor stuff, like trying to track down which header file actually contains the implementation of, say, struct mcontext_t so I can remember how to set the value of RSP in a signal handler. I've grown to enjoy the Rust programming far more. Having a language, and associated tooling, that's woken up to the 21st century is far more enjoyable. (Really, why is it acceptable that a major language in 2023 still defaults to providing absolutely no diagnostic information on a fault?)
- Gigachad 4y ago
  Fighting with the compiler just means you have the wrong frame of thinking. Once you learn how to express things in ways that are verifiably safe, there is no fighting because you’ll get it mostly correct the first time.
  - eggy 4y ago
    I agree, but I think you should then look at SPARK2014 [1]. Rust just has better marketing and a bigger company behind it, but SPARK2014 is simpler and has been delivering Rust's bullet list for almost 10 years. [1] https://www.adacore.com/about-spark https://www.adacore.com/about-spark
    - Gigachad 4y ago
      Why on earth did they add 2014 to the name? It’s like putting an expiry date on it before it even takes off.
      - eggy 4y ago
        It is more a version thing, and I always put it in the name to differentiate from Apache's Spark. That and the all-uppercase letters.
Firmwarrior 4y ago
I'm going to butt in with a counterpoint, since every time someone mentions "c" on the internet a bunch of Rust people come out of the woodwork and give this impression that Rust is taking over, everything is Rust now, everyone loves Rust, etc. I've been a mobile OS developer for a decade now. Basically nobody uses Rust in the real world of firmware/kernel engineering. There are a few public examples of doing Rust in linux and Google, but the vast majority of work is still done in c or c-flavored c++. Maybe it'll catch on some day, but it's definitely NOT catching on in the real world of making actual products.
- steveklabnik 4y ago
  > I've been a mobile OS developer for a decade now. Basically nobody uses Rust in the real world of firmware/kernel engineering. You know it’s kinda funny, I read this comment and then tabbed over to twitter and then read this: https://blogs.blackberry.com/en/2023/02/this-is-the-kind-of-rust-the-automotive-industry-needs https://blogs.blackberry.com/en/2023/02/this-is-the-kind-of-... Anyway you’re not wrong that Rust is still a tiny portion of this kind of thing, but it is growing, and quickly. Only time will tell. (I work at a company writing firmware (and virtually everything else) in Rust, but as a startup I don’t expect that to carry as much weight as big established companies, of course.)
  - Firmwarrior 4y ago
    Man oh man. I realized I'd never even seen Rust code once in my life, so I loaded up some random Rust book and skimmed through it. I know HackerNews doesn't like half-informed angry opinions, so I'll just say "I really hope Rust never takes off" and leave it at that.
    - steveklabnik 4y ago
      Not everything can be everyone's cup of tea :)
    - dralley 4y ago
      What about your brief skimming turned you off?
quelsolaar 4y ago
Lots of people are _entertaining_ Rust as an option, but that's very different from C being defecto. I don't know of a single peace of software I have used written in Rust. A lot of people have in the past had very good arguments for why their language (C++, D Java, OCaml, Objective-C) should replace C but after decades they still haven't. The C-is-dead argument predates Rust by a lot, and Rust is already 10 years old. C may at some point be replaced, but I'm not holding my breath especially given that I think Cs success is so poorly understood, especially by people who come from other languages.
- jcranmer 4y ago
  Sure, Rust isn't there yet; C is still undisputably the king of system languages. But it's honestly the first language to crack the chink of C's dominance in low-level programming--C no longer looks unstoppable, in a way that C++ or D never managed to achieve.
- di4na 4y ago
  Ever used Android? VScode? If yes, you are using software written in Rust. Fastly? Same. Python? there is a good chance you are using cryptography, which is partially in Rust. Firefox? Rust is in there. And i could keep doing, at this point it is slowly creeping everywhere :)
  - Gigachad 4y ago
    Linux also contains the building blocks for loading rust modules now as I understand. And some builds like Asahi Linux contain major rust components.
    - di4na 4y ago
      Iirc AWS ship quite some rust in their hypervisor and networking stack too
- AnimalMuppet 4y ago
  It's like Chesterton's Fence. If you don't understand why C is used, you aren't going to be able to convince people that they ought to use something else. And you for certain are not going to be able to create a language to replace it.
tialaramex 4y ago
> My understanding of things like MISRA C is that it's almost a completely different language MISRA's rules aren't that distinct from a C coding style you've probably used if you're an experienced C programmer. Any competent C programmer can easily read and understand code that obeys the rules - it's just C, but maybe somebody with no prior experience of MISRA might trip on some of the rules because they're unnatural. For example if you like recursive code, MISRA hates that, so don't do that (call stacks are finite). If you're used to doing shenanigans with pointers (e.g. XOR linked list), MISRA hates that too, C's pointers are just magic, don't try to fiddle with them. I'd guess that 90+% of code I wrote with no intention for it to be MISRA would, in fact, pass MISRA rules or would pass with some minor tweaks. Some of MISRA's dozens of rules are forbidding stuff no sane C programmer writes unless it's for a contest or something, so you just won't hit those. Some require practices which were recommended in like the ANSI document, that's over 30 years ago, hopefully you are doing that already.
FullyFunctional 4y ago
My annecdata: my first language after BASIC was Pascal and I worked professionally for a couple of years using Turbo Pascal, yet I preferred C. I think the reasons were (in order): verbosity and flexibility. I always hated Wirth's obsession with bloated keywords. I like conciseness (though J might be jumping the shark). The latter point is just a reflection of how awkward it is to the break the rules in Pascal, which was necessary for many real-world applications. And yes, I'm also a Rust convertee (sorry haters); I can do everything I did in C in Rust and for most parts it's more readable and frankly less work. I think my biggest regret is that while I know I could write a C compiler, I don't think I could write a Rust compiler [in my lifetime].
- eggy 4y ago
  I love J and APL, but April takes the cake for me[1]. APL in Lisp. I also prefer SPARK2014 instead of Rust if I am not going to use C. I've started learning Rust a few times. SPARK2014 is easier to get going for me, and it has been used to produce high-integrity software and real-world applications for over a decade, and more if you include Ada from which it sprang[2]. [1] https://github.com/phantomics/april https://github.com/phantomics/april [2] https://www.adacore.com/about-spark https://www.adacore.com/about-spark
  - FullyFunctional 4y ago
    April is interesting, thanks. Aside: I worked professionally in Scheme for a few years, but Haskell (and ghci) is my favorite language (thus my handle) for experimenting with non-trivial derivations and quick one-off experiments. Rust gives me some of what I love in Haskell (type classes, polymorphic types, sum types, some type inference, rich and ergonomic library, some functional style, ...) without the sad part (space leaks, unpredictable runtime, completely insane defaults from a perf POV)
    - eggy 4y ago
      I find APL and J to be functional enough and terse to a point of beauty once you get it. Look at solutions on rosettacode.org between Haskell and J or APL to get a feel for what I am saying. Rust's syntax is a turn off, but that is a personal bias against my C background once I embraced Haskell, J, APL, Forth, Lisp, etc... SPARK2014 covers me for the things Rust is striving for with a longer legacy of doing so for real world systems. It's also a simpler syntax (Ada, Pascal).

wheelerof4te 4y ago

Still, C is far more enjoyable to write than Rust is. Constantly fighting with your compiler is not how I would imagine a good time.

c-cube 4y ago
Clearly that's a matter of taste. The popularity of rust shows that some people prefer writing it to writing C or C++, otherwise they'd just write C or C++. And yeah, personally I'd rather spend time fixing compile time errors, directly in the editor as I type, than hunting segfaults with gdb later.
- torstenvl 4y ago
  Personally — and I know this isn't a good philosophy for secure software, I'm just commenting purely on the enjoyability aspect — I much prefer the logic game of hunting memory errors over the frustration of one of my tools refusing to do what I'm telling it to do. (Like Brian Kernighan, I usually use judicious printf()s rather than gdb or lldb.)
jcranmer 4y ago
I care to disagree. I'd much rather fight with my compiler than play the game of "oops, I segfaulted, let me recompile with -g so I can rerun with gdb so I can figure out where I crashed." Or more minor stuff, like trying to track down which header file actually contains the implementation of, say, struct mcontext_t so I can remember how to set the value of RSP in a signal handler. I've grown to enjoy the Rust programming far more. Having a language, and associated tooling, that's woken up to the 21st century is far more enjoyable. (Really, why is it acceptable that a major language in 2023 still defaults to providing absolutely no diagnostic information on a fault?)
Gigachad 4y ago
Fighting with the compiler just means you have the wrong frame of thinking. Once you learn how to express things in ways that are verifiably safe, there is no fighting because you’ll get it mostly correct the first time.
- eggy 4y ago
  I agree, but I think you should then look at SPARK2014 [1]. Rust just has better marketing and a bigger company behind it, but SPARK2014 is simpler and has been delivering Rust's bullet list for almost 10 years. [1] https://www.adacore.com/about-spark https://www.adacore.com/about-spark
  - Gigachad 4y ago
    Why on earth did they add 2014 to the name? It’s like putting an expiry date on it before it even takes off.
    - eggy 4y ago
      It is more a version thing, and I always put it in the name to differentiate from Apache's Spark. That and the all-uppercase letters.

Firmwarrior 4y ago

I'm going to butt in with a counterpoint, since every time someone mentions "c" on the internet a bunch of Rust people come out of the woodwork and give this impression that Rust is taking over, everything is Rust now, everyone loves Rust, etc. I've been a mobile OS developer for a decade now. Basically nobody uses Rust in the real world of firmware/kernel engineering. There are a few public examples of doing Rust in linux and Google, but the vast majority of work is still done in c or c-flavored c++. Maybe it'll catch on some day, but it's definitely NOT catching on in the real world of making actual products.

steveklabnik 4y ago
> I've been a mobile OS developer for a decade now. Basically nobody uses Rust in the real world of firmware/kernel engineering. You know it’s kinda funny, I read this comment and then tabbed over to twitter and then read this: https://blogs.blackberry.com/en/2023/02/this-is-the-kind-of-rust-the-automotive-industry-needs https://blogs.blackberry.com/en/2023/02/this-is-the-kind-of-... Anyway you’re not wrong that Rust is still a tiny portion of this kind of thing, but it is growing, and quickly. Only time will tell. (I work at a company writing firmware (and virtually everything else) in Rust, but as a startup I don’t expect that to carry as much weight as big established companies, of course.)
- Firmwarrior 4y ago
  Man oh man. I realized I'd never even seen Rust code once in my life, so I loaded up some random Rust book and skimmed through it. I know HackerNews doesn't like half-informed angry opinions, so I'll just say "I really hope Rust never takes off" and leave it at that.
  - steveklabnik 4y ago
    Not everything can be everyone's cup of tea :)
  - dralley 4y ago
    What about your brief skimming turned you off?

quelsolaar 4y ago

Lots of people are _entertaining_ Rust as an option, but that's very different from C being defecto. I don't know of a single peace of software I have used written in Rust. A lot of people have in the past had very good arguments for why their language (C++, D Java, OCaml, Objective-C) should replace C but after decades they still haven't. The C-is-dead argument predates Rust by a lot, and Rust is already 10 years old. C may at some point be replaced, but I'm not holding my breath especially given that I think Cs success is so poorly understood, especially by people who come from other languages.

jcranmer 4y ago
Sure, Rust isn't there yet; C is still undisputably the king of system languages. But it's honestly the first language to crack the chink of C's dominance in low-level programming--C no longer looks unstoppable, in a way that C++ or D never managed to achieve.
di4na 4y ago
Ever used Android? VScode? If yes, you are using software written in Rust. Fastly? Same. Python? there is a good chance you are using cryptography, which is partially in Rust. Firefox? Rust is in there. And i could keep doing, at this point it is slowly creeping everywhere :)
- Gigachad 4y ago
  Linux also contains the building blocks for loading rust modules now as I understand. And some builds like Asahi Linux contain major rust components.
  - di4na 4y ago
    Iirc AWS ship quite some rust in their hypervisor and networking stack too
AnimalMuppet 4y ago
It's like Chesterton's Fence. If you don't understand why C is used, you aren't going to be able to convince people that they ought to use something else. And you for certain are not going to be able to create a language to replace it.

tialaramex 4y ago

> My understanding of things like MISRA C is that it's almost a completely different language MISRA's rules aren't that distinct from a C coding style you've probably used if you're an experienced C programmer. Any competent C programmer can easily read and understand code that obeys the rules - it's just C, but maybe somebody with no prior experience of MISRA might trip on some of the rules because they're unnatural. For example if you like recursive code, MISRA hates that, so don't do that (call stacks are finite). If you're used to doing shenanigans with pointers (e.g. XOR linked list), MISRA hates that too, C's pointers are just magic, don't try to fiddle with them. I'd guess that 90+% of code I wrote with no intention for it to be MISRA would, in fact, pass MISRA rules or would pass with some minor tweaks. Some of MISRA's dozens of rules are forbidding stuff no sane C programmer writes unless it's for a contest or something, so you just won't hit those. Some require practices which were recommended in like the ANSI document, that's over 30 years ago, hopefully you are doing that already.

FullyFunctional 4y ago

My annecdata: my first language after BASIC was Pascal and I worked professionally for a couple of years using Turbo Pascal, yet I preferred C. I think the reasons were (in order): verbosity and flexibility. I always hated Wirth's obsession with bloated keywords. I like conciseness (though J might be jumping the shark). The latter point is just a reflection of how awkward it is to the break the rules in Pascal, which was necessary for many real-world applications. And yes, I'm also a Rust convertee (sorry haters); I can do everything I did in C in Rust and for most parts it's more readable and frankly less work. I think my biggest regret is that while I know I could write a C compiler, I don't think I could write a Rust compiler [in my lifetime].

eggy 4y ago
I love J and APL, but April takes the cake for me[1]. APL in Lisp. I also prefer SPARK2014 instead of Rust if I am not going to use C. I've started learning Rust a few times. SPARK2014 is easier to get going for me, and it has been used to produce high-integrity software and real-world applications for over a decade, and more if you include Ada from which it sprang[2]. [1] https://github.com/phantomics/april https://github.com/phantomics/april [2] https://www.adacore.com/about-spark https://www.adacore.com/about-spark
- FullyFunctional 4y ago
  April is interesting, thanks. Aside: I worked professionally in Scheme for a few years, but Haskell (and ghci) is my favorite language (thus my handle) for experimenting with non-trivial derivations and quick one-off experiments. Rust gives me some of what I love in Haskell (type classes, polymorphic types, sum types, some type inference, rich and ergonomic library, some functional style, ...) without the sad part (space leaks, unpredictable runtime, completely insane defaults from a perf POV)
  - eggy 4y ago
    I find APL and J to be functional enough and terse to a point of beauty once you get it. Look at solutions on rosettacode.org between Haskell and J or APL to get a feel for what I am saying. Rust's syntax is a turn off, but that is a personal bias against my C background once I embraced Haskell, J, APL, Forth, Lisp, etc... SPARK2014 covers me for the things Rust is striving for with a longer legacy of doing so for real world systems. It's also a simpler syntax (Ada, Pascal).