Why Rust in Production?(corrode.dev) |
Why Rust in Production?(corrode.dev) |
> Rust has a great developer experience. Its type system is very powerful and allows you to encode complex invariants about your system in the type system.
Usually this means: we have three people doing type-level magic, no one understands it, and when they inevitable quit no one can understand how this works and why it takes weeks to add a small change.
> Related to the previous point, the Rust community is still relatively small. It is hard to find developers with professional Rust experience.
This directly correlates with what was written previously: "Many developers enjoy working with Rust. It is the most admired language for the 6th year in a row". Enjoyment often comes from early adopters, and people trying the language for some side projects.
I'll admit, however, that Rust seems to have crossed the chasm in the adoption cycle.
> Rust has a famously steep learning curve. It is a complex language with many advanced features.
Combined with "It is hard to find developers with professional Rust experience" and "mostly training their developers on the job", stay away from it unless you know exactly what you are doing.
> more than 2/3 of respondents are confident in contributing to a Rust codebase within two months or less when learning Rust.
This is a huge amount of time. However, unclear: is this due to the language, due to being thrust into a new domain/role/job, or both.
Having said that - yeah, making good apis and abstractions that prevent mistakes takes time and some skill, and pays off gradually proportional to the scale and longevity of the project. And for certain things is not worth it. Being able to make a good judgment if enforcing something at the compile time / runtime / at all is worth it is part of the skill.
There's a middle ground, and I was specifically responding to the quoted bit: "Its type system is very powerful and allows you to encode complex invariants about your system in the type system."
Once people start "encoding complex invariants in the type system" it becomes an unholy mess only one or two people on the team understand. Usually an ad-hoc unspecified poorly thought-out type-level DSL dozens of level deep.
Personally, I found even Haskell's type system easier and nicer to use than fiddling with _lifetimes_ in Rust types. Everything else in Rust is falling nice into place, but lifetimes are painful, magical and very annoying.
This is how it is in all typed languages I've used. There will always be trivial propositions which the compiler cannot check and bending around that often means ridiculous type magic. Such is the life of library & framework authors.
Not enough to pay well enough, it reminds me of node.js in the early days.
I'm active in the community, do rust events but I can't find something that pays more than js consulting with untouchable companies.
I guess at some point I'll have to decide between money and my soul
Mostly agreed with the conclusion, too: the language still looks good, especially as a C alternative, and hopefully it will be usable in a more stable setting. Gradually trying it out does not feel like a pivotal decision though, that sounds overly dramatic.
Every microcontroller project I've worked on, as we approach maturity, goes through a round of freeing up ram and code space. Usually deleting strings, removing debug functionality, or shortening datatypes.. etc
Can I write rust code with the same footprint as c code?
17.5 million users versus about 6 million, basically the ones being driven by Google to Kotlin on Android.
Back to topic, I feel Rust is a great language for production on scenarios where having automatic memory management is forbidden, like in high integrity computing, GPGPU code, micro-controllers and such.
Everywhere else, a mix of automatic memory mangement, value types and eventually linear typing, are a much ergonomic approach.
Nowadays, with Java 21 and virtual threads, results might be quite different (and the default GC has changed as well).
I agree with the graphs being unreadable. The tables in the benchmark article are easier to read.
"Benchmarked on JDK 11, with G1"
"Rust, Go, Java, Python" in order, left to right, yes.
You write backend code as of you were writing frontend code, which is not enjoyable. You always have to think about who owns what.
And the whole crate terminology is just stupid. What am I, a dock worker or software designer?
No, to each their own but Rust does not have a great developer experience.
Compile times are long.
What do you gain in performance compared to Go? Not a while lot, and you pay with wasted time aka increased development time and more complicated thought process.
It's not for me, and when this blog says great dx, that means it's a propaganda post. In fact the whole article reads like it's trying to convince someone do something they don't want to.
Rust libraries will never be shipped by your distro’s package manager. Maybe a few exceptions for things that also have C bindings, but it will never be the default.
What languages/ecosystems is this not the case? Even with C/C++ you probably shouldn't be relying on your distro's package management for library and toolchain support.
Also, you do not need nightly unless there is some very shiny and new feature that you need that isn't on stable yet.
With Haskell (used for most tasks at work) I get the tools (GHC and Cabal) and most of the dependencies from Debian stable repositories, though loading missing ones from Hackage (but slowly moving towards not relying on Hackage at all). And keeping sources compatible with package versions from Debian repositories from version 9 to 12 (4 major versions, 6 years apart). With shell scripts, sticking to POSIX; with SQL ones, avoiding extensions and also doing fine.
At the beginning I was using stable without many problems.
I switched to nightly to access the last language features and I have no reason not to use it (I've never encountered a nightly bug in 4 years)
Haskell is my favourite language (if we forget prelude, exceptions, strings and a few other warts) but Rust wins hands down on pragmatism and getting things done. The tooling (cargo vs stack) is way better and there are more production ready libraries to do cool things.
I'm sorry do you not use https://github.com/clap-rs/clap ?
You still have to like, actively think about binary size in order to get things to be that small. But the smallest x86_64 binary rustc has ever produced is 137 bytes. How small your program is up to you, not Rust.
EDIT: Oh yeah, I left a similar comment with more details about a year ago: https://news.ycombinator.com/item?id=34032824
It illustrates the steps to take Rust from 3.6MiB executable to 400 bytes, by stripping more and more things away, and changing things.
Sure, ELF includes a lot of fluff but you're not deploying ELF on a microcontroller.
I was mostly trying to figure a 1:1 comparison. For example, If I write a Feature Control module in c and in rust, using the same design, are outputs similar?
seems like either no one has a good sense of that comparison, or it's a bad comparison and I don't understand why.
What I'm trying to avoid is having a space-saving task be "rewrite rust module X in c to save code memory"
Of all the reasons to complain about a programming language, the package manager not being elitist enough is certainly an original one.
The compiler has pretty good error messages, `rustc --explain` exists, "unreadable syntax" is a common complaint from people that expect everything to be C-like or Python (or are just trolling), "forced structures" is explained by Rust being a statically typed programming language.
> You write backend code as of you were writing frontend code, which is not enjoyable.
No idea what's this about.
> You always have to think about who owns what.
If your code is well-structured this is a non-issue. The types of people that complain about ownership are the ones that write messy code with chaotic inter-dependencies and unclear semantics.
And besides, you have to do that anyway in e.g. C++, only it doesn't enforce it, which leads to programmer error, which is worse. Or you can use reference counting if you have skill issue.
> Compile times are long.
Compared to what? They aren't much longer when comparing apples to apples: C++ with static analysis tools and Valgrind will have pretty much the same compile times. Again, a bold general statement that doesn't really say much.
> What do you gain in performance compared to Go? Not a while lot, and you pay with wasted time aka increased development time and more complicated thought process.
Performance in what? For non compute-intensive tasks you can obviously pick any language you are comfortable with. Obviously there's no point using C++ to serve a static site when a simple Python server will do. In benchmarks, Rust just murders Go in performance, so you are objectively wrong if you are talking about raw performance.
> that means it's a propaganda post
Based on your wacky arguments, I'd say that your comment is in fact propaganda.
You really must hate this thing we use instead of VMs nowadays.
The specific model is an MSP430G2231 [1] with 128 Bytes of RAM and 2kB of flash.
https://github.com/rust-lang/rust/issues/46213
In general Rust chases a "zero cost abstraction" ethos, so a lot of the type system niceties have no code or memory cost because the heavy lifting is done at compile time, not run time. For instance using specific traits for each GPIO pin ensures you won't accidentally apply some meaning meant for another pin, but the compiler will compile it right down to integers anyhow.
Things like options (how Rust deals with "null" values) are enums and usually incur a one byte penalty, but in some cases they can be compiled down to no overhead at all.
Different languages are different, and so it's tough to compare. You don't generally write Rust code in the same way you write C, and so a "using the same design" constraint on a comparison means that some folks will not consider it to be an accurate one.
In general, similar constructs have the same amount of overhead, that is, zero. Rust has additional features that are useful that can increase code size if you're not careful, but getting that back down doesn't necessarily mean abandoning Rust, but it may lead to "write the Rust closer to C." I am thinking of generics specifically here, monomorphization can blow up your code size, but you could either not use generics or use a few techniques to minimize it.
E.g. in Erlang GC is mostly negligible [1] (but you can put undue pressure on it, and on the underlying OS), there are realtime GCs for Java, etc.
But yeah the cost of GC is never zero.
[1] citation needed
Nothing depends on no GC.
I'm not anti-GC. I earn most of my living using GC languages. But there comes a time when the cost of power and hardware outweigh the value of GC. When that time comes Rust is an excellent way to solve it. I am, however, very "anti" the "no such time exists" position. That has never been and will never be true.
Also, why is it immature for Rust to ship a toolchain and package manager through a sidechannel, but not Haskell?
Haskell also feels less mature to me than C, with fewer POSIX functions being readily available, but as mentioned above, with Haskell (in my experience; the experiences indeed seem to differ) it is "one or two dependencies have to be pulled from Hackage across multiple projects and system versions", while in Rust it is rather "I failed to pull common logging and argument parsing dependencies on a single up-to-date stable system, and apparently one is supposed to install and update its compiler, package manager, and libraries separately from the rest of the system". Though some use ghcup or Stack, which also aim working without a system package manager, but at least a system package manager is a viable option.
It just seems weird to blame Rust for a problem you had with your package manager, when every modern ecosystem I can think of eschews distro package managers because of these problems.
I also don't mean to blame Rust's ecosystem (let alone the language itself) in the sense of complaining about it, though talking about this feels that way, and I thought it might be useful to clarify: it appears to aim less "stable" and more "cutting edge" (or "experimental") versions and practices than "stable" system distributions do, and than more mature ecosystems tend to do. Likewise, I wouldn't call having a slightly older compiler version in system repositories a problem with package manager: this is a useful approach for getting a stable system, relatively well-tested and with predictable changes. Not every system has to be this way, but in some cases it is useful, some people (myself included) generally prefer those. And unfortunately those fail to play together smoothly at the moment, but I view it as an issue arising between those and their approaches, not as a problem of one of those.
In my mind, it's that updating a dependency doesn't break existing installations, or knowing that an existing install isn't going to get borked by an update.
And this is not something that is applicable to ecosystems like Rust, where it's not really possible to break a Rust program because another Rust program needs a newer version of the same dependency that happens to be incompatible with the older version. In fact, you can compile one Rust program that links against multiple versions of the same dependency at incompatible versions without issue.
So the entire notion of the Debian model of package management doesn't really apply to Rust, and there's not any benefit to keeping an older version of the toolchain around. There are only negatives.
And Rust has strong stability guarantees. A newer toolchain will not break compiles of older code. Nor will Cargo's cache break compiles with an existing lockfile because another package needed different incompatible versions of the same dependency. It's designed to be stable from first principles, in a way that C and C++ builds are not.
This is kind of why you're only going to have a bad time if you want to use the system package manager to manage your Rust packages. It's not built for the same problem domain, and over constrained for the design space.
Not introducing breaking changes too often (so that you have to adjust configuration and custom software relatively infrequently), while applying security patches and other bugfixes, and being well-tested to work together are the first ones I think of. With "breaking changes" including changes to configuration, file formats, command-line interfaces, notable behavior, as well as library interfaces. Well, I think it mostly amounts to "knowing that an existing install isn't going to get borked by an update".
Supporting multiple dependency versions and stability guarantees indeed must help with avoidance of breaking changes in libraries, assuming the latest compiler version (or a dependency restriction: either compatible packages in system repositories or if there was such dependency resolution in Cargo), though probably not so much with fixes (I imagine there is less motivation to maintain stable branches and apply fixes to those then) and with integration testing. Besides, not all software is written in Rust: other packages and ecosystems must be taken into account as well. Likely more varied ecosystems can be handled more smoothly with NixOS or GuixSD, but I am not risking to use them on anything that should be reliable yet (maybe it is the time to look into those again though). But this kind of poor compatibility with stable systems does not seem necessary, especially for a language that is supposedly a safer alternative to C, while C is about as well-integrated into--and compatible with--common (POSIX) systems as it gets. Though then again, above it was noted that our experiences with C differ, but this is how I see it.
> how is one supposed to go around such a task, by the way?
There is not great tooling for this, because most people use the latest stable when starting a new project, and then rust being backwards compatible means things Just Work into the future. A vanishingly small number of folks use builds significantly older than that, since upgrading is generally trivial, and newer compilers have faster build times and better error messages.
As for newer compilers, I prefer to depend on system repositories and package manager for updates, and to stick to stable branches, so that things do not change too often. I see the appeal of rolling release distributions and cutting edge software, but not feeling comfortable using it for things that are supposed to be reliable.
EDIT: from clap itself:
> We will support the last two minor Rust releases (MSRV, currently 1.70.0)
So yeah, 1.63.0 is going to be quite old.
error: package `anstream v0.6.4` cannot be built because it requires rustc 1.70.0 or newer, while the currently active rustc version is 1.63.0
Either upgrade to rustc 1.70.0 or newer, or use
cargo update -p anstream@0.6.4 --precise ver
where `ver` is the latest version of `anstream` supporting rustc 1.63.0For anstream, the situation seems more difficult for you, as it doesn't seem that there's any (non-yanked?) release that supports <1.64.0: https://lib.rs/crates/anstream/versions