
Rust is not a good C replacement (2019) - fortran77
https://drewdevault.com/2019/03/25/Rust-is-not-a-good-C-replacement.html#update
======
ohazi
You're not going to write microcontroller firmware in Go, but several people
are doing just that in Rust, and it actually works quite well.

Philosophy aside, in actual use Go is a better Java, not a better C.

If your C program could have been a Java program, then go ahead and use Go.
But lots of C and C++ programmers who consider Rust and decline to consider Go
do so because the trade-offs that Go makes (garbage collection, error handling
ergonomics, generics, etc.) really aren't that appealing. Not everybody is
writing web servers for big-iron Google servers.

~~~
lostmsu
> Go is a better Java

Maybe off topic, but I highly doubt Go is better than Java. Have not seen
anyone convert to it from Java yet. Most come from Python.

~~~
valbaca
Java dev here (10yrs). I would like to consider Go a better Java.

I'm still collecting data and it'll be hard to move away from Java's
established position.

~~~
hbogert
I used java starting in high-school and got it extensively in Uni. I've been
using Golang for the last half year and it feels like I'm reliving the dark
ages in which java has lingered so long. Heavily patterned, but even dumber
than java 5 was.

Omission of language functionality and/or constructs is always attributed to
"this was intended, the language doesn't need it", however I DO want generics.
Go has remedied C's memory unsafety, yet meanwhile 1) it made no strides in a
multi-threaded model when it comes to safety. (can't stand Mutexes anymore) 2)
shooting yourself in the foot with nil's is still rampant. 3) A project
codebase file hierarchy is overly non-opiniated but everybody has "the one and
true" project hierarchy.

Yet all I hear is praise, I just don't get it. The reinvention of completely
static binaries is cool sometimes, and not having to deal with a bloated
runtime like the JVM is indeed a blessing, other than that, it feels like
we're praising the (relatively) new kid on the block because he comes from the
big city (Google)

------
jonahbenton
D almost certainly is the "C replacement" he would want to evaluate. Go and
Rust solving different problems and have very different ergonomics. D is most
C-like.

~~~
dathinab
I'm pretty sure that's not the case. Why I can't speak for him from what I
have heard about him I don't think he is a fan of C++ either. So D wouldn't be
his think either.

------
pixelbath
Link to previous discussion when this was posted in 2019, along with some
comments from the author (I guess it was considered inflammatory enough to be
flagged):
[https://news.ycombinator.com/item?id=19482669](https://news.ycombinator.com/item?id=19482669)

~~~
fortran77
It's astounding that was flagged and the moderators left it flagged. Why can't
we criticize Rust here?

~~~
gpm
It's poorly argued flamebait. I probably flagged it back then, and I
definitely flagged it just now.

Go look at the old discussion for lots of examples of why it is poorly argued.

If they argued as poorly against C I would probably flag that too.

~~~
platinumrad
I regularly see completely misinformed statements about C on this site and
none of them have ever been flagged.

~~~
gpm
Pretty sure I've flagged sufficiently misinformed comments about C a number of
times. But I do have a lower threshold for flagging stories than comments.

------
dathinab
Be aware that this article is by now over a year old.

While I respect him a lot for a lot of the work he does some of the thinks in
that article are IMHO just not right (and hadn't been a year ago either).

E.g. yes cargo is somewhat mandatory but no rust doesn't refuses to play
along. It's just that if you try to integrate rustc in the same way you would
do so for a C/C++ compiler it wouldn't work because they way rust build thinks
it's very different. So the best way to integrate rust into another build
system is through cargo, which had been extended with such and other use cases
in mind (emitting metadata etc.).

Also in practice you often have similar problems for C/C++ projects which
requires you to use that specific build system or port and maintain houndred
of lines of <make/python/..> code. Worse the isn't a standard way to do thinks
like running tests or seeing which features so exist.

------
jbreckmckye
"Rust is still unstable, so it will therefore never be stable"

"There were X new features in Rust's sixth year. I will now compare that to
the count of new features in C's forty-eighth year"

"People who are using new tools are interested in 'shiny' things. I am using
the word 'shiny' to suggest that their motives are cognitive weakness and
neophilia. It cannot be that these developers have contexts and needs I have
not yet reasoned about."

"I don't care about safety and segfaults, which means no-one should. I am
never involved in safety critical software and therefore safety features are
not useful."

And finally, if I may make a cheap shot:

"I would like to mount a robust defence of C based on its spec, well known for
lack of Undefined Behaviour"

~~~
santoshalper
Your first 3 points are collectively true and a fair rebuttal. That absolutely
does not change the fact that the level of instability in Rust would make me
very uncomfortable to use it for anything I want to last very long right now.
I am not obligated to be fair to my tools when I choose them. C is profoundly
stable, and that is a great asset for long-lived systems.

~~~
derefr
Rust has stable features, and unstable features. Code you wrote to target only
the stable features is never going to have to change.

There's a lot of Rust code in the wild (e.g. libraries) that targets unstable
features. That adoption is _necessary_ , just like drug trials are necessary:
people need to actually use something, to figure out whether it's good, and/or
what needs to be changed about it.

Most of the time, though, an unstable feature that gets used _a lot_ , is
stabilized exactly as-is—both because the huge usage proves that people are
happy with it working that way; and because there's now a lot of code in the
wild depending on that feature, and it'd be a shame to break it all without an
excellent justification.

This means that these libraries that were "only usable on nightly" because
they used a popular unstable feature, tend to become stable libraries, without
having to _do_ anything at all. And it's pretty easy to predict that this is
the way things will go (just by looking at usage numbers), and so start using
such libraries "early." There's very little risk of breakage introduced by
doing so.

It's not like there are features everyone begins depending on in Rust, that
just suddenly disappear one day. Not even unstable ones.

There are just (unstable) features that nobody likes or uses, and so they get
changed or go away. But if nobody liked them (including you), then what does
it matter whether they went away? You wouldn't have used those (again,
unstable) features in the first place. Libraries wouldn't have used them
either, so you wouldn't have used them even transitively. Such (unstable!)
features just wouldn't exist/matter to you. If their going-away was a problem,
that would mean somebody liked them enough to put them into something
crucial... which means they weren't that unpopular after all, and shouldn't go
away. (Or, at least, it means the author of a critical library is
stubborn/malicious, and in need of either a stern talking-to or a project-
fork.)

It's basically the same as having pre-1.0 packages in a package ecosystem. The
popular ones mature. The unpopular ones sometimes mature, and sometimes die.
But the unpopular ones are unpopular, so it's very unlikely you were depending
on them. (And if you were, you knew exactly what you were getting yourself
into.) So what does it matter if they die?

------
Koshkin
It’s not Rust’s fault. C is irreplaceable. Even C++, “a better C,” couldn’t.
Nothing can.

------
xiphias2
Rust doesn't try to be a C replacement. It's a great C++ replacement, for big
performance-critical projects: Mozilla Firefox code was written in C++, not in
C.

~~~
mem32
How can Rust hope to replace C++ when it in fact depends on LLVM?

~~~
lmm
Because Rust is a viable language for writing LLVM-like programs in (whether
by writing a new replacement or rewriting LLVM gradually).

------
inshadows
The innocent looking CLI thingy linked below turns into 68 MB binary when
built with

    
    
        cargo build --release
    

[https://github.com/mozilla/application-
services/blob/master/...](https://github.com/mozilla/application-
services/blob/master/components/tabs/examples/tabs_sync.rs)

I don't think Rust can replace C for CLI tools. It feels more like Java with
these uber binaries.

~~~
jamesmunns
[https://github.com/mozilla/application-
services/blob/master/...](https://github.com/mozilla/application-
services/blob/master/Cargo.toml#L39-L42)

They include debug info in release builds in their configuration.

If you run `strip` on the resulting binary, it will likely drop to like 5 MB.

~~~
inshadows
Wow, it dropped to 9.1 MB. Thanks for the info!

------
gfs
I don't know how significant a year is but this was written in 2019.

~~~
dathinab
Partially, mainly points be addresses have gotten some but slow improvements.

E.g. the part of rust but having a side is a think the rust community doesn't
like to much either so there is long ongoing with to _slowly and steadily_ get
to a point where you can have a spec. And that had gotten a bit more traction
this year I think.

Also I think there are by now more alternate rust compiler projects, through
no real alternatives and work in alternative non llvm backers. (Like there is
the idea to have a cranelift backed allowing much faster but also much less
optimized rust debug build.).

------
tick_tock_tick
While I'm not sold on the premise even the most fervent Rust fan has to
concede that idiomatic Rust changes several times a year which is nigh
unsustainable for any large codebase and no cargo fix is not a reasonable
solution.

~~~
dijit
Yes and no.

Granted, I'm a little bit of a newbie; but there seems to be a fervent use of
the 'nightly' compiler, which obviously changes frequently.

Stuff that targeted stable seems to still work. But a frightening number of
crates will only work on nightly.

And I'm not sure if there was a "version" that ever worked on stable, as that
information isn't immediately visible on crates.io.

~~~
dathinab
The person is speaking about _idiomatic_ rust code and seems to assume a large
code base needs to always be updated to be in the most idiomatic stile.

Most creates working on nightly only where tryfrom and async ones before that
became stable. Now it's still common to find embedding and "crazy" creates
(like there one which uses asm to hack in green threads) which work only on
nightly.

Most maintained creates work on stable by now, but it's not un-common to have
some nightly only features. Honestly I haven't run into a created I wanted to
use which requires nightly in a long time.

The only crate which did cause me headaches in the recent year was ring
(rustls,webpki) but that had gotten better.

~~~
gpm
> like there one which uses asm to hack in green threads

Hey, I implemented that at one point (crazy is a good description)! But I
didn't publish it on crates.io (just gitlab). Did someone actually publish a
crate that does this?

------
klysm
Certainly it depends on the application.

------
blackrock
I would like C functions to have default parameter values, and named
parameters.

There are some tricks to achieve this, but they’re all rather cumbersome.

~~~
Gibbon1
I'd like it if C had read arrays and range types like Ada.

~~~
blackrock
Doesn’t Ada have bounds checking?

This would be super useful, and prevent a large problem with buffer overflows.
It would be nice to have some flag to turn it off, to increase the speed mode.

~~~
thesuperbigfrog
>> Doesn’t Ada have bounds checking?

Yes. Ada numeric types can be defined to only allow a specific range of
values:

Integer types: [http://www.ada-
auth.org/standards/12rm/html/RM-3-5-4.html](http://www.ada-
auth.org/standards/12rm/html/RM-3-5-4.html)

Floating-Point types: [http://www.ada-
auth.org/standards/12rm/html/RM-3-5-7.html](http://www.ada-
auth.org/standards/12rm/html/RM-3-5-7.html)

>> It would be nice to have some flag to turn it off, to increase the speed
mode.

Many Ada implementations have compile flags to turn off runtime bounds
checking.

