Rust is not a good C replacement (2019)

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.

jcranmer2• 6 years 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.

mumblemumble• 6 years 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.

masklinn2• 6 years ago

"Green threads" have been around for years, but Go seems to be the first language where they really took off.

Java used to be based around green threads back in the early day. Lua's concurrency is based around coroutines. OCaml's OS threads are hampered by a GIL so concurrency is generally done via lwt or Async. And of course "green threads" are the very base of erlang / elixir. And Haskell has… Sparks, I think? You could argue that they're not as popular as Go but then… ok?

This may reflect the use case.

It definitely does. Rust used to use green threads and everything way back in the olden days. That was stripped out, because it's inimical to being the low-level language its community wanted it to be.

If you want to use green threads, you must have some sort of runtime to manage them (scheduling and preempting, maintaining the task queues, …), and probably a GC because this makes the lifecycle of your values way harder to predict and square. But the environment where the Rust community of the time wanted to use Rust did not allow for such overhead. So out they went, to be added later as an opt-in.

Ar-Curunir2• 6 years ago

async was not "bashed into the language as an afterthought". The design of async took a lot of time, and was done very carefully to try and fit a niche that very few other languages manage to do: zero-overhead, ergonomic, and safe abstractions for futures.

pornel2• 6 years ago

This header counting is silly. Regular complaints about Rust changing too much have stopped after Rust website stopped having such detailed release notes. Seriously.

People who don't know Rust don't understand how bare-bones 1.0 was, and that Rust is still filling in gaps in basic functionality. Rust is still catching up with features Go 1.0 had, but people praise Go for being small, while freaking out about Rust getting bloated. This doesn't make sense!

Most of the changes can be summed up "previously code that you'd expect to work didn't work for weird complex reasons, but now we've fixed it and it compiles". Things like `clone()` didn't work on arrays larger than 32 elements. Now it works, as it should have since 1.0. But by Drew's header count that's some frivolous added complexity.

Rust started with threads, and are having "async" bashed into the language as an afterthought.

Afterthought? That feature was over 3 years in the making. It was probably the most scrutinized and bikeshedded feature Rust ever had. Rust team has explored various approaches, with prototypes implemented in the compiler. People have built an entire ecosystem on Futures 0.1 to work out all the kinks of the design in large production-ready projects.

Proto-Rust had green threads and removed them for a good reason. The trade-offs are well understood, and it's not a coincidence that Go doesn't have zero-cost interoperability with C, and Rust has (including cross-language inlining).

hitekker• 6 years ago

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

lights01232• 6 years 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+d... [2]: https://www.reddit.com/r/rustjerk/comments/av5pog/higherres_... [3]: https://www.reddit.com/r/rust/comments/ifkrvg/i_printed_rewr...

ColanR4• 6 years 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.

Ar-Curunir2• 6 years ago

I mean, every rust forum has a "no language zealotry" rule in place, partially to head off the RIIR meme. I don't know what you want the Rust team to say, "Don't use Rust to improve your C projects"?

dathinab2• 6 years 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• 6 years ago

It’s not a job, you don’t have to feel bad about that ;-)

dathinab2• 6 years 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_2• 6 years 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.

steveklabnik8• 6 years 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.

ausjke3• 6 years 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• 6 years ago

C++ does however still leave the door open for the not-so-stupid mistakes that are still memory safety issues ;)

pizza234• 6 years ago

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

Google has, supposedly, some of the best engineers¹ in the world, and the best tooling in the world, and they keep pouring tons of resources on the best engineers and the best tools.

Yet, the same memory safety errors (which Rust, or any hypothetical memory-safe language, prevent entirely) keep popping again, and again. Have you heard of CVE-2020-0022? It's amazing.

In this perspective, pouring resources and effort on those languages is like trying to open a door by banging the head harder. It's fine if you like it, just don't pretend it's the optimal way to open doors.

¹=edited, to make it clearer what I wanted to convey.

ausjke3• 6 years ago

https://youtube.com/watch?v=iOBXVOAbpdY this is a 8-minute study on how rust is safe comparing to C, the summary is that, there is a long way to go, many rust code is still unsafe today.

JT2FG• 6 years ago

I honestly don't think anyone suggests dropping C in favor of Rust.

Depends on where you look. In some online spaces a lot of Rust advocates do.

jeroenhd5• 6 years ago

I do believe there's a "drop C and pick Rust" crowd, or multiple even.

When it comes to building user mode applications like desktop programs with QT or GTK or what have you or command line programs such as curl and wget, I think these crowds have a valid point. Most of those applications are written in an object oriented language though.

There's also a very small group that's very militant about everything, including kernels and microcontroller programs, being rewritten into Rust. I don't pay too much attention to that crowd; C has its place and it's not the ultimate solution to programming languages.

Rust won't replace C in the kernel, but I do think we will see tooling for our network clients, file indexing and perhaps even version control slowly switching languages (if they still rely on C, that is). These will all be new tools though, because rewriting an old application into Rust and maintaining compatibility and performance is a big challenge.

bluejekyll5• 6 years ago

Rust won't replace C in the kernel, but I do think we will see tooling for our network clients, file indexing and perhaps even version control slowly switching languages (if they still rely on C, that is).

Do you mean the Linux kernel, XNU, Free/Net/OpenBSD, or other existing kernel's? There are plenty of examples of folks successfully building kernels in Rust. The likely hood of any of the major kernels adopting it (beyond drivers) is probably low. I expect the only reason that would happen is if any of the folks behind those kernels decide that they actively want to migrate the entire thing away from C in the long-run.

Ground up new kernels in Rust are very feasible, though. Will any of those attract the community and contribution that we see in Linux? That's unlikely, but it's not impossible, as your comment implies.

BearOso• 6 years ago

Doing GUIs with Rust is difficult. Gtk-rs lucked out because Gtk has introspection that maps out its C object API. Qt is not so good. Something simple like Win32? Not so good.

Maybe I want to write a game. Gfx-rs is deprecated. Its replacement? It’s in a half ready beta state, and most of its developers are now focusing on a compatibility wrapper for MacOS, so progress is stalled.

The ecosystem just isn’t there. System libraries have an interface that is extremely suited for C. Interfaces have to be uniquely adapted for rust or be marked completely unsafe. Dynamic linking is convoluted, so Rust encourages statically linking everything. It’s not easy, and the situation needs to improve or Rust will be relegated to just another text processing language. C library symbols need to be accessible as a first-class part of the language.

axegon_2• 6 years ago

I do believe there's a "drop C and pick Rust" crowd, or multiple even.

I wouldn't be surprised if there are multiple large communities that preach about nodejs replacing c. However I doubt anyone from the core rust developers lives with such illusions.

masklinn2• 6 years ago

I honestly don't think anyone suggests dropping C in favor of Rust.

librsvg largely did. Brian Cantrill was very bullish, and apparently still is given… well the name of his company is a reference for starters, and if you look a Oxide's public repos those with C as the main language are all forks.

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.

That's very true, but at the same time C++ is way more complicated than Rust, with features interacting in subtle pitfalls and a lot more implicit (and often undesirable) behaviours e.g. the Chromium Cursor / GDI leak where a missing (therefore implicitly-declared) copy-assignment operator led to a leak of invisible kernel resources.

Not all of the people who'd rather do C than C++ do so because they don't want anything better than C. Again I'll cite Cantrill who very famously and publicly hated C++.

caeril• 6 years ago

Right, well, Cantrill was also bullish on Node.js of all things, somehow. I'm not sure I'd take a snapshot of a single moment of his ever-evolving advocacy to be justification of what the current Right Thing(tm) is.

That said, Oxide is definitely doing The Right Thing(tm) selecting Rust, since they explicitly NEED boot and system board firmware that A. Is fast native code and B. Is as close to semi-sorta-provably-secure as one can get. Rust fits that specific bill better than anything short of C/ASM and NASA-level code validation processes.

abnercoimbre3• 6 years ago

The simplicity of the C language remains a necessary property for critical industries around the world. These industries are not on social media talking about programming languages either :P

I'm rooting for Zig and Odin as the better evolution for C. So is Carmack, at least for Zig [0] it seems.

[0] https://twitter.com/ID_AA_Carmack/status/1300579679951294464

bluejekyll5• 6 years ago

That comment doesn't really seem to support your statement. He may or may not be rooting for Zig, but it seems to be a stretch to derive that from this statement, "I have been checking on the progress for a while, and I like what I see, but I haven’t coded in it."

In the same thread on Rust when asked, "What’s a better modern choice?", the response was: "Rust would be the obvious things [sic], and I don't have any reason to doubt it would be good, but I haven't implemented even a medium sized application in it."

https://twitter.com/ID_AA_Carmack/status/1299574198365495297...

solidsnack9000• 6 years 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.

kstrauser2• 6 years 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.

pornel2• 6 years 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.

kstrauser2• 6 years 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• 6 years ago

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

smt88• 6 years 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• 6 years 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.

bluejekyll5• 6 years 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• 6 years ago

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

discardable_dan2• 6 years 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

lights01232• 6 years ago

Note that you linked to the Rust Reference from 2015: the living version lives at https://doc.rust-lang.org/reference/.

the8472• 6 years 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.

steveklabnik8• 6 years 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.

discardable_dan2• 6 years ago

we already have one alternative implementation that's good enough to compile the compiler

That's really interesting! Can you link it?

jcranmer2• 6 years ago

While I do think the lack of a specification is problematic, I don't think it's quite the dealbreaker it's presented here as.

Most programmers don't write ISO C; they write GCC/Clang/MSVC C. This is especially true in the systems programming domain. And these variants are frequently poorly-specified, if indeed they are at all. Start using __attribute__ (or __declspec), inline assembly, computed goto, etc., and you find that your program isn't well-specified. Implementation-defined behavior is also supposed to have its behavior documented by the compiler, but adherence to this rule is spotty (clang is the most notorious violator here). And the after-effects of these changes aren't localized: the semantics of __builtin_nontemporal in LLVM imply a change in the specification of atomic fences [1], not that it's documented anywhere in LLVM.

The lack of a specification tends to not be a problem in practice because (and again, especially so for systems programmers) C tends to be viewed as a "portable assembly," and these extensions are mostly gateways for picking specific, more specialized instructions--which are less amenable to optimization. But the main value of the specification is to nail down what can and cannot be optimized, and if you're a person like me who loves pushing the margins of the specification, you'll really notice how desperately needed better specification of these extensions are, even in the C domain.

[1] If you're wondering, LLVM treats the semantics of fences as adhering only to "normal" memory operations. MOVNT, the nontemporal operator in x86, is equivalent to a relaxed store, so you need to do a release fence (SFENCE) to guarantee visibility. However, x86 is TSO, so all regular stores effectively have a SFENCE following them, so release fences compile to nothing instead of SFENCE.

GlitchMr• 6 years ago

calling conventions

Rust intentionally doesn't have stable ABI. Having a specification wouldn't change that. C++ does have a stable ABI, and pays a cost due to that - for instance `unordered_map` is 3 times slower than it needs to be (the implementation cannot be improved specifically due to having a stable ABI).

Use C ABI if you need components compiled using different rustc version to interoperate.

Paul-ish• 6 years ago

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

MaxBarraclough• 6 years 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-...

erik_seaberg• 6 years 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• 6 years 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• 6 years 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• 6 years ago

Consider Go, ... addressing them with the simplest solution possible.

Go code doesn't result in the simplest solution possible.

Rust is not a good C replacement (2019)

Related Stories