1. About 15 years of experience in C++, 2-3 years in Rust.
2. I'm retired now, but I would have considered Rust for any greenfield project that didn't have a compelling reason to pick C++ (e.g. mandatory interop with an existing big C++ library).
3. Rust nearly every time. I sometimes use a layer of C++ as an FFI shim, such as when writing a gRPC client/server (the Rust libs there aren't mature).
4. The library ecosystem. Rust's crates.io seems full, but if you scratch the surface it's just a bunch of half-baked hobby projects at v0.x versions. And Cargo (the most popular build system for Rust) has essentially no support for multi-library packages, so instead of something like GLib (a single dep with lots of functionality) it's common to see even trivial programs depending on dozens or hundreds of half-baked hobby projects at v0.x versions.
5. Most of the Haskell/ML-ish functionality, such as traits and proper enums. I'm currently in the middle of a Rust project that's gotten much bigger than I expected (parsers are hard! compilers are hard! zero-copy is hard!), but it's still possible to make progress by leaning heavily on the type system.
I often describe Rust as "a dialect of C++ where the compiler forces Google Standard C++ on the world", or alternatively "the language you'd get if you hired a team of Haskell developers to write firmware".
Your thoughts about crates.io mirrors mine exactly. I'm becoming more and more interested in just ditching it entirely and using vendored checked-in (or submoduled) dependencies and managing the transitive dependency tree myself. Cargo&crates.io seems to have been inspired too much by npm. Lots of half-baked, abandoned libs that wantonly pull-in piles of other 3rd party deps and create a sprawling graph of dependencies that ends up with binary bloat and multiple versions of the same package, etc. etc.
somewhat OT, but what happened to haskell? a few years ago it was all over HN - now you hardly see any mention of it. surely this won't happen to rust?
Entirely different snack bracket. Haskell is great stuff, but not something you'll be able to practically staff a team and build with.
Rust is not nearly so "brainy." It's a much more pragmatic and conservative language.
And it's targeted in an entirely different domain -- systems programming. Haskell is a garbage collected pure functional programming language. Rust is not anything like that.
> And it's targeted in an entirely different domain -- systems programming.
> Haskell is a garbage collected pure functional programming language.
At the time there were many people trying to make a go of doing systems programming in Haskell. I remember lots of arguments about libraries using ByteString/Text vs String in their public APIs, where the research people were like "linked list of u32 is so conceptually pure!" and the systems people were like "what, no".
In retrospect, starting with a low-level systems language and adding safety turned out to be a better idea than using `ST a` to implement borrow-checking in a high-level GC'd hosted language. I can only say "it seemed like a good idea at the time...".
There was an era of stability in the Haskell project during which it was possible to write code for industrial purposes. A lot of people were attracted to the idea of a memory-safe language that compiled to native binaries, and there wasn't much competition in that area at the time.
Then the research-oriented nature of the language and community re-asserted itself with Haskell 2010, and there was a lot of churn in both the base libraries and Hackage. Around this time was when Swift, Go, and Rust had their first releases, all of which offered memory safety and varying levels of ML/Haskell inspiration. So Haskell was suddenly less appealing, and there were other options -- why file another perf-regression GHC ticket into the void when Go has an HTTP server built right into the stdlib?
I don't think it's got anything to do with Haskell 2010. Haskell is far more widely used in industry today than in 2010 by at least an order of magnitude. Heck, Mercury alone has about 250 Haskell programmers I think. That's probably more industry Haskell programmers than there were at all in 2010.
As far as I remember, most of the pillars of Haskell were hired to work on projects that were, at some level, competing with Haskell (by Microsoft, Facebook, Epic).
2. I'm retired now, but I would have considered Rust for any greenfield project that didn't have a compelling reason to pick C++ (e.g. mandatory interop with an existing big C++ library).
3. Rust nearly every time. I sometimes use a layer of C++ as an FFI shim, such as when writing a gRPC client/server (the Rust libs there aren't mature).
4. The library ecosystem. Rust's crates.io seems full, but if you scratch the surface it's just a bunch of half-baked hobby projects at v0.x versions. And Cargo (the most popular build system for Rust) has essentially no support for multi-library packages, so instead of something like GLib (a single dep with lots of functionality) it's common to see even trivial programs depending on dozens or hundreds of half-baked hobby projects at v0.x versions.
5. Most of the Haskell/ML-ish functionality, such as traits and proper enums. I'm currently in the middle of a Rust project that's gotten much bigger than I expected (parsers are hard! compilers are hard! zero-copy is hard!), but it's still possible to make progress by leaning heavily on the type system.
I often describe Rust as "a dialect of C++ where the compiler forces Google Standard C++ on the world", or alternatively "the language you'd get if you hired a team of Haskell developers to write firmware".