[necubi]

As someone building my startup [0] on Rust (and a fan of the language since ~2014) I don't think this is a very compelling list of points.

> Rust is overhyped

People are excited about Rust! Not sure why this is a reason you _shouldn't_ use the language.

> Rust projects decay

The text doesn't match the headline here; Rust takes backwards compatibility very seriously, and rust code I wrote in 2016 against Rust 1.10 still compiles with Rust 1.72 in 2023.

> Rust is still in beta

Mentions missing async traits, which is legitimately annoying, but the workaround with the async_trait crate works in practice

> The standard library is anemic

This is a tradeoff; big standard libraries become graveyards over time (the classic article on this: https://leancrew.com/all-this/2012/04/where-modules-go-to-di...). How long was Python stuck with a terrible HTTP client because that was the one in the standard library? In Rust we have an incredible, state of the art regex library because it's a separate crate and is allowed to evolve.

> async is hard

Rust's async is hard to get started with; it's a barrier to get over like learning the borrow checker and lifetime system. But once you do I've found it productive and incredibly performant.

--

Overall, I don't think that Rust is the right solution to all problems. Rust makes you think about everything you're doing, the ways in which your programs use resources, and every possible class of errors. This is incredibly useful for writing fast and correct software, but will be overhead for people who just want to move fast.

I also think that static memory management is not the right tradeoff for most application software, although a GC language with Rust's ergonomics and crate ecosystem would be amazing for those use cases.

I'd personally always choose Java over Go especially given recent developments like ZGC, GraalVM, and Project Loom which essentially makes Java a better Go.

[0] https://arroyo.dev

[nixpulvis]

>> Rust projects decay

> The text doesn't match the headline here; Rust takes backwards compatibility very seriously, and rust code I wrote in 2016 against Rust 1.10 still compiles with Rust 1.72 in 2023.

This hasn’t been my experience. Though it’s often not large changes that are needed. The bigger problem in my book is the crate ecosystem, which is riddled with abandonware. Though this issue plagues most all languages.

[icholy]

For all the praise cargo gets, the lack of namespaces seems like a pretty huge oversight :/

[necubi]

This is endlessly debated within the community (e.g., https://internals.rust-lang.org/t/blog-post-no-namespaces-in...), and there's no consensus on whether namespaces would be an improvement

[littlestymaar]

There's no consensus mostly because namespace proponent, despite all the noise they make, haven't been able to articulate a constructed argument about what namespace is actually bringing to the table.

For instance, most of them bring typosquatting as a problem that namespaces solve, yet they completely ignore namespace typosquatting: for instance instead of typosquatting `ripgrep` with `rigrep`, you'd typosquat `burntsushi/ripgrep` with `bunrtsushi/ripgrep`…

[goku12]

> Rust makes you think about everything you're doing, the ways in which your programs use resources, and every possible class of errors. This is incredibly useful for writing fast and correct software, but will be overhead for people who just want to move fast.

I agree with the reduction in development speed. But the cognitive load is less, at least for me. Rust's type system, error handling primitives, language server and compiler messages seem to guide and reduce the effort needed to write good programs. The reduced development speed is often an acceptable compromise for all the advantages Rust gives - especially the cognitive load. The language also seems to save a lot of debugging time - so the reduced development speed may not be of much consequence.

> Overall, I don't think that Rust is the right solution to all problems.

I guess this depends on how comfortable you are with the language. Rust is my second choice after shell scripts to automate things. The point is, your statement is correct for only a class of developers - those who are new to Rust. For others, it's just as good as any other language for almost all problems.

[pnpnp]

> ZGC, GraalVM, and Project Loom which essentially makes Java a better Go.

GraalVM is still nowhere near as nice as Go when you need to compile quickly. Last time I checked, the compiler needed orders of magnitude more time and memory to make a binary. ZGC is pretty nice, though.

[sureglymop]

Why not Kotlin instead of Java? I feel Kotlin is very underrated.

[FullyFunctional]

"Rust makes you think about everything you're doing ... overhead for people who just want to move fast."

Honestly, I find it much easier to move fast in Rust because for explorative code, I just bang out the code and used copy/clone liberally and once I have a skeleton it's usually a few iteration until rustc agrees to compile my code. Strong types makes it very easy for me to move fast. Doing this in C/C++ never worked for me and I always had to be extra careful lest I'd end up wasting a lot of time debugging.

I don't think Rust is over-hyped; almost everything I would have used Haskell for I do in Rust now.

[tome]

> I don't think Rust is over-hyped; almost everything I would have used Haskell for I do in Rust now.

As a Haskell fan this is very interesting! What sort of things do you write where you find Rust is a better fit? No code that I write in Haskell would be much better off without GC so I struggle to think of reasons Rust could be a better fit.

[FullyFunctional]

The _language_ isn't a vast advantage; the type system is near-identical (which is important). Both have their advantages, but the ecosystem (tools, crates, documentation, educational material, community) is so much better and richer in Rust, and of course wrt. performance and memory frugality, Haskell doesn't even compete. (I haven't never been able to use Haskell professionally because of that, but I use Rust for work now).

Something things about Haskell have always boggled my mind: integer overflows aren't caught (so much for safety) and the argument for this choice was performance, but at the same time, the default string type is a linked list of characters. In fact, Haskell relies far too much on lists. In Rust, the rough equivalent is Vec and Vec slices, which takes less memory, is much easier to parallelize, and is just much faster overall.

It is true that garbage collected languages allow more flexibility than languages with an ownership model (~ linear types), but so far I have been able to work with this and the end result usually benefits (I haven't had to use interior mutability yet).

Disclaimer: I'm neither a Haskell or Rust expert, but probably equally intermediate in both.

[tome]

Good to know about the ecosystem differences, thanks. Hopefully with some effort Haskell will be able to catch up there. And yes, Haskell gets some defaults wrong.

Regarding the type systems, they're definitely not near identical :) Haskell's is far more powerful. Perhaps you mean "the type systems are near identical for the kinds of programs I write". Speaking for myself, I could never work without a straightforward implementation of higher-kinded types, for example.

[FullyFunctional]

Well, now you need to define "Haskell". Haskell 98 has effectively the same type system as Rust (ignoring lifetimes). GHC does not. I guess I'm not a fan of the overly abstract types in later GHCs.

[tome]

Normally by "Haskell" I'd mean "GHC", since that's the Haskell that everyone actually uses, but even Haskell 98 has higher-kinded types!

[jasfi]

Nim is another alternative. Fast to write and excellent performance. Needs a bigger community though.