- The ABI is not stable yet

- The compiler is not the fastest

- Doesn't work on all architectures (compared to C in the embedded space)

While those are potential downsides, they don't have to be. It all depends on what you're using it for and the language you're coming from. I would ignore the "learning curve" comments as they're (in my opinion) irrelevant. You learn it once and then reap the benefit for the rest of your career so a couple of months of investment doesn't sound that bad.

From personal experience: Our company had tailor made use-case to use Rust (switching from Python), more than Go. Experiments were performed and Rust outperformed Go in all aspects (time, CPU, memory). Everyone acknowledged but CTO (who knows C/C++ very well, he is a filesystem developer) decided to select Go. CTO was bullish on Rust to start with but developed cold-feet later. He told me that the only reason was that it is easy to train people in Go than in Rust. This one single thing trumped everything in my case. When I look back, I see his point & I respect that.

While issues like portability, eco-system, ABI stability, etc are important, these are not inherent problems with the language itself. They will get better over the time.

My revert was mainly due to my realization that yes, Rust does take quite a bit to spin new devs up, it can be far easier than people give it credit for.

Specifically I found that I was able to write Rust code that looked, felt and prototyped just as fast as Go code. The complexities of Rust come when you push beyond Go's feature set, namely lifetimes and the myriad of Generics features. Yet, if you don't use those, if you pretend Rust is Go, the language is far far more approachable to new devs.

You may ask "what's the point then? Why not just use Go?" as I did. The answer imo, lies in if you ever expect to want or need features beyond Go. If you're using Go but need something more you're sort of stuck. You'll force your way through fitting Go's square peg into a round hole, or be forced to rewrite in something else. However if you're already using Rust you can simply use more advanced features in the specific areas you need.

I think of Rust as a "full-time" language - it doesn't lend itself to small, part-time use like languages such as Python or Ruby.

It is not an immediatley approachable language and can appear intimidating at first. It feels big, although this is subjective and for some a large language is not a problem.

I don't like the terse and cryptic syntax of Rust but this too is subjective and for many programmers it's something easily overcome. I do wonder though: what would people's perception (and takeup) of Rust have been like if the language had syntax closer to Ruby or Python?

I agree. I have been learning Rust over the past year or so and I'm still getting hung on areas where trying to borrow an already borrowed value while in a loop. That said, the compiler error messages are typically very good.

> Not considering toolchain / language maturity & stability, what are disadvantages of rust?

You can't really "not consider" these things - they're big factors in any decision you might want to make. If you think the Rust toolchain and language ecosystem are half-baked and not yet ready for prime time, that's quite important!

When you start writing programs in Rust you can often back yourself into a corner. These corners are often unsafe, but allowed patterns in other languages.

Sure, you can solve this by forcefully Mutexing everything, or you can often learn a "better" design which doesn't involve trying to prevent race conditions. These batter patterns are not exclusive to Rust and can be brought to many languages. It's just that most languages won't help you discover them.

So what I'm saying is that learning Rust can make you a better X developer, even if you don't stick with Rust. Especially if you really learn it, and get a feel for what patterns to avoid, etc. If you just learn the syntax Rust isn't likely to help you, imo.

To answer to your question, I will say it will take you time to understand and to be productive with Rust.

But, please stop, Go and Rust can't be compared, they don't have the same goal in mind.

Nonsense. For _certain things_ they can't be compared, but many things they can be. If I can compare Python and Rust, why can't I compare Go and Rust?

For example, I chose Rust at work recently for a project that was previously written in Go. How do you think I made that decision if I can't compare them?

Fundamentally yes, they're different languages. But seeing as Rust is quite usable in many areas it's perfectly valid to compare them. I see this "they can't be compared" so frequently that it's comical to me. Not trying to be insulting here, it's just perplexing.

I think it must stem from back in the day when Go was "incorrectly" labeled as a Systems Language. People ended up thinking that Rust and Go were competing for the same space. That there was bound to be a winner and a loser. They can happily co-exist, they're not at war, but they can and will frequently be compared. They have a ton of overlap.

For me, Rust fundamentally doesn't offer anything that 1) I want and 2) Python doesn't already have. The language I want is a better version of Python, not a better version of C++.

Eg, Rust often gets criticized for it's Syntax (rather, lots of it, ::<>, etc.). Yet, this isn't a downside in Rust, it's merely an opinion.

I'd be curious though what you think these downvoted into oblivion criticisms are? The ones here have been well received, and are quite fair. I'd be curious to see a criticism that's not widely agreed upon.

Have you tried Nim? https://nim-lang.org/

Very Pythonic if you ask me.

    julia> 2^64
    -9223372036854775808

Based on your other comments, if you're OK with a more Ruby-flavored syntax, you could look at Elixir. Its designers put a lot of effort into pervasive immutability and a solid developer experience.

So it's not that your point isn't valid, but it can't be extrapolated to general safety or high-level-ness; this is a really specific feature to rest your decision on. Arguably Julia has an advantage here because you can easily check correctness of an algorithm using arbitrary precision types and then use machine types in production, which is pretty handy.

Another reason for saying so is because it's an example of performance meeting safety. Julia, Nim and Rust choose performance, ostensibly to score well on benchmarks which I think is irresponsible. Python choose safety which I prefer. In the future, these languages will again choose performance ("zero-cost abstractions") to preserve their benchmark rankings over essential safety and programmer ergonomics. Another area in which these languages make compromises for performance is in the legibility of stack traces.

It is true that Python doesn't do fractional arithmetic correctly which I think is a flaw. Newer languages should use rational arithmetic by default. 6/5 - 1 should evaluate to 1/5 not 0.19999999999999996.