10 ms·

Rust is not a good C replacement (2019)

59 points by letientai299 6y ago

steveklabnik 6y ago
Three months ago: https://news.ycombinator.com/item?id=23343507 https://news.ycombinator.com/item?id=23343507 A year ago: https://news.ycombinator.com/item?id=19482669 https://news.ycombinator.com/item?id=19482669
Koshkin 6y ago
"Oh say, can you C?" "In Rust We Trust."
- ColanR 6y ago
  Very clever, but off topic. :)
joey_loey89 6y ago
I don't think anyone is seriously claiming that rust is a replacement for C.
batsigner 6y ago
This post is just decompressed twitter trolling.
jolux 6y ago
Parallelism is too hard in C, easier in Go, but Rust makes it too easy and is therefore poorly designed? What kind of an argument is this?
- Animats 6y ago
  Yes. I have criticisms of Rust, but not that one. We have to go parallel for things that need speed. CPUs are not getting faster, but we have far more cores. Now this is more of a problem: - C: 0.73 new features per year - Go: 2 new features per year - C++: 11.3 new features per year - Rust: 15 new features per year Rust is now stable enough that you can recompile old programs from a few years ago, but more and more features are being added and the ideomatic usage keeps changing. The borrow checker was brilliant. The rest of the language, not so much. A point that doesn't get discussed enough is threading models. Go has "green threads" - no need for a distinction between threading and "async". Python and Rust started with threads, and are having "async" bashed into the language as an afterthought. "Green threads" have been around for years, but Go seems to be the first language where they really took off. This may reflect the use case. Go is optimized for big web servers talking to huge numbers of clients, which is what Google does all day.
  - jcranmer 6y ago
    The feature comparison is bullshit because the author uses different methodologies to count the features of Rust compared to the other three languages. For the other languages, it's count the bullet points in a list of new features; for Rust, it's count the bullet points in release notes. (And the methodology isn't clear as to whether it's limiting to language features, or including both library and language features) > Python and Rust started with threads, and are having "async" bashed into the language as an afterthought. Rust started with green threads, but they were removed pre-1.0 for reasons that I'm sure steveklabnik can jump in and explain.
    - steveklabnik 6y ago
      Yeah, I would strongly disagree with "bashed into the language as an afterthought" Here is a very lengthy explanation of the reasons: https://www.infoq.com/presentations/rust-2019/ https://www.infoq.com/presentations/rust-2019/
  - mumblemumble 6y ago
    > We have to go parallel for things that need speed. That really depends on the kind of speed you need. I have, in my brief time on this planet, accomplished each of the following at least once: Sped up a concurrent implementation by making it parallel. Sped up a concurrent implementation by making it sequential. Sped up a parallel implementation by making it concurrent. Sped up a parallel implementation by making it sequential. Sped up a sequential implementation by making it concurrent. Sped up a sequential implementation by making it parallel. The 2nd and 4th ones are often the easiest to accomplish. Amdahl's law is a great rule of thumb, but it subtly implies an idealized world where both the transition between sequential and parallelizable sections of the process, and the communication among parallel sections, happen at zero cost. The real world is messy, though, so, in practice, they can get pretty expensive. Parallelism can slow things down by introducing extra copying, memory access, memory fences, conditional branches, etc. You've got to dig yourself out of that hole before you can realize any gains. To the extent that the term "order of magnitude" often comes into play when describing the sizes of delays these things can cause, it can be a pretty deep hole.
  - 6y ago
hitekker 6y ago
I wonder how the author views Zig as a C replacement.
lights0123 6y ago
> Cargo is mandatory. On a similar line of thought, Rust’s compiler flags are not stable. Attempts to integrate it with other build systems have been met with hostility from the Rust & Cargo teams. The outside world exists, and us systems programmers spend a lot of our time integrating things. Rust refuses to play along. Linux kernel maintainers doesn't want to use Cargo in the kernel ("Agreed, I wrote one ~half a year ago that compiled TUs through rustc mimicking what we do with cc to some degree (i.e. no cargo etc.), and it was quite pleasant." [1]), and there hasn't really been much opposition to that by the Rust team. > However, nearly all programs needn’t be parallel. A program which uses poll effectively is going to be simpler, reasonably performant, and have orders of magnitude fewer bugs. “Fearless concurrency” allows you to fearlessly employ bad software design 9 times out of 10. Sure, if you don't care about performance, which may very well be the case in many situations. However, the reality is that modern CPUs get their performance from multi-core workloads, requiring you to do things in parallel. Go does have some nice bits (e.g. no fragmentation between Tokio and smol, no need to separate code between async and non-async versions), but you don't explain what those are in depth. > I especially refuse to “rewrite it in Rust” Sure—that's mostly just a meme[2], which many people in the Rust world acknowledge is a bad thing[3]. [1]: https://lore.kernel.org/lkml/CAKwvOdmuYc8rW_H4aQG4DsJzho=F+djd68fp7mzmBp3-wY--Uw@mail.gmail.com/T/#u https://lore.kernel.org/lkml/CAKwvOdmuYc8rW_H4aQG4DsJzho=F+d... [2]: https://www.reddit.com/r/rustjerk/comments/av5pog/higherres_rust_evangelism_strike_force_image/ https://www.reddit.com/r/rustjerk/comments/av5pog/higherres_... [3]: https://www.reddit.com/r/rust/comments/ifkrvg/i_printed_rewrite_it_in_rust_swag_for_students/g2s1bh9 https://www.reddit.com/r/rust/comments/ifkrvg/i_printed_rewr...
- ColanR 6y ago
  > “rewrite it in Rust”...which many people in the Rust world acknowledge is a bad thing I've seen "rewrite it in Rust" mentioned plenty, even on HN; in fact, that meme colored much of my initial impression of Rust before I learned anything about it directly. I think the maintainers and the Rust world in general need to address that meme head on if they don't want it to be part of how Rust is known. Otherwise, as it stands currently, Rust is the language that's trying to replace C and rewrite everything that is C in Rust.
dathinab 6y ago
How often does this get rehashed? This is at least the third maybe forth time the article is in the top charts. I don't feel even like posting my opinion anymore.
- czzr 6y ago
  It’s not a job, you don’t have to feel bad about that ;-)
  - dathinab 6y ago
    Sure ;) it's just a topic I'm normally likely to comment on as I both respect Drew a lot for the work he does but at the same time disagree a lot with what he thinks about programming languages.
axegon_ 6y ago
I honestly don't think anyone suggests dropping C in favor of Rust. Make no mistake, I love Rust and I think it's the best language that's been developed in this century. Firstly, C is where it is because it's well established and has solid foundations and it has remained pretty much unchanged for decades. Rust on the other hand is changing rapidly and fast, which is something you wouldn't want for a language that powers your kernel Secondly, the Rust community is painfully small. Thirdly, Rust lives in the LLVM world and I don't see it coming into the GCC world anytime soon. Which is a huge problem, as far as replacing C goes(namely licencing might be problematic in some cases). Lastly Rust, in terms of it's nature, is more closely related to C++ rather than C. If Rust was to replace something, it has a much better chance against C++ than C. I truly want to see the day I open up linkedin, go to the jobs section, type in rust and see 6000 new job offers. But at this point in doubt this day will ever come.
- steveklabnik 6y ago
  > Thirdly, Rust lives in the LLVM world and I don't see it coming into the GCC world anytime soon. You may be surprised... we'll see, and it very much depends on what you mean by "soon," but there have been some interesting rumblings here.
- ausjke 6y ago
  mostly true. it took me a while to decide, I eventually picked up c++. modern c++ is very different nowadays, and it keeps evolving fast, to some extent many modern languages are having the same new features, c++ is becoming better and better for each new standard release, and g++/clang++ also keep up with new sanitizer, static analysis, excellent warning optional flags etc, in fact it is now very hard to make those stupid mistakes these days with modern c++ in a good IDE(even vim with the right configuration). I will keep my eye on rust, I use a few rust utilities myself, but for the heavy duty of my carerr, c/c++ remains to the the top choice.
  - saagarjha 6y ago
    C++ does however still leave the door open for the not-so-stupid mistakes that are still memory safety issues ;)
solidsnack9000 6y ago
It might be that the only real C replacement in the author's sense is a language of annotations/validations and idioms for C. How else would you get everything that C has now -- the compiler support, the well-tire-kicked-spec, the ABI, the low feature-rate and concomitant unchanging character -- besides basically just being C with some minor (and unchanging) addenda? The weird thing about Go relative to all this is the fact that interoperates so poorly with C.
kstrauser 6y ago
The reverse is also true: C isn't a good replacement for Rust. Between Rust and Go, I can't see myself plausibly starting a new project in C ever again. Contributing to existing C projects? Sure! But for me, today, C has little appeal other than being compatible with itself. In any situation where C compatibility isn't a requirement, I don't feel like it has anything to offer me.
- pornel 6y ago
  Rust has been a fantastic C replacement for me. I have all the control and performance I wanted from C. Despite Rust being a "bigger" language, it's simpler to use, because it takes care of things for me, instead of relying on me to handle every tedious detail. It is more portable than C was for me. I don't need to support exotic DSP platforms, but I do need to support Windows. Now I don't have to spoon-feed MSVC, and I don't need to answer endless support tickets about the build system.
  - kstrauser 6y ago
    That's been my experience, too. It's the little things, like having a built-in HashMap data structure, that I find to be so time saving. Data ownership took a bit of getting use to, but the compiler gives wonderful human-readable suggestions for how to fix errors that pop up, and now I don't have to spend a lot of time reasoning through every decision I've made to make sure I'm not leaking or clobbering memory all over the place.
rafaelvasco 6y ago
Don't think there's any good C replacements. There are great alternatives, with advantages and compromises.
smt88 6y ago
This seems like attacking a straw man. Rust can be a good C alternative, which is all I've ever seen Rust people promise it to be. C is far too widely used/supported to be replaced. A small minority of libraries will be rewritten in Rust, but mostly we'll see new projects that have their own namespaces.
marcosdumay 6y ago
Hum... Of course, Rust is very different from C. I don't think anyone disagrees. But a "C replacement" doesn't mean "something similar to C", it means "something that solves the same problems as C". Rust doesn't excel on all the problems that C excels at, but it does for a lot of them. So it is a partial replacement, and isn't at all a total replacement.
- bluejekyll 6y ago
  At the moment I believe C excels at portability to uncommon CPU architectures. It also excels at ABI stability. Are there other areas where you believe C excels vs. Rust?
CalChris 6y ago
Concurrency is generally a bad thing and specifically it is a good thing.
discardable_dan 6y ago
The discussions about a lack of specification are, I think, the largest and most-relevant. Someone in an earlier discussion mentioned the Rust Reference [1], but it is not sufficient: in particular, many portions of the memory model, calling conventions, and borrow-checking enforcement are left unspecified. Rust's guarantees are built on these, and they are currently defined by the current rustc implementation. Until a complete and detailed standard is published, Rust will not have a stable AI, and cannot enjoy multiple implementations (which inhibits its portability). Even the bit about Cargo stems from this: without a specification, Cargo's implementation is the de facto explanation for to properly link external, compiled libraries against rust binaries. As Rust matures, I anticipate many of these things will stop being the case---and I really hope someone gets around to writing a different Rust compiler, using pattern-matched ASTS like you would in OCaml, instead of the current, visitor-based solution. 1. https://doc.rust-lang.org/1.0.0/reference.html https://doc.rust-lang.org/1.0.0/reference.html
- lights0123 6y ago
  Note that you linked to the Rust Reference from 2015: the living version lives at https://doc.rust-lang.org/reference/ https://doc.rust-lang.org/reference/.
- the8472 6y ago
  > calling conventions Afaik that's intentionally unspecified/implementation-specific so that the language can evolve. The C ABI is the de-facto interoperability layer. > the memory model According to the rustonomicon they're leaning entirely on the C++20 memory model at the moment.
- steveklabnik 6y ago
  > Until a complete and detailed standard is published, Rust will not have a stable AI, and cannot enjoy multiple implementations (which inhibits its portability). This is not really true; we already have one alternative implementation that's good enough to compile the compiler, though it is not complete yet. Also, the gcc folks are interested in getting Rust in, and a formal specification is not a roadblock for them. > Even the bit about Cargo stems from this: without a specification, Cargo's implementation is the de facto explanation for to properly link external, compiled libraries against rust binaries. This is not true; this interface to the compiler is stable.
Paul-ish 6y ago
Whatever replaces C, if it is replaced, won't be C.
MaxBarraclough 6y ago
> Go is the result of C programmers designing a new programming language, and Rust is the result of C++ programmers designing a new programming language”. This isn’t just a metaphor - Go was designed by plan9 alumni That may be true, but Go has a garbage-collector, and Rust does not. Garbage-collection strikes me as being against the principles of both C and C++, but especially C. Drew makes some solid points about the merits of C, even despite its considerable downsides, but I have to agree with others here that rewriting in Rust is rarely what people are advocating. Writing new systems in Rust, is usually the point. Mandatory link to the Spolsky article, Things You Should Never Do, on why you probably shouldn't throw out working code. [0] > Rust will eventually fail to the “jack of all trades, master of none” problem that C++ has. Ok, but C++ has been incredibly successful, and it outcompetes C in many domains, just about everything but kernel programming and embedded programming. C++ isn't completely out of the running even there. Versatility is a feature. Also, Drew (the SourceHut guy, if anyone missed it) has a good sense for minimalist web design. There's no fat on that page. A refreshing change. [0] https://www.joelonsoftware.com/2000/04/06/things-you-should-never-do-part-i/ https://www.joelonsoftware.com/2000/04/06/things-you-should-...
- deleted 6y ago
  [deleted]
- erik_seaberg 6y ago
  > why you probably shouldn't throw out working code. Linux crashes, Windows bluescreens, Emacs crashes, GCC crashes. Do we have any C that works? I hear good things about seL4 but that was mostly using C as a compilation target from Haskell.
- Gibbon1 6y ago
  Offhand thought is there are two ways to skin the cat vs safety. Go and Rust put hard limits on what will compile and especially rust run a whole bunch of checks to enforce book keeping. In C if you are doing things right you run those checks as a separate process. And you only do it once you are done with a dev cycle, not every time you compile the program.
almostdeadguy 6y ago
If you take this argument seriously enough there's a level of specificity about the salient features of C (or any language) where you can say "nothing is a replacement for C, because it isn't C". Is C's degree of portability important for a C replacement? Depends on the project we're talking about and the platforms it needs to support. We can go down the line w/ these arguments (some of which like "concurrency is a bad thing" and "I don't care about safety" aren't even serious). I'm also surprised that in 2020 (or 2019 as this was written) we have engineers making a serious argument that specifications are inviolable laws. They do in fact help, but there are more considerations to make about a project's commitments to reasonable, expected behavior than just "there's a spec" (and in fact C has more guardrails supporting those commitments than a spec). I agree that there's a rust contingent that is over-eager to rewrite and may be oblivious to the concerns of a project or broader technical implications involved in pulling rust into a project. That being said, this reads more like a "get off my lawn", oblivious tirade about the "cult of the new" than a serious attempt to address these instances.
codygman 6y ago
> Consider Go, ... addressing them with the simplest solution possible. Go code doesn't result in the simplest solution possible.

59 points by letientai299 6y ago

Three months ago: https://news.ycombinator.com/item?id=23343507 https://news.ycombinator.com/item?id=23343507 A year ago: https://news.ycombinator.com/item?id=19482669 https://news.ycombinator.com/item?id=19482669

Koshkin 6y ago

"Oh say, can you C?" "In Rust We Trust."

ColanR 6y ago
Very clever, but off topic. :)

joey_loey89 6y ago

I don't think anyone is seriously claiming that rust is a replacement for C.

batsigner 6y ago

This post is just decompressed twitter trolling.

jolux 6y ago

Parallelism is too hard in C, easier in Go, but Rust makes it too easy and is therefore poorly designed? What kind of an argument is this?

Animats 6y ago
Yes. I have criticisms of Rust, but not that one. We have to go parallel for things that need speed. CPUs are not getting faster, but we have far more cores. Now this is more of a problem: - C: 0.73 new features per year - Go: 2 new features per year - C++: 11.3 new features per year - Rust: 15 new features per year Rust is now stable enough that you can recompile old programs from a few years ago, but more and more features are being added and the ideomatic usage keeps changing. The borrow checker was brilliant. The rest of the language, not so much. A point that doesn't get discussed enough is threading models. Go has "green threads" - no need for a distinction between threading and "async". Python and Rust started with threads, and are having "async" bashed into the language as an afterthought. "Green threads" have been around for years, but Go seems to be the first language where they really took off. This may reflect the use case. Go is optimized for big web servers talking to huge numbers of clients, which is what Google does all day.
- jcranmer 6y ago
  The feature comparison is bullshit because the author uses different methodologies to count the features of Rust compared to the other three languages. For the other languages, it's count the bullet points in a list of new features; for Rust, it's count the bullet points in release notes. (And the methodology isn't clear as to whether it's limiting to language features, or including both library and language features) > Python and Rust started with threads, and are having "async" bashed into the language as an afterthought. Rust started with green threads, but they were removed pre-1.0 for reasons that I'm sure steveklabnik can jump in and explain.
  - steveklabnik 6y ago
    Yeah, I would strongly disagree with "bashed into the language as an afterthought" Here is a very lengthy explanation of the reasons: https://www.infoq.com/presentations/rust-2019/ https://www.infoq.com/presentations/rust-2019/
- mumblemumble 6y ago
  > We have to go parallel for things that need speed. That really depends on the kind of speed you need. I have, in my brief time on this planet, accomplished each of the following at least once: Sped up a concurrent implementation by making it parallel. Sped up a concurrent implementation by making it sequential. Sped up a parallel implementation by making it concurrent. Sped up a parallel implementation by making it sequential. Sped up a sequential implementation by making it concurrent. Sped up a sequential implementation by making it parallel. The 2nd and 4th ones are often the easiest to accomplish. Amdahl's law is a great rule of thumb, but it subtly implies an idealized world where both the transition between sequential and parallelizable sections of the process, and the communication among parallel sections, happen at zero cost. The real world is messy, though, so, in practice, they can get pretty expensive. Parallelism can slow things down by introducing extra copying, memory access, memory fences, conditional branches, etc. You've got to dig yourself out of that hole before you can realize any gains. To the extent that the term "order of magnitude" often comes into play when describing the sizes of delays these things can cause, it can be a pretty deep hole.
- 6y ago

hitekker 6y ago

I wonder how the author views Zig as a C replacement.

lights0123 6y ago

> Cargo is mandatory. On a similar line of thought, Rust’s compiler flags are not stable. Attempts to integrate it with other build systems have been met with hostility from the Rust & Cargo teams. The outside world exists, and us systems programmers spend a lot of our time integrating things. Rust refuses to play along. Linux kernel maintainers doesn't want to use Cargo in the kernel ("Agreed, I wrote one ~half a year ago that compiled TUs through rustc mimicking what we do with cc to some degree (i.e. no cargo etc.), and it was quite pleasant." [1]), and there hasn't really been much opposition to that by the Rust team. > However, nearly all programs needn’t be parallel. A program which uses poll effectively is going to be simpler, reasonably performant, and have orders of magnitude fewer bugs. “Fearless concurrency” allows you to fearlessly employ bad software design 9 times out of 10. Sure, if you don't care about performance, which may very well be the case in many situations. However, the reality is that modern CPUs get their performance from multi-core workloads, requiring you to do things in parallel. Go does have some nice bits (e.g. no fragmentation between Tokio and smol, no need to separate code between async and non-async versions), but you don't explain what those are in depth. > I especially refuse to “rewrite it in Rust” Sure—that's mostly just a meme[2], which many people in the Rust world acknowledge is a bad thing[3]. [1]: https://lore.kernel.org/lkml/CAKwvOdmuYc8rW_H4aQG4DsJzho=F+djd68fp7mzmBp3-wY--Uw@mail.gmail.com/T/#u https://lore.kernel.org/lkml/CAKwvOdmuYc8rW_H4aQG4DsJzho=F+d... [2]: https://www.reddit.com/r/rustjerk/comments/av5pog/higherres_rust_evangelism_strike_force_image/ https://www.reddit.com/r/rustjerk/comments/av5pog/higherres_... [3]: https://www.reddit.com/r/rust/comments/ifkrvg/i_printed_rewrite_it_in_rust_swag_for_students/g2s1bh9 https://www.reddit.com/r/rust/comments/ifkrvg/i_printed_rewr...

ColanR 6y ago
> “rewrite it in Rust”...which many people in the Rust world acknowledge is a bad thing I've seen "rewrite it in Rust" mentioned plenty, even on HN; in fact, that meme colored much of my initial impression of Rust before I learned anything about it directly. I think the maintainers and the Rust world in general need to address that meme head on if they don't want it to be part of how Rust is known. Otherwise, as it stands currently, Rust is the language that's trying to replace C and rewrite everything that is C in Rust.

dathinab 6y ago

How often does this get rehashed? This is at least the third maybe forth time the article is in the top charts. I don't feel even like posting my opinion anymore.

czzr 6y ago
It’s not a job, you don’t have to feel bad about that ;-)
- dathinab 6y ago
  Sure ;) it's just a topic I'm normally likely to comment on as I both respect Drew a lot for the work he does but at the same time disagree a lot with what he thinks about programming languages.

axegon_ 6y ago

I honestly don't think anyone suggests dropping C in favor of Rust. Make no mistake, I love Rust and I think it's the best language that's been developed in this century. Firstly, C is where it is because it's well established and has solid foundations and it has remained pretty much unchanged for decades. Rust on the other hand is changing rapidly and fast, which is something you wouldn't want for a language that powers your kernel Secondly, the Rust community is painfully small. Thirdly, Rust lives in the LLVM world and I don't see it coming into the GCC world anytime soon. Which is a huge problem, as far as replacing C goes(namely licencing might be problematic in some cases). Lastly Rust, in terms of it's nature, is more closely related to C++ rather than C. If Rust was to replace something, it has a much better chance against C++ than C. I truly want to see the day I open up linkedin, go to the jobs section, type in rust and see 6000 new job offers. But at this point in doubt this day will ever come.

steveklabnik 6y ago
> Thirdly, Rust lives in the LLVM world and I don't see it coming into the GCC world anytime soon. You may be surprised... we'll see, and it very much depends on what you mean by "soon," but there have been some interesting rumblings here.
ausjke 6y ago
mostly true. it took me a while to decide, I eventually picked up c++. modern c++ is very different nowadays, and it keeps evolving fast, to some extent many modern languages are having the same new features, c++ is becoming better and better for each new standard release, and g++/clang++ also keep up with new sanitizer, static analysis, excellent warning optional flags etc, in fact it is now very hard to make those stupid mistakes these days with modern c++ in a good IDE(even vim with the right configuration). I will keep my eye on rust, I use a few rust utilities myself, but for the heavy duty of my carerr, c/c++ remains to the the top choice.
- saagarjha 6y ago
  C++ does however still leave the door open for the not-so-stupid mistakes that are still memory safety issues ;)

solidsnack9000 6y ago

It might be that the only real C replacement in the author's sense is a language of annotations/validations and idioms for C. How else would you get everything that C has now -- the compiler support, the well-tire-kicked-spec, the ABI, the low feature-rate and concomitant unchanging character -- besides basically just being C with some minor (and unchanging) addenda? The weird thing about Go relative to all this is the fact that interoperates so poorly with C.

kstrauser 6y ago

The reverse is also true: C isn't a good replacement for Rust. Between Rust and Go, I can't see myself plausibly starting a new project in C ever again. Contributing to existing C projects? Sure! But for me, today, C has little appeal other than being compatible with itself. In any situation where C compatibility isn't a requirement, I don't feel like it has anything to offer me.

pornel 6y ago
Rust has been a fantastic C replacement for me. I have all the control and performance I wanted from C. Despite Rust being a "bigger" language, it's simpler to use, because it takes care of things for me, instead of relying on me to handle every tedious detail. It is more portable than C was for me. I don't need to support exotic DSP platforms, but I do need to support Windows. Now I don't have to spoon-feed MSVC, and I don't need to answer endless support tickets about the build system.
- kstrauser 6y ago
  That's been my experience, too. It's the little things, like having a built-in HashMap data structure, that I find to be so time saving. Data ownership took a bit of getting use to, but the compiler gives wonderful human-readable suggestions for how to fix errors that pop up, and now I don't have to spend a lot of time reasoning through every decision I've made to make sure I'm not leaking or clobbering memory all over the place.

rafaelvasco 6y ago

Don't think there's any good C replacements. There are great alternatives, with advantages and compromises.

smt88 6y ago

This seems like attacking a straw man. Rust can be a good C alternative, which is all I've ever seen Rust people promise it to be. C is far too widely used/supported to be replaced. A small minority of libraries will be rewritten in Rust, but mostly we'll see new projects that have their own namespaces.

marcosdumay 6y ago

Hum... Of course, Rust is very different from C. I don't think anyone disagrees. But a "C replacement" doesn't mean "something similar to C", it means "something that solves the same problems as C". Rust doesn't excel on all the problems that C excels at, but it does for a lot of them. So it is a partial replacement, and isn't at all a total replacement.

bluejekyll 6y ago
At the moment I believe C excels at portability to uncommon CPU architectures. It also excels at ABI stability. Are there other areas where you believe C excels vs. Rust?

CalChris 6y ago

Concurrency is generally a bad thing and specifically it is a good thing.

discardable_dan 6y ago

The discussions about a lack of specification are, I think, the largest and most-relevant. Someone in an earlier discussion mentioned the Rust Reference [1], but it is not sufficient: in particular, many portions of the memory model, calling conventions, and borrow-checking enforcement are left unspecified. Rust's guarantees are built on these, and they are currently defined by the current rustc implementation. Until a complete and detailed standard is published, Rust will not have a stable AI, and cannot enjoy multiple implementations (which inhibits its portability). Even the bit about Cargo stems from this: without a specification, Cargo's implementation is the de facto explanation for to properly link external, compiled libraries against rust binaries. As Rust matures, I anticipate many of these things will stop being the case---and I really hope someone gets around to writing a different Rust compiler, using pattern-matched ASTS like you would in OCaml, instead of the current, visitor-based solution. 1. https://doc.rust-lang.org/1.0.0/reference.html https://doc.rust-lang.org/1.0.0/reference.html

lights0123 6y ago
Note that you linked to the Rust Reference from 2015: the living version lives at https://doc.rust-lang.org/reference/ https://doc.rust-lang.org/reference/.
the8472 6y ago
> calling conventions Afaik that's intentionally unspecified/implementation-specific so that the language can evolve. The C ABI is the de-facto interoperability layer. > the memory model According to the rustonomicon they're leaning entirely on the C++20 memory model at the moment.
steveklabnik 6y ago
> Until a complete and detailed standard is published, Rust will not have a stable AI, and cannot enjoy multiple implementations (which inhibits its portability). This is not really true; we already have one alternative implementation that's good enough to compile the compiler, though it is not complete yet. Also, the gcc folks are interested in getting Rust in, and a formal specification is not a roadblock for them. > Even the bit about Cargo stems from this: without a specification, Cargo's implementation is the de facto explanation for to properly link external, compiled libraries against rust binaries. This is not true; this interface to the compiler is stable.

Paul-ish 6y ago

Whatever replaces C, if it is replaced, won't be C.

MaxBarraclough 6y ago

> Go is the result of C programmers designing a new programming language, and Rust is the result of C++ programmers designing a new programming language”. This isn’t just a metaphor - Go was designed by plan9 alumni That may be true, but Go has a garbage-collector, and Rust does not. Garbage-collection strikes me as being against the principles of both C and C++, but especially C. Drew makes some solid points about the merits of C, even despite its considerable downsides, but I have to agree with others here that rewriting in Rust is rarely what people are advocating. Writing new systems in Rust, is usually the point. Mandatory link to the Spolsky article, Things You Should Never Do, on why you probably shouldn't throw out working code. [0] > Rust will eventually fail to the “jack of all trades, master of none” problem that C++ has. Ok, but C++ has been incredibly successful, and it outcompetes C in many domains, just about everything but kernel programming and embedded programming. C++ isn't completely out of the running even there. Versatility is a feature. Also, Drew (the SourceHut guy, if anyone missed it) has a good sense for minimalist web design. There's no fat on that page. A refreshing change. [0] https://www.joelonsoftware.com/2000/04/06/things-you-should-never-do-part-i/ https://www.joelonsoftware.com/2000/04/06/things-you-should-...

deleted 6y ago
[deleted]
erik_seaberg 6y ago
> why you probably shouldn't throw out working code. Linux crashes, Windows bluescreens, Emacs crashes, GCC crashes. Do we have any C that works? I hear good things about seL4 but that was mostly using C as a compilation target from Haskell.
Gibbon1 6y ago
Offhand thought is there are two ways to skin the cat vs safety. Go and Rust put hard limits on what will compile and especially rust run a whole bunch of checks to enforce book keeping. In C if you are doing things right you run those checks as a separate process. And you only do it once you are done with a dev cycle, not every time you compile the program.

almostdeadguy 6y ago

If you take this argument seriously enough there's a level of specificity about the salient features of C (or any language) where you can say "nothing is a replacement for C, because it isn't C". Is C's degree of portability important for a C replacement? Depends on the project we're talking about and the platforms it needs to support. We can go down the line w/ these arguments (some of which like "concurrency is a bad thing" and "I don't care about safety" aren't even serious). I'm also surprised that in 2020 (or 2019 as this was written) we have engineers making a serious argument that specifications are inviolable laws. They do in fact help, but there are more considerations to make about a project's commitments to reasonable, expected behavior than just "there's a spec" (and in fact C has more guardrails supporting those commitments than a spec). I agree that there's a rust contingent that is over-eager to rewrite and may be oblivious to the concerns of a project or broader technical implications involved in pulling rust into a project. That being said, this reads more like a "get off my lawn", oblivious tirade about the "cult of the new" than a serious attempt to address these instances.

codygman 6y ago

> Consider Go, ... addressing them with the simplest solution possible. Go code doesn't result in the simplest solution possible.