Rust is not a good C replacement

There's a lot of stuff I could say here, but I'll stick to

> Attempts to integrate it with other build systems have been met with hostility from the Rust & Cargo teams.

This is very much not true. We've put in a ton of work to support this. Arguably, we've put in too much design work and not enough implementation work; we've had a few different attempts at making this work even better than it does today, and we haven't finished them up. But this is very much something that is cared about and desired by the team.

It was literally on the 2017 roadmap: https://blog.rust-lang.org/2017/02/06/roadmap.html

> Rust should integrate easily into large build systems. Plans include working with large companies incorporating Rust to understand how best to equip Cargo to smooth the process.

I don't know how this is framed as "hostility".

As one example of the work done here: https://github.com/rust-lang/cargo/issues/5579

> Safety. Yes, Rust is more safe. I don’t really care. In light of all of these problems, I’ll take my segfaults and buffer overflows. I especially refuse to “rewrite it in Rust” - because no matter what, rewriting an entire program from scratch is always going to introduce more bugs than maintaining the C program ever would.

And that is why we can't have nice things.

"I don't really care" if someone overflows my buffer to execute code...

And: "going to introduce more bugs" - false. Empirically complete bollocks...

> C is the most portable programming language.

This is a function of popularity and time.

> C has a spec. No spec means there’s nothing keeping rustc honest.

Agreed, language specification is critical. The language reference [1] is very detailed, though. I'm not sure what it would take to promote this to a "specification."

> That really cool feature $other_language has? Not interested. It’ll be more trouble than it’s worth

Binding to "editions" is a reasonable way to get stability, IMO. It's a shame that this wasn't adopted earlier.

> Concurrency is generally a bad thing.

So don't leverage it. Don't use fork() or clone() either and we'll all agree to ignore this point.

> Safety. Yes, Rust is more safe. I don’t really care. In light of all of these problems, I’ll take my segfaults and buffer overflows.

Here underlies the crux, you should have led with this. This is a sizable portion of rust's value proposition. If you don't value it then it's likely not to measure up well.

> Rust will eventually fail to the “jack of all trades, master of none” problem that C++ has.

We have to take the good with the bad in everything, right? If Rust's future is "spectacular failure like C++" then it's probably going to be a wild success.

[1] https://doc.rust-lang.org/1.0.0/reference.html

> But now you know why we are still writing C, and hopefully you’ll stop bloody bothering us about it.

I don't think anyone will stop bothering them about it until C software security improves. Microsoft found that 70% of security bugs in their software were memory safety issues:

https://www.zdnet.com/article/microsoft-70-percent-of-all-se...

Languages like Rust are making an effort to address these issues. What's the roadmap for reducing the number of security flaws in C software?

The main fallacy of this blog post is that he wants it to be one single programming language that replaces C.

C has actually been already replaced mostly. C++, Java, C#, Python, Ruby, Go, Rust, etc. have been chipping away for more than 20 years now at C's market share.

What kind of project can you seriously start today in C because there are no better options available?

My guess is embedded programming and kernel programming and for both of these usecases we feel the pain and would actually want something else.

> Yes, Rust is more safe. I don’t really care. In light of all of these problems, I’ll take my segfaults and buffer overflows.

Old C programmer yelling at clouds?

> Consider Go, which has had a lot of success in supplanting C for many problems. It does this by specializing on certain classes of programs and addressing them with the simplest solution possible. It hasn’t completely replaced C, but it has made a substantial dent in its problem space - more than I can really say for Rust

Go is IMHO a nice language and I would have been delighted to have it in the 90s. But nowadays it already feels outdated on arrival.

Lately I've been noticing more and more tools being developed with Rust. Some things take time, I wouldn't already write off Rust yet.

I agree with the overall conclusion. Zig is aiming at being a C replacement. Rust is very much more in the C++ space. But a lot of the individual points seem off the mark.

> Concurrency is generally a bad thing. A program which uses poll effectively is going to be simpler, reasonably performant, and have orders of magnitude fewer bugs.

One of the benefits of Rust is that provides a lot of checks on concurrent code to prevent you doing stupid things, so you get the benefits without these costs. It's not perfect, but I've personally had zero issues with concurrent code in Rust. This is actually a benefit Rust provides even over other memory safe languages like Java.

> C has a spec.

Yes, C has a spec. But a ridiculous number of things (in a modern context) are left as undefined behaviour in that spec, meaning that it is very easy to accidentally violate the spec. Rust doesn't have a spec yet, but it has far more safeguards which make it much easier to avoid weird unexpected behaviours in practice. A full spec will come eventually.

Most of the author's points here derive from the fact that C has been around for nearly 50 years and Rust a mere 8. This post should really be titled "Rust is not a good C replacement _right now_".

Yes, Rust still has a long way to go to be the right tool for all the things you can do with C today, but that doesn't make it less. It clearly has benefits when writing concurrent and safe code. You pay for this with a learning curve, but the Rust team has been shaving this curve down through better tooling and documentation for the past few years.

> Yes, Rust is more safe. I don’t really care. In light of all of these problems, I’ll take my segfaults and buffer overflows.

I suspect that for the author's work, these things may not matter much. But to a programmer working on any software where security is paramount (many web infrastructure pieces), this feature is golden.

I expect that as Rust matures, we'll see a solidified spec, competing implementations, and expanded build tooling. C has a long head-start, not to acknowledge that is just wrong.

I read through the article and I recognized the pattern of an old C cave bear that refuses to learn new things and understand why safety and type theory matters. Lots of arguments made in that post are either unfair (i.e. the Cargo team stuff) or completely wrong.

Also, if you think Go is a replacement of C, I think you are not a real systems programmer. Go has a GC, in the first place: how can you seriously state it’s a replacement of C? Also, you didn’t mention it (voluntary I guess), but Rust does have a community-based mechanism to make the language evolve (RFCs).

About the number of features, those are mostly non-breaking changes additions. Rust has editions now. Just… do your homework?

C++ is mostly used as a OOPL. Rust has no concept of OOP.

> Yes, Rust is more safe. I don’t really care. In light of all of these problems, I’ll take my segfaults and buffer overflows.

Sorry For Your Loss.

,,Concurrency is generally a bad thing''

Easy speedup of processors ended. Not using system resources efficiently is not sustainable long term. Mozilla created Rust to be able to use the multi-core hardware (especially on mobile phones), thereby improving battery usage as well for rendering web pages.

Rust has it's C++ style problems (compiling time, not good enough IDE support), but the dev team knows about them, and hopefully improve them in the next years.

>Rust will eventually fail to the “jack of all trades, master of none” problem that C++ has.

He's talking about C++ like it's some kind of failure and not one of the most widely used languages in the world. Sounds like the author just doesn't like C++, so it's no surprise he doesn't like Rust either.

>Yes, Rust is more safe. I don’t really care. In light of all of these problems, I’ll take my segfaults and buffer overflows.

"I don't really care" isn't a good reason for ignoring one of Rust's strongest points. If you're not an expert in C like the author, then this would be one of the biggest reasons for choosing Rust over C.

That being said, I agree than Rust isn't a good C replacement, mainly because it's more similar to C++.

This reads like a rant about screwdrivers being terrible hammers.

By the way, there is a lot of polyglot library code out there that is both valid C and C++, which is the reason for using "C/C++" much of the time.

I think a better title for this post would be "Rust is not C".

I'm also not sure how stating the number of features recently added to a 47yo language is very small and the number of features added to a 8yo language is very large proves any point.

That you don't care about safety or concurrency has nothing to do with the title, and frankly betrays that this article is more about Rust not being last decade's systems language as opposed to Rust being a good candidate for future projects that would otherwise have chosen C.

I've been waiting so much for a way to use rustup (and Cargo, but that's beyond the pull request a bit further down) behind a MITM proxy.

And since Rust has always been Windows-friendly, I had high hopes when someone actually started to implement this support (basically pass "-k" to curl).

Because I had fought with all kinds of git and curl configuration files, until I realized that those don't mean anything to rustup.

The implementation was critiqued in a very civil way. The author fixed the issues. Everything was ready to merge and... in walk some busybodies who under the pretense of caring about security (having no clue about the issue or modern Windows workplaces, and despite clear refutations of their concerns) have seemingly been able to kill this patch: https://github.com/rust-lang/rustup.rs/pull/1624/

"We need to discuss this with experts". I don't know where, I briefly searched for any such discussion. I guess there was none.

So a drive-by shooting killed a very useful feature. The saboteurs can revel in the knowledge that they drove away a new contributor (I haben't seen any more activity on that GitHub issue). And users suffer.

Thanks a lot! Sabotaging corporate users must feel very good.

> A program which uses poll effectively is going to be simpler, reasonably performant,

Only for newbie values of "performant". I work on data-storage servers. It has been quite a few years since I've worked on one that didn't absolutely need to take advantage of multiple cores to get competitive performance, and I'm very far from being alone in this need. Splitting one server into many separate processes is not a solution in these cases, as it just moves complexity from the in-process domain to the between-process domain where it's even harder to maintain good performance (or even validate correctness). As soon as I read "concurrency is generally a bad thing" the author lost all credibility.

> "measured by the number of bullet points [...] on Wikipedia"

> "measured by the number of headers in the release notes of major [...] versions"

I don't think it's a fair comparison to pull from these two types of sources, compare the numbers and expect a reasonable result.

The entire rest of this blog reads more like a rant about screws not being nails than an actual complain about the languages itself.

> Safety. Yes, Rust is more safe. I don’t really care. In light of all of these problems, I’ll take my segfaults and buffer overflows. I especially refuse to “rewrite it in Rust” - because no matter what, rewriting an entire program from scratch is always going to introduce more bugs than maintaining the C program ever would.

Are they advocating for never rewriting anything? Like, programming language advancement should have stopped at C cause someone would have had to rewrite something and that would mean more bugs??

You don't have to care about memory safety, but if you don't you probably shouldn't speak for "systems programmers" as a whole. Systems need to be safe.

OK looking Just at the number of features seems disingenuous. Cpp features tend to idk, increase the level of complexity as there tends to be quite a bit of friction between them. Rust features definitely “work together”.

This post seems to have started with a conclusion and worked backwards.

Rust is such a breath of fresh air. Cargo is nuts. The community is nuts. I’ve been writing rust full time for a couple of months now and I’m not going back.

Sir_Cmpwn has lost a bit of credibility in my eyes after this article and their behavior in the comments.

The current pace of development of C++ is questionable, but Rust is still a fairly young language, so the comparison to C seems unfair. Presumably, the rate of change in Rust will slow down. Although, if you are looking for stability today, the point does stand.

The converse is what I've heard with people at REN-ISAC and whom write and coauthor RFCs. (I'm not one, but trust the comments they've made to me regarding this.)

For a new dev to start writing internet-quality code, with C/C++ takes 10 years before they can make reliable code. The procedure takes what amounts to a journeyman style one-on-one until proficiency, 10k / 10 years later.

With Rust, it takes 2 years for a new developer to attain proficiency.

To me, those numbers are the ones that matter. Rust is stable and good, and gets out of the way of the developer... and gets in the way of the developer when coding anti-patterns.

"...I’ll take my segfaults and buffer overflows"

Well, this speaks volumes. Nothing more need to be said.

Age of the langs absolutely needs to be taken into account if comparing stability and feature addition rate.

According to Wikipedia it's 47 years for C vs 8 years for Rust (as of 2019) - it's not that surprising that a 6x older language is much more stable.

> Concurrency is generally a bad thing

Erm...

> Safety. Yes, Rust is more safe. I don’t really care. In light of all of these problems, I’ll take my segfaults and buffer overflows.

Ok this is nonsense.

Concurrency might be a dangerous thing but in microcontroller land, where I do my C programming, interrupts are a fact of life and just polling really isn't a practical solution.

This just reads like the author was told to rewrite his code in rust one too many times, and he felt compelled to justify his own choices by bashing rust. Just say you like the simplicity and subtle bugs of C more than having to deal with the upfront complexity of low-level code at all times

Of course C programmers are going to think Rust is a poor C replacement. Rust wasn't made for C programmers -- it was made for their replacements.

Why do people up vote your flame war post?

Ah, exploiting the human urge to argue about literally anything. Especially when your argument is full of flaws and straw men statements.

My biggest quibble with the article is the idea that C will have a replacement. Many languages have already replaced C, in many domains. And yet C is still with us. I suspect it will remain indefinitely, shrinking in relative popularity but growing in the absolute sense. If for no other reason than that every language benefits from having a way of talking to libraries written in other languages, and the lingua franca is C. Rather than writing N^2 foreign function interfaces for N languages, each language can have one FFI library targeting C interoperability.

As long as you don't write software for computers that are connected to a network, it's fine not to care about security. For everybody else though, new software should probably be written in a safer language. That doesn't have to be Rust of course.

Personally, I think the C community is deeply infatuated with the idea that "we are in fact simple" mentality even though it's not well justified.

C isn't simple. C isn't simple to use.

On the implementation side, it has a complex calling convention. It relies on a memory management runtime without spec'd behavior. Tons of hardware implementation details leak up to the upper levels. C's error handling schemes are inconsistent, and thus complex to work with and to implement.

Being a C programmer isn't much easier either! C's memory managers tend to blow up if misused, but they don't blow up WHEN they're misused. They always cause problems, but it's not clear how or why. You have a bomb in your code that will go off in a random place. Even good debuggers with great tools can find it challenging to find the source of a double free. And that's alongside managing the weakly typed (not to be confused with static/dynamic) world, the pointer arithmetic, the inconsistent library conventions. Oh yeah, the libraries...

C's libraries aren't simple. They have to protect themselves from double inclusion, they can collide with each other, and have wildly different conventions depending on if they're loaded at runtime or compile time. Despite a constant derision of OO from the community, they often affect an "OO" discipline on methods. In reality this asks developers to create the impression of OO behavior by being very (very!) careful with call sequencing. And of course, the price of failure on most of these tasks is at runtime, on someone else's hardware, often with opportunities for remote execution.

When a C programmer says, "C is far from the perfect language - it has many flaws. However, its replacement will be simpler - not more complex," we have to read it very carefully and ask, "What does simpler mean?" Because despite the complexities of being a C programmer and the unstated complexities of the C runtime (and the large portion of unspec'd behavior so glibly ignored in this article to dunk on Rust), they still say "C is simple."

In this case, evidently it means: "Consider Go, which has had a lot of success in supplanting C for many problems. It does this by specializing on certain classes of programs and addressing them with the simplest solution possible."

Go isn't simpler. Go actually aims for a rather broad category of programs (it goes way up into the world of abstraction Python covers, and stops short of the embedded world where C is firmly entrenched because it's well-understood). Go has a sophisticated (and arguably, hard-to-use) concurrency model (didn't the author just say, "Concurrency is generally a bad thing?") and implementation. It has real garbage collection. Its stdlib is expected to have full SSL and networking support builtin.

But Golang is familiar to C programmers. I think that is why we see all the dunks on C++ and Rust in this artcile. C++ and Rust are weird. They're different. Go feels like C, so it's "simpler to learn" even if it requires a whole lot more core concepts and careful implementation than a C compiler.

Maybe Rust isn't your solution. Okay. Maybe C++ isn't your solution. Okay. There's still lots of other good languages to try. Languages that don't ask users to wade among a field of charged rails that the slightest touch can result in catastrophe. Nim or D maybe? There are others, and you can find them.

But continuing to use C with the attitude that, and I quote, "I don’t really care. In light of [the complaints leveled at Rust], I’ll take my segfaults and buffer overflows" is dangerous. It's unprofessional. It's reckless. It's also a false dichotomy.

The answer to C's problems is to stop using C. Not to start using something else specifically. This article makes it clear that the actual goal of this sentiment in the C camp is to keep using C. There isn't even a candid ownership of the problems with that strategy.

From performance point of view, Rust is comparable to C++ https://benchmarksgame-team.pages.debian.net/benchmarksgame/...

You can't overstate the importance of a specification. It is the most loathed thing to write, like unit tests, but in the end is essential. I think the OP romanticizes a bit: K&R C had a spec, a very very very loose spec. It took ANSI a decade to put some meat on it. Early C compilers weren't much help: Sparc had SystemV and AIX had POSIX which are OS specs but still defined C behavior in their compilers, and it made life so much easier in the early 90's when they converged on Gnu.

My favorite part of the article is the footnote. We really need to stop referring to C/C++ as "roughly the same" because they are so so so radically different.

Should the HN rules be amended to discourage self-authored submissions? They seem to circumvent the natural filter that comes with peer-nomination, and suggests they were written with promotion in mind.

Lack of a formal specification and/or an international standard is the real bummer. That's the biggest disadvantage in comparison to languages like Ada and C.

I think there is a gap in the market for small language which is just a "better C", but developing a new language is a great deal of work, and it would be hard to compete against the alternative of using a small subset of {Ada, Rust, whatever}.

Maybe the large languages should look at defining official subsets, to make life simpler both for programmers and validation. Ada used to have something of the sort (and still does for all I know).

It seems that the Rust community is already slowing down with new features. Have a look at "This Week in Rust" updates: the section "Approved RFCs" has the text "No RFCs were approved this week" almost every week now. There also was a discussion of designing 2019 as the fallow year and going more slow than before.

from compiler's point of view, C++ doesn't really added that much features, and quite stable. imho i believe the C++ ISO committee does consider the possibilities compiler writers are able to implement these features. e.g lambda expression, there's always operator() overloaded available in C++98; Variable template, only allowed in namespace, aka. static member data member in template type; CTAD, take template function argument deduce mechanism and wrap-up for ya; auto, same as template argument, and C++'s template argument is the same as C's typedef, etc. that is to say, to some extend, C++'s features are also written in C++. The new idea could think of is the r-value type, which invented to trigger move constructor, again, using the existing function overloading mechanism to do the job. This maybe not engineering friendly which the writer has to manually nullify the moved object's internal pointers as for Rust just using type system to prevent you from using it.

Sincere question, I didn't realize that Rust didn't have a specification. How can folk say Rust guarantees safety when it doesn't guarantee an implementation? I don't see how you could have one without the other.

Now, admittedly, the lowest level language I've used is Go!, so fairly abstracted (and no memory management), so I might be mistaken, but it doesn't seem like you can have safety without a specification.

Totally agree with his observations but I disagree with the conclusion. C is a ok programming language. The first language that realises that simplicity above all is the most important feature of any language and uses the same safety measures like Rust is going to win over a huge user base.

If OP thinks Firefox is one of the largest C++ codebases in the world then OP has a very limited worldview.

I keep trying to make up my mind whether this author is a C programmer. Hmmm.