Rust is not a good C replacement (2019)
drewdevault.com
drewdevault.com
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.
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.
I'm still collecting data and it'll be hard to move away from Java's established position.
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)
And then massive concurrency was added.
Anyway go is mostly good for cases where C or a very C like C++ where used but C want the best fit, like certain server applications. Ironically it's design makes it also pretty bad for many other server applications.
Can you elaborate? genuinely curious
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.
“I don't like the quality of the article” wasn't an argument against today's earlier churnalist piece on "Soviet" control rooms, and it shouldn't be one for this either. The previous submission got well over a hundred upvotes, and Drew's additions to the conversation were well received.
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.
"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"
Well actually, it’s made to be safer, that’s why it’s fearless.
“I don’t care that it’s safer.”
???
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?
cargo build --release
I don't think Rust can replace C for CLI tools. It feels more like Java with these uber binaries.
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.
I haven't checked too much into Rust but I seem to recall it could be dynamically compiled. I would imagine any OS base tools would be dynamically compiled anyways.
Though considering the lengths that package managers go to for dependency management, maybe static linking everything is not a bad idea after all, I don't mind a 10GB OS image on disk as long as it isn't actually wasting memory.
Ripgrep is one of the most popular Rust CLI tools. It has ~2MB binaries: https://github.com/BurntSushi/ripgrep/releases (except the windows GNU variant which is 8MB for some reason, but a ~2MB windows MSVC variant is available).
That's certainly a lot bigger than the ~50kb for my system's copy of grep. But it's also faster than grep for most use cases (see: https://blog.burntsushi.net/ripgrep/), and has better support for things like unicode. Seems like a pretty good trade-off to me.
Release just specified the profile and you can override settings if it in Cargo.toml, e.g. to include debug info into release builds it disable lto.
(Edit) which is done by the linked tool.
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.).
The Rust compiler itself has lots of code in a really old style (much of it predates Rust 1.0, and originally used features that Rust no longer has). And it's generally considered to be maintainable code.
If worked with rust (in a company) for over two years using rust for large code based is substainable.
Sure at async fn's majorly changed for to do async IO, but that's basically it.
Beside the async IO story other changes where often minor and fast to fix even without cargo fix.
Also for a large code based there is zero reason to pedantically follow any new rust feature. It's actually idiomatic rust to not touch working/complete code just for some stile updates. And if you touch it anyway adding them cost you normally less than a minute. (Except async fn.)
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.
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.
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?
> which obviously changes frequently.
Not nearly as much as you would think. Everything that doesn't need a `#![feature(...)]` at the top of your crate never changes. Most `#![feature(...)]` flags enable things actually change pretty rarely - you can definitely go years on nightly without hitting a breaking change if you're conservative in your conservative in you feature set.
> 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.
That would be a nice feature to have! But I bet that you would find that if a crate currently needs nightly, it needed nightly from basically the start.
There are some tricks to achieve this, but they’re all rather cumbersome.
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.
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
Floating-Point types: 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.
range and mod types as in Ada would also squelch a bunch of C's shitastic undefined behavior bullshit.
And your comment about just implementing it via a feature flag would be the way to go.