> 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.
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 ?
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?
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"
This was quite the great experience!
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.
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.
