
Ask HN: What Are Downsides of Rust Language? - tellme_throwa
Especially on reddit &#x2F; HN, as well as blogosphere, rust is touted as one language to rule lot of things. Unlike, say Go, which draws lot of criticism, there are much less accounts on disadvantages of rust.<p>Not considering toolchain &#x2F; language maturity &amp; stability, what are disadvantages of rust?
======
dsirola
I would say

\- 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.

------
sudeepj
The biggest issue which is inherent to the language is the learning curve. I
feel there is limit beyond which language cannot be made easy to learn. I
still claim it is worth learning Rust, however my point should still stand.

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.

~~~
asdkhadsj
I made a similar decision quite a while back, though in the past year I
reverted that decision and am back to using Rust.

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.

------
0815test
[https://old.reddit.com/r/rust/comments/c0xwjd/all_i_hear_abo...](https://old.reddit.com/r/rust/comments/c0xwjd/all_i_hear_about_is_how_great_rust_is_what_isnt/)

> 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!

~~~
tellme_throwa
Well, I am trying to evaluate rust the language, because if the language is
good, as a student, time investment can be worth it...

~~~
asdkhadsj
So this is a bit off topic, but on the note of time investment, I'd definitely
say learning Rust is valuable for your mental model. Common patterns in
languages _(take Go for example)_ allow you to do unsafe things very, very
easily. Often simply involving pointers.

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.

------
totothrow
I think there is a part of criticism on Go which are not relevant. The
language has been designed to be "simple" and it do the job. The latest posts
on Go were only for the Karma, re-post, no new elements, no fair statements.

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.

~~~
asdkhadsj
> 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.

------
bjourne
Rust is criticized on in too, but you can't read the criticism because it's
downmodded to the background color. ;)

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++.

~~~
giaour
There are a few new languages competing for the title of “better Python,”
i.e., a language with Python-inspired syntax, optional typing, and native
compilation. Julia is trying to be a “better Python” for mathematical and
scientific computing, and Nim is aiming to be a better general purpose Python.
Nim predates Julia by a few years, but there’s a lot of excitement around
Julia these days.

~~~
bjourne
I've tried both and I don't think they are better than Python. For one, they
don't do integer arithmetic correctly by default:

    
    
        julia> 2^64
        -9223372036854775808
    

To me, that is simply not ok. The point of HLLs is that details like sizes of
hardware registers shouldn't matter.

~~~
one-more-minute
Python uses arbitrary-precision integers by default, unless you use Numpy, in
which case you end up with the same issue. It also uses machine floats by
default, which can give similar errors (so one could say "Python doesn't do
real arithmetic correctly by default", though of course neither does anyone
else).

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.

~~~
bjourne
Integer overflow is one type of bugs that can lead to catastrophic failures.
Think billing systems that suddenly starts paying customers rather than
charging them or rockets firing in the opposite direction. Therefore I think
you can say that Python is safer because it prevents one class of bugs that
these languages doesn't.

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.

