
Rust is not a good C replacement (2019) - letientai299
https://drewdevault.com/2019/03/25/Rust-is-not-a-good-C-replacement.html
======
MaxBarraclough
> 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-...](https://www.joelonsoftware.com/2000/04/06/things-you-should-never-
do-part-i/)

~~~
Gibbon1
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.

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

~~~
jeroenhd
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.

~~~
BearOso
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.

~~~
jeroenhd
I agree the ecosystem isn't there yet, but given some time that will correct
itself.

Perhaps Rust will not be able to interface with Win32 because of its reliance
on pointers, but there's the possibility of leveraging alternative programming
interfaces such as the abstractions in the .NET runtime.

I believe that if Python and Java can have cross-platform GUI libraries, so
can Rust. I don't know what the result would look like but the tooling has
already massively improved since I first looked into the language. I'm too
annoyed at GTK for their obsession with client-side decorations messing up the
native look on Windows and other platforms to use it for my own projects, but
the Qt integration didn't look all that bad in my opinion. Rust-qt is clunky
because the Qt API requires unsafe code, but with some work the unsafe parts
can be abstracted away from the main program logic. It's suboptimal but it
does allow you to do data and network traffic parsing and handling in a safe
manner, which would already be a huge win for application security in my
opinion.

~~~
steveklabnik
(Rust can absolutely interface with Win32, and Microsoft themselves have
implemented bindings to WinRT.)

~~~
jeroenhd
Interesting. In my experience, a lot of Win32 messaging required converting
pointers to structs and reading values from that. I don't see how that works
with Rust? I suppose you can add a load of unsafe code but that would make the
whole thing a lot more complex as you now need to deal with pointer ownership
and (de)allocation.

~~~
steveklabnik
Yes, because it is FFI you have to use unsafe to do so.

Almost 20 million all time downloads:
[https://crates.io/crates/winapi](https://crates.io/crates/winapi)

And the other bindings I was talking about
[https://github.com/microsoft/winrt-rs](https://github.com/microsoft/winrt-rs)

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

------
lights0123
> 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...](https://lore.kernel.org/lkml/CAKwvOdmuYc8rW_H4aQG4DsJzho=F+djd68fp7mzmBp3-wY
--Uw@mail.gmail.com/T/#u) [2]:
[https://www.reddit.com/r/rustjerk/comments/av5pog/higherres_...](https://www.reddit.com/r/rustjerk/comments/av5pog/higherres_rust_evangelism_strike_force_image/)
[3]:
[https://www.reddit.com/r/rust/comments/ifkrvg/i_printed_rewr...](https://www.reddit.com/r/rust/comments/ifkrvg/i_printed_rewrite_it_in_rust_swag_for_students/g2s1bh9)

~~~
ColanR
> “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-Curunir
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"?

~~~
ColanR
Maybe a clearly published outline of where their language fits in the
ecosystem of languages that are out there. e.g., it improves on these aspects
of C++, gets these traits from python, fixes these weaknesses of C, but
doesn't improve on X, and Y is something that C still does better.

Or something like that. Then there's something out there and clearly visible
that immediately shuts down the zealotry because the maintainers have said
exactly where Rust stands, and what they think it's great at, and what it
doesn't do. Which seems like the problem: that the zealots are giving the
impression that Rust is better than C for everything.

~~~
whyever
I don't really see how that would stop the zealots. They are already getting
pushback within the Rust community.

~~~
ColanR
It sure wouldn't hurt.

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

~~~
steveklabnik
> 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_dan
> we already have one alternative implementation that's good enough to compile
> the compiler

That's really interesting! Can you link it?

~~~
steveklabnik
[https://github.com/thepowersgang/mrustc](https://github.com/thepowersgang/mrustc)

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

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

------
jolux
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
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
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
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/)

------
marcosdumay
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
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?

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

------
dathinab
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
It’s not a job, you don’t have to feel bad about that ;-)

~~~
dathinab
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.

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

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

------
CalChris
_Concurrency is generally a bad thing_ and specifically it is a good thing.

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

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

------
codygman
> Consider Go, ... addressing them with the simplest solution possible.

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

------
Koshkin
"Oh say, can you C?"

"In Rust We Trust."

~~~
ColanR
Very clever, but off topic. :)

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

------
batsigner
This post is just decompressed twitter trolling.

