6 ms·

As someone who writes, reviews, and maintains lots of C code professionally, here’s what I think a lot of Rust advocates don’t understand: We see and understand

As someone who writes, reviews, and maintains lots of C code professionally, here’s what I think a lot of Rust advocates don’t understand: We see and understand the benefits of Rust. That’s no longer something we need to be sold on. Every C programmer who’s written and reviewed any amount of nontrivial C code likely has firsthand experience dealing with memory safety bugs that would simply disappear with a memory-safe language. The ultimate problem is that most of the muscle memory you’ve built using C over the years becomes useless when writing Rust due to so many of the semantic differences. If you were an expert and highly productive C programmer, your productivity will go out the window for what feels like a long time until you feel even just comfortable writing Rust. That makes Rust a very hard sell for C programmers who simply want to get things done. This is an area, by the way, that I think Zig does extremely well at—it provides safer semantics (despite its lack of guaranteed memory safety à la Rust) in a rather simple language and without rendering so much of your experience useless.

empath75 2y ago
This is a problem that will resolve itself with time as C developers retire and new projects start in Rust.
- doe_eyes 2y ago
  C is 52 years old; C++ is nearly 40. That's more than a generation. Yet, I'd bet that there are more up-and-coming developers learning C/C++ than Rust today. The problem isn't just personal preference or inertia. It's that all mainstream OSes, libraries, and system software are written in C/C++. You can't exactly ignore this and not learn the language if you want to work in this space. Of course, there are many developers who don't work with system-level stuff, and they may be perfectly fine just knowing Java or JavaScript, but Rust is not positioning itself as a direct competitor to that.
  - xelamonster 2y ago
    How is "too much existing software uses C/C++" not just inertia? That can also change with time.
    - doe_eyes 2y ago
      Inertia is doing things because you're used to doing them. This is pragmatism: until the arrival of mainstream Rust-based OSes, there's probably no escaping C/C++.
      - xelamonster 2y ago
        My point is that the arrival of Rust-based OSes is absolutely in the cards, so while I don't disagree that it would be very difficult to fully escape at the moment that is also actively changing.
  - MBCook 2y ago
    The world has lots of important COBOL. You’re dead on. Even if everyone committed to all new code in Rust tomorrow, C/C++ will be around for a LONG time. There’s just too much pre-existing code.
- jay-barronville 2y ago
  > This is a problem that will resolve itself with time as C developers retire and new projects start in Rust. Respectfully, this is wishful thinking. C programmers aren’t going anywhere any time soon. There are millions upon millions upon millions lines of C code everywhere running critical software, firmware, infrastructure, etc. that won’t be rewritten in Rust any time soon.
  - mav3ri3k 2y ago
    From my perspective (college student), it is true that there is godly amount of C code in the world which would remain true for a long long time. In similar sense there are also quite a lot of new java developers who maintain the millions of lines of java code. However a lot of new infrastructure is being developed in rust. Infact it can be argued that the very reason it should be in rust is because it is critical. I think there would be great value if a person can efficiently thread between both rust and c rather than competing.
    - fuckrabs 2y ago
      [flagged]
      - MBCook 2y ago
        The entire graphics driver for Apple Silicon Macs in Linux, with zero memory bugs in the code despite being deployed to a large number of machines. including a fully conformant OpenGL implementation and most/all of Vulkan (I’ve lost track of the current state).
    - MBCook 2y ago
      Java is not an old “maintain the code” language as you seem to imply. Despite not being the new hotness for about 25 years it’s an extremely useful and productive language and I assure you there are tons and tons of new things being written in it every day. The language is still evolving and has been getting great improvements. Yeah it has some warts, but it’s been running and keeping backwards compatibility for 30 years despite evolving.
dwattttt 2y ago
Speaking as someone who has written C skirting both sides of the UB line & referenced the spec to see when something tipped too far over said line... The fear that I'd be less productive for a "long" time was quite overblown. Rust hasn't replaced all the C I write, why should it? It's replaced lots of C I wrote around the periphery of the hairiest stuff, and frankly done it better than the C I might otherwise have written there.
- jay-barronville 2y ago
  > The fear that I'd be less productive for a "long" time was quite overblown. I’m genuinely glad that was your experience! I actually would love for more C programmers to have that same experience (or better), but my own experience with Rust and the experiences of many of my colleagues is that going from C as someone who’s productive with it to Rust entails at least a couple months just to get comfortable with the language and its semantics. One could argue that spending that time is worth it for the memory safety benefits and I’d probably agree, but I’m just pointing out that it’s a pretty hard sell for many C programmers.
  - nixpulvis 2y ago
    Who are these C programmers who are a hard sell on this? Any C programmer who knows how to write working code knows a lot of Rust’s rules implicitly because they have to deal with it manually! What C programmer hears, “you can heap allocate without a GC and the compiler will place frees for you” and thinks, gosh… this sounds irritating? Or what C programmer hears, “we make using multiple mutable references to the same data at the same time something only unsafe rust can do” and thinks, gosh… I do that all the time, and I have no issues? I think the bigger issue is convincing people it’s worth the energy and risk to port existing, working, and tested C code.
    - charleslmunger 2y ago
      >What C programmer hears, “you can heap allocate without a GC and the compiler will place frees for you” and thinks, gosh… this sounds irritating? People who still use C rather than C++, which has this exact feature? https://open.substack.com/pub/ryanfleury/p/untangling-lifetimes-the-arena-allocator?selection=82423c75-d382-4020-b867-4e4b8a81b10c https://open.substack.com/pub/ryanfleury/p/untangling-lifeti...
nixpulvis 2y ago
Could you give an example of how Zig is more C-like for the seasoned C developer? Rust generally has a lot of what C has, you just might need unsafe to get it. One notable omission is `volatile` but that sorta beside the point. If the concern is just relearning a new STD lib and getting used to error handling with an enum instead of ints, then I suspect you could get up to speed pretty quickly. Past that, sure the rust crate ecosystem might make use of a lot more complex bits of rust, just like C++ libraries can do wild things with templating. If you are just comparing C, just avoid the complex stuff and write your Rust function like you write your C functions. It’ll work.
- bschwindHN 2y ago
  > One notable omission is `volatile` but that sorta beside the point. What do you mean here?
  - nixpulvis 2y ago
    Basically this note: https://doc.rust-lang.org/std/ptr/fn.write_volatile.html#notes https://doc.rust-lang.org/std/ptr/fn.write_volatile.html#not...
    - bschwindHN 2y ago
      I see, thanks!
- wtetzner 2y ago
  You can use methods in Rust for volatile reads/writes. https://doc.rust-lang.org/std/ptr/fn.write_volatile.html https://doc.rust-lang.org/std/ptr/fn.write_volatile.html https://doc.rust-lang.org/std/ptr/fn.read_volatile.html https://doc.rust-lang.org/std/ptr/fn.read_volatile.html
pveierland 2y ago
Having written quite a bit of C++ firmware and just now spending a few weeks getting into Rust, I have to say the learning curve was less challenging than I thought it would be, and that I feel pretty effective after a short amount of time. The feeling of how sturdy the program is after getting the additional compiler support during development feels very reassuring. Already at this point I'm hoping that I never need to write C++ again, as the complexity of the language is maddening and only increasing. (I've only spent a few days on Zig and it was also a very fresh breeze).
- MBCook 2y ago
  My question would be is the learning curve better or worse than, say, Swift? If the curve is small moving from A to B can make a lot of sense. Rust is an obvious possible successor. But as the curve gets bigger maybe looking at less obvious choices makes more sense. Maybe even a language with a runtime or VM like Java if you’re not doing low level programming like Google is in this post. Swift is a strawman here. I know it’s probably not there for large non-Apple adoption today, but pretend it was
  - pveierland 2y ago
    I wouldn't be able to answer for Swift as I don't know it. However Rust would seem to be a suitable replacement for all use-cases of C++ in an embedded context that I was involved with (including allocation control + static initialization + macro usage).
  - redman25 2y ago
    Rust can be written simply if you avoid more complicated features of the language. It depends on what you want to get out of it. If you want to develop a library, you might have to dig into more complicated features in order to provide a convenient interface for users. If you want to build an API, using a web framework is simple and doesn’t require understanding the more complicated parts of the language.
csomar 2y ago
So you are saying we should stick to the status quo because, otherwise, some C developers have to adapt and might lose their competitive advantage because of it?
- jay-barronville 2y ago
  > So you are saying we should stick to the status quo because, otherwise, some C developers have to adapt and might lose their competitive advantage because of it? Can you point me to where I said or suggested any of that?
ycombinatrix 2y ago
Rust doesn't require nearly as much muscle memory as C.
selfmodruntime 2y ago
> The ultimate problem is that most of the muscle memory you’ve built using C over the years becomes useless when writing Rust due to so many of the semantic differences The horror. Lest someone make an argument that to earn a salary, you have to put in hard work.
- jay-barronville 2y ago
  > The horror. Lest someone make an argument that to earn a salary, you have to put in hard work. To quote the HN guidelines [0]: > Be kind. Don't be snarky. Converse curiously; don't cross-examine. Edit out swipes. > Please respond to the strongest plausible interpretation of what someone says, not a weaker one that's easier to criticize. Assume good faith. [0]: https://news.ycombinator.com/newsguidelines.html https://news.ycombinator.com/newsguidelines.html
  - selfmodruntime 2y ago
    You're correct. A slip of etiquette.
mplanchard 2y ago
Rust interoperability with C is excellent, way easier than with C++, which is also pretty easy. I think if you’re a good C programmer you’ll naturally be a good Rust programmer, and come up to speed faster than you expect. There’s nothing forcing you to write everything with traits, generics, etc. You can write simple, fast, safe Rust without them. Edit: read some of your other comments and realize this doesn’t quite address your point, but I do still think that writing small sections of logic in simple, straightforward Rust and then calling that from C is a nice way to get started. Doing so for places where ownership is complicated and the compiler can help enforce invariants can provide I think a meaningful ergonomic gain in a C codebase.
pornel 2y ago
Productivity tanks only temporarily. I know that writing your first 10 lines of Rust code will give you 15 novel compile errors, and that feels like it's impossible to get anything done in Rust, but once you get over the hump, you get to use a very productive modern language that can be as low-level as C, and almost as high-level as Python, at the same time. You will not regret leaving behind the muscle memory for all the preprocessor tricks, workarounds for gratuitous platform differences and 40-year-old footguns, all the trivia for old compilers, the never ending tweaking of snowflake build scripts, and the skill of writing yet another half-assed hash table with your eyes closed. You'll wonder how you ever got anything done in a language that kept you busy calculating malloc sizes by hand.

empath75 2y ago

This is a problem that will resolve itself with time as C developers retire and new projects start in Rust.

doe_eyes 2y ago
C is 52 years old; C++ is nearly 40. That's more than a generation. Yet, I'd bet that there are more up-and-coming developers learning C/C++ than Rust today. The problem isn't just personal preference or inertia. It's that all mainstream OSes, libraries, and system software are written in C/C++. You can't exactly ignore this and not learn the language if you want to work in this space. Of course, there are many developers who don't work with system-level stuff, and they may be perfectly fine just knowing Java or JavaScript, but Rust is not positioning itself as a direct competitor to that.
- xelamonster 2y ago
  How is "too much existing software uses C/C++" not just inertia? That can also change with time.
  - doe_eyes 2y ago
    Inertia is doing things because you're used to doing them. This is pragmatism: until the arrival of mainstream Rust-based OSes, there's probably no escaping C/C++.
    - xelamonster 2y ago
      My point is that the arrival of Rust-based OSes is absolutely in the cards, so while I don't disagree that it would be very difficult to fully escape at the moment that is also actively changing.
- MBCook 2y ago
  The world has lots of important COBOL. You’re dead on. Even if everyone committed to all new code in Rust tomorrow, C/C++ will be around for a LONG time. There’s just too much pre-existing code.
jay-barronville 2y ago
> This is a problem that will resolve itself with time as C developers retire and new projects start in Rust. Respectfully, this is wishful thinking. C programmers aren’t going anywhere any time soon. There are millions upon millions upon millions lines of C code everywhere running critical software, firmware, infrastructure, etc. that won’t be rewritten in Rust any time soon.
- mav3ri3k 2y ago
  From my perspective (college student), it is true that there is godly amount of C code in the world which would remain true for a long long time. In similar sense there are also quite a lot of new java developers who maintain the millions of lines of java code. However a lot of new infrastructure is being developed in rust. Infact it can be argued that the very reason it should be in rust is because it is critical. I think there would be great value if a person can efficiently thread between both rust and c rather than competing.
  - fuckrabs 2y ago
    [flagged]
    - MBCook 2y ago
      The entire graphics driver for Apple Silicon Macs in Linux, with zero memory bugs in the code despite being deployed to a large number of machines. including a fully conformant OpenGL implementation and most/all of Vulkan (I’ve lost track of the current state).
  - MBCook 2y ago
    Java is not an old “maintain the code” language as you seem to imply. Despite not being the new hotness for about 25 years it’s an extremely useful and productive language and I assure you there are tons and tons of new things being written in it every day. The language is still evolving and has been getting great improvements. Yeah it has some warts, but it’s been running and keeping backwards compatibility for 30 years despite evolving.

dwattttt 2y ago

Speaking as someone who has written C skirting both sides of the UB line & referenced the spec to see when something tipped too far over said line... The fear that I'd be less productive for a "long" time was quite overblown. Rust hasn't replaced all the C I write, why should it? It's replaced lots of C I wrote around the periphery of the hairiest stuff, and frankly done it better than the C I might otherwise have written there.

jay-barronville 2y ago
> The fear that I'd be less productive for a "long" time was quite overblown. I’m genuinely glad that was your experience! I actually would love for more C programmers to have that same experience (or better), but my own experience with Rust and the experiences of many of my colleagues is that going from C as someone who’s productive with it to Rust entails at least a couple months just to get comfortable with the language and its semantics. One could argue that spending that time is worth it for the memory safety benefits and I’d probably agree, but I’m just pointing out that it’s a pretty hard sell for many C programmers.
- nixpulvis 2y ago
  Who are these C programmers who are a hard sell on this? Any C programmer who knows how to write working code knows a lot of Rust’s rules implicitly because they have to deal with it manually! What C programmer hears, “you can heap allocate without a GC and the compiler will place frees for you” and thinks, gosh… this sounds irritating? Or what C programmer hears, “we make using multiple mutable references to the same data at the same time something only unsafe rust can do” and thinks, gosh… I do that all the time, and I have no issues? I think the bigger issue is convincing people it’s worth the energy and risk to port existing, working, and tested C code.
  - charleslmunger 2y ago
    >What C programmer hears, “you can heap allocate without a GC and the compiler will place frees for you” and thinks, gosh… this sounds irritating? People who still use C rather than C++, which has this exact feature? https://open.substack.com/pub/ryanfleury/p/untangling-lifetimes-the-arena-allocator?selection=82423c75-d382-4020-b867-4e4b8a81b10c https://open.substack.com/pub/ryanfleury/p/untangling-lifeti...

nixpulvis 2y ago

Could you give an example of how Zig is more C-like for the seasoned C developer? Rust generally has a lot of what C has, you just might need unsafe to get it. One notable omission is `volatile` but that sorta beside the point. If the concern is just relearning a new STD lib and getting used to error handling with an enum instead of ints, then I suspect you could get up to speed pretty quickly. Past that, sure the rust crate ecosystem might make use of a lot more complex bits of rust, just like C++ libraries can do wild things with templating. If you are just comparing C, just avoid the complex stuff and write your Rust function like you write your C functions. It’ll work.

bschwindHN 2y ago
> One notable omission is `volatile` but that sorta beside the point. What do you mean here?
- nixpulvis 2y ago
  Basically this note: https://doc.rust-lang.org/std/ptr/fn.write_volatile.html#notes https://doc.rust-lang.org/std/ptr/fn.write_volatile.html#not...
  - bschwindHN 2y ago
    I see, thanks!
wtetzner 2y ago
You can use methods in Rust for volatile reads/writes. https://doc.rust-lang.org/std/ptr/fn.write_volatile.html https://doc.rust-lang.org/std/ptr/fn.write_volatile.html https://doc.rust-lang.org/std/ptr/fn.read_volatile.html https://doc.rust-lang.org/std/ptr/fn.read_volatile.html

pveierland 2y ago

Having written quite a bit of C++ firmware and just now spending a few weeks getting into Rust, I have to say the learning curve was less challenging than I thought it would be, and that I feel pretty effective after a short amount of time. The feeling of how sturdy the program is after getting the additional compiler support during development feels very reassuring. Already at this point I'm hoping that I never need to write C++ again, as the complexity of the language is maddening and only increasing. (I've only spent a few days on Zig and it was also a very fresh breeze).

MBCook 2y ago
My question would be is the learning curve better or worse than, say, Swift? If the curve is small moving from A to B can make a lot of sense. Rust is an obvious possible successor. But as the curve gets bigger maybe looking at less obvious choices makes more sense. Maybe even a language with a runtime or VM like Java if you’re not doing low level programming like Google is in this post. Swift is a strawman here. I know it’s probably not there for large non-Apple adoption today, but pretend it was
- pveierland 2y ago
  I wouldn't be able to answer for Swift as I don't know it. However Rust would seem to be a suitable replacement for all use-cases of C++ in an embedded context that I was involved with (including allocation control + static initialization + macro usage).
- redman25 2y ago
  Rust can be written simply if you avoid more complicated features of the language. It depends on what you want to get out of it. If you want to develop a library, you might have to dig into more complicated features in order to provide a convenient interface for users. If you want to build an API, using a web framework is simple and doesn’t require understanding the more complicated parts of the language.

csomar 2y ago

So you are saying we should stick to the status quo because, otherwise, some C developers have to adapt and might lose their competitive advantage because of it?

jay-barronville 2y ago
> So you are saying we should stick to the status quo because, otherwise, some C developers have to adapt and might lose their competitive advantage because of it? Can you point me to where I said or suggested any of that?

ycombinatrix 2y ago

Rust doesn't require nearly as much muscle memory as C.

selfmodruntime 2y ago

> The ultimate problem is that most of the muscle memory you’ve built using C over the years becomes useless when writing Rust due to so many of the semantic differences The horror. Lest someone make an argument that to earn a salary, you have to put in hard work.

jay-barronville 2y ago
> The horror. Lest someone make an argument that to earn a salary, you have to put in hard work. To quote the HN guidelines [0]: > Be kind. Don't be snarky. Converse curiously; don't cross-examine. Edit out swipes. > Please respond to the strongest plausible interpretation of what someone says, not a weaker one that's easier to criticize. Assume good faith. [0]: https://news.ycombinator.com/newsguidelines.html https://news.ycombinator.com/newsguidelines.html
- selfmodruntime 2y ago
  You're correct. A slip of etiquette.

mplanchard 2y ago

Rust interoperability with C is excellent, way easier than with C++, which is also pretty easy. I think if you’re a good C programmer you’ll naturally be a good Rust programmer, and come up to speed faster than you expect. There’s nothing forcing you to write everything with traits, generics, etc. You can write simple, fast, safe Rust without them. Edit: read some of your other comments and realize this doesn’t quite address your point, but I do still think that writing small sections of logic in simple, straightforward Rust and then calling that from C is a nice way to get started. Doing so for places where ownership is complicated and the compiler can help enforce invariants can provide I think a meaningful ergonomic gain in a C codebase.

pornel 2y ago

Productivity tanks only temporarily. I know that writing your first 10 lines of Rust code will give you 15 novel compile errors, and that feels like it's impossible to get anything done in Rust, but once you get over the hump, you get to use a very productive modern language that can be as low-level as C, and almost as high-level as Python, at the same time. You will not regret leaving behind the muscle memory for all the preprocessor tricks, workarounds for gratuitous platform differences and 40-year-old footguns, all the trivia for old compilers, the never ending tweaking of snowflake build scripts, and the skill of writing yet another half-assed hash table with your eyes closed. You'll wonder how you ever got anything done in a language that kept you busy calculating malloc sizes by hand.