11 ms·

The "Likeability" of C is very underestimated. Many people think that system code _should_ be written in other language, but people who _want_ to actually write

The "Likeability" of C is very underestimated. Many people think that system code _should_ be written in other language, but people who _want_ to actually write, and maintain system software want to do so in C. A programming language has to be enjoyed, if someone is going to dedicated a significant part of their lives o writing opensource software in it. 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. I strongly suspect that a big reason for this is that C is enjoyable enough for maintainers stick around long enough shake out all the issues.

Gigachad 4y ago
Things have changed a lot since 2012. The Asahi Linux devs have said positive things about writing OS code in Rust. They have built a full M1 GPU driver in Rust which says a lot for the future of system code in safer languages.
galangalalgol 4y ago
Misra C is not normal likeable C. And while people have written safety critical code in normal likeable C, that isn't at all common. Ada, more recently spark, and various c++ subsets are all far more common. But yes Misra C is very common. Zig seems likeable, but I haven't tried it yet. And rust is enjoyable now that I'm into it as my daily driver. The complexity is only there if I go looking. Mostly.
- wheelerof4te 4y ago
  Isn't malloc one of prime reasons that makes C "less likeable"? I would imagine banning the use of malloc would make C easier, not harder to code in.
  - convolvatron 4y ago
    what would you replace it with? stack allocation almost everywhere and acyclic reference counting when you absolutely have to?
    - steveklabnik 4y ago
      I write Rust code without malloc equivalents. You stack allocate, you statically allocate. Anything growable either doesn’t grow, or preallocates (on the stack or statically) an upper limit and “grows” within that.
      - galangalalgol 4y ago
        Often for dsp type stuff you'd blow out the stack for the size of a time series or image buffer. I typically preallocate when the size is known and reuse. Is yhere a good way to do that statically.
        steveklabnik 4y ago
        In Rust? Simplest thing is to declare an array as a static. Mutable statics do require unsafe, because it's inherently not threadsafe, but if you wanted to stay away from that directly, just depends on what kinds of tradeoffs you're interested in making.
        galangalalgol 4y ago
        I didn't realize who I was replying to! But yes in rust. I have messed with mutable statics with a mutex and maybeuinit mostly for exporting stuff as a cdylib that has mutable state, and found I lose some of what I love about rust. So I heap allocate once and do borrows for each stage in my pipeline (SDR stuff). Sometimes a stage copies to cuda device mem, or back, or doesn't and just carries a device pointer through behind an abstraction. Is there a good reason to avoid preallocation on the heap?
        steveklabnik 4y ago
        I thought we were talking about a situation with no heap! If you have that luxury, heck yeah just call malloc.
        4y ago
  - tmtvl 4y ago
    Ban malloc, use stack only? Using C like Forth is definitely a thing someone could do.
tialaramex 4y ago
I liked C perfectly well, and for over 25 years I wrote software in it, including both Free Software you may have used and in-house software I was directly employed to write for a large corporation. However I began learning Rust back in 2021 and not only do I now not want to write any more C, I want to rewrite my C software in Rust, although obviously 25 years worth of software means that's a whole lot of work and in a few cases I don't own the rights.
jcranmer 4y ago
> 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.)
hgs3 4y ago
> The "Likeability" of C is very underestimated. I like C quite a bit for systems programming because it's design is simple, minimalistic, and cohesive - especially given its age. It does not restrict how I design my software. I'm (usually) unsurprised when reviewing the generated assembly. I wish C "successors" would show more restraint. They _usually_ fail on at least one of these points. With that said, I am keeping my eye on Zig, Hare, C3, and a few others.
- olodus 4y ago
  I very much agree. Rust has some good ideas but the more I've tried it and played with it it lacks that restraint you mentioned. Sooo many concepts, so many sub-languages for different parts. Don't get me wrong, I like the memory safety and that is an honorable goal, but I am not even sure I think ownership / uniqueness types are the best solution for that. There are so many other interesting solutions to memory safety that I think needs to be investigated and tried and I am getting a bit upset that Rust people seem so "our way is the only way"-sounding. But maybe that is just me, as I said I like some parts of the language. Like you I am looking at Zig and a few others. A recent one I that really caught my eye was Austral (which uses linear types which is the more restrained cousin to Rusts ownership for example).
erik_seaberg 4y ago
> trusted safety critical software Does that exist? Is it only found in expensive, narrow verticals? Because general purpose free or retail software has been blowing up randomly for my entire career. At this point I believe conforming C can be generated, but I doubt a human being can write much at all.

Gigachad 4y ago

Things have changed a lot since 2012. The Asahi Linux devs have said positive things about writing OS code in Rust. They have built a full M1 GPU driver in Rust which says a lot for the future of system code in safer languages.

galangalalgol 4y ago

Misra C is not normal likeable C. And while people have written safety critical code in normal likeable C, that isn't at all common. Ada, more recently spark, and various c++ subsets are all far more common. But yes Misra C is very common. Zig seems likeable, but I haven't tried it yet. And rust is enjoyable now that I'm into it as my daily driver. The complexity is only there if I go looking. Mostly.

wheelerof4te 4y ago
Isn't malloc one of prime reasons that makes C "less likeable"? I would imagine banning the use of malloc would make C easier, not harder to code in.
- convolvatron 4y ago
  what would you replace it with? stack allocation almost everywhere and acyclic reference counting when you absolutely have to?
  - steveklabnik 4y ago
    I write Rust code without malloc equivalents. You stack allocate, you statically allocate. Anything growable either doesn’t grow, or preallocates (on the stack or statically) an upper limit and “grows” within that.
    - galangalalgol 4y ago
      Often for dsp type stuff you'd blow out the stack for the size of a time series or image buffer. I typically preallocate when the size is known and reuse. Is yhere a good way to do that statically.
      - steveklabnik 4y ago
        In Rust? Simplest thing is to declare an array as a static. Mutable statics do require unsafe, because it's inherently not threadsafe, but if you wanted to stay away from that directly, just depends on what kinds of tradeoffs you're interested in making.
        galangalalgol 4y ago
        I didn't realize who I was replying to! But yes in rust. I have messed with mutable statics with a mutex and maybeuinit mostly for exporting stuff as a cdylib that has mutable state, and found I lose some of what I love about rust. So I heap allocate once and do borrows for each stage in my pipeline (SDR stuff). Sometimes a stage copies to cuda device mem, or back, or doesn't and just carries a device pointer through behind an abstraction. Is there a good reason to avoid preallocation on the heap?
        steveklabnik 4y ago
        I thought we were talking about a situation with no heap! If you have that luxury, heck yeah just call malloc.
        4y ago
- tmtvl 4y ago
  Ban malloc, use stack only? Using C like Forth is definitely a thing someone could do.

tialaramex 4y ago

I liked C perfectly well, and for over 25 years I wrote software in it, including both Free Software you may have used and in-house software I was directly employed to write for a large corporation. However I began learning Rust back in 2021 and not only do I now not want to write any more C, I want to rewrite my C software in Rust, although obviously 25 years worth of software means that's a whole lot of work and in a few cases I don't own the rights.

jcranmer 4y ago

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

hgs3 4y ago

> The "Likeability" of C is very underestimated. I like C quite a bit for systems programming because it's design is simple, minimalistic, and cohesive - especially given its age. It does not restrict how I design my software. I'm (usually) unsurprised when reviewing the generated assembly. I wish C "successors" would show more restraint. They _usually_ fail on at least one of these points. With that said, I am keeping my eye on Zig, Hare, C3, and a few others.

olodus 4y ago
I very much agree. Rust has some good ideas but the more I've tried it and played with it it lacks that restraint you mentioned. Sooo many concepts, so many sub-languages for different parts. Don't get me wrong, I like the memory safety and that is an honorable goal, but I am not even sure I think ownership / uniqueness types are the best solution for that. There are so many other interesting solutions to memory safety that I think needs to be investigated and tried and I am getting a bit upset that Rust people seem so "our way is the only way"-sounding. But maybe that is just me, as I said I like some parts of the language. Like you I am looking at Zig and a few others. A recent one I that really caught my eye was Austral (which uses linear types which is the more restrained cousin to Rusts ownership for example).

erik_seaberg 4y ago

> trusted safety critical software Does that exist? Is it only found in expensive, narrow verticals? Because general purpose free or retail software has been blowing up randomly for my entire career. At this point I believe conforming C can be generated, but I doubt a human being can write much at all.