
Rust sucks because - sgt
https://wiki.theory.org/YourLanguageSucks#Rust_sucks_because
======
chrismorgan
> LLVM's optimizer considers undefined behavior a license to kill. Of course,
> that only matters in unsafe code,

We’re not quite there yet with defining rigorous semantics for unsafe code
(there are still a couple of undefined things at present), but Rust _does_
intend to rigorously define all behaviour. So this is a quibble which is being
dealt with.

(Note that there’s still the odd rustc bug involving LLVM doing something it
shouldn’t, but those are just bugs. See [https://github.com/rust-
lang/rust/issues?q=is%3Aopen%20label...](https://github.com/rust-
lang/rust/issues?q=is%3Aopen%20label%3AI-wrong%20label%3AA-LLVM) for a
couple.)

> but you need unsafe code for anything complicated.

… _what?_ Somewhere deep down in your dependencies, maybe, but for most things
you _really_ don’t need unsafe code.

\----

Most of the rest of the issues are either Rust immaturity (compiler is slow,
_& c._) or tradeoffs that the language has made (String vs. &str). There are
definitely some legitimate criticisms in it.

~~~
hyperpape
>> but you need unsafe code for anything complicated.

> … what? Somewhere deep down in your dependencies, maybe, but for most things
> you really don’t need unsafe code.

If anyone has an account or feels like creating one, that line really should
be changed to "unsafe code can't always be avoided" or "fundamental types like
Vector are implemented with unsafe" or something similar.

~~~
all2well
>fundamental types like Vector are implemented with unsafe

That's kind of the point, though: Vec provides a safe interface over behavior
that would otherwise be unsafe. You could as easily complain that C is
fundamentally implemented in machine code without any type safety.

~~~
hyperpape
I agree that it's not a huge problem. But it does communicate accurately where
unsafe appears, unlike the existing text.

------
abiox
> Overly terse named types and keywords that don't communicate their purpose,
> like Vec and Cell

i'm of the opposite view here; though, i think i get where this is coming
from.

for me, if i look at it from a "broader timeline perspective", the length of
keywords (like say "function" in JS) is mildly annoying to me. especially if
they're high frequency.

over time, familiarized keywords essentially "fade into the background" and
afterward just occupy precious horizontal space, but provide a valuable sort
of visual shaping or pattern.

given this, i love the elements of terseness in rust syntax. my identifiers
are what i want to be more expressive and descriptive. this combos well: terse
keywords and stdlib elements contrast excellently with longer identifiers and
make it easier and faster to read (for me).

~~~
erikpukinskis
I used to be annoyed by "function" in JavaScript. That was when I thought the
main job of a programming language was to help brilliant programmers write
code in the most efficient possible way.

My thinking has changed. Lately I think the job of the language is just to
provide variable assignment, function calls, and a couple other basics. Most
programming languages go far above and beyond and they become impossible to
use for beginners, which means they can't be used on a diverse team. And
worse, they tempt intermediate programmers into using complex control
structures instead of doing the design work to figure out which boring-ass
array processing functions they actually need to write.

I think the core challenge of programming is to write code that
_inexperienced_ people can understand quickly. Partly because your teammates
may be inexperienced. Partly because 2 years from now _you_ will be
inexperienced with respect to this part of the code. Advanced programming
language features are generally antithetical to that. Terseness is
antithetical to that.

Instead, we get giant codebases that require full time attention from an
expert programmer, in order to have any chance of extending anything.

I want code that uses the most basic possible programming primitives. I names
to be as verbose as necessary so you don't have to look a lot of places to see
what's happening. And I want the data model to be as simple as possible.

I want to see that the programmer told the rest of the organization "No" over
and over, and that the code does very little, and uses childlike tools to do
basic things. I am not impressed by wizardry, and trivialities like "function"
versus "def" don't matter to me anymore at all. I am impressed when someone
makes something small and simple and good.

~~~
parenthephobia
> the core challenge of programming is to write code that inexperienced people
> can understand quickly

This is a pipe dream. For anything significantly non-trivial, programming is
inherently complex. Designing the language so that code is forced to be
"simple" at the lowest scale just pushes that complexity up to larger scale
code structures.

Trying to make programs easier to understand by limiting the expressivity of
the language is like trying to make quantum physics easier by reformulating it
without using complex numbers. Whilst it may well make each individual step of
a calculation easier to understand, it doesn't make the whole any easier to
comprehend.

~~~
erikpukinskis
I agree you can't force code to be simple with a language. Writing simple code
is an art, and a cultural practice.

I disagree strongly that code in non-trivial systems must be inherently
complex. Complex code can be broken into simple pieces, but it takes time to
find the abstractions. I spend at least as much time making my abstractions
better as I do making things work. Many managers won't let you take that time.

> Whilst it may well make each individual step of a calculation easier to
> understand, it doesn't make the whole any easier to comprehend

You're used to the notion that programmers must keep entire codebases in their
head because that's the norm: leaky abstractions where any part of the
codebase could have implications for any other part. That how we in the tech
world tend to build things in 2016. You need to understand the whole before
you touch any part of it, or you'll likely break things.

But when you find the right abstractions, you don't need to understand the
whole codebase to get things done. In fact, that's how you know your
abstraction is good. You stop seeing problems that span it.

------
maxlybbert
I read the entries for a few other languages that I am familiar with, and
found the criticisms to be shallow, misguided, and silly. I don't have any
confidence that the Rust criticisms are any better.

~~~
metalon
I thought the same, e.g. this:

> There's actually a special Haskell search engine to search for anything
> related to Haskell, because of the funky syntax not playing nice with
> Google.

Hoogle is so extremely convenient, it's a big plus imho

~~~
codygman
Hoogle also exists to allow users to search for functions by type signature,
not mentioning that is an unfair mischaracterizes.

------
alimbada
> Overly terse named types and keywords that don't communicate their purpose,
> like Vec and Cell.

I completely agree with this. This type of naming convention shouldn't even be
a remote possibility in this day and age. I find it extremely difficult to
read coming from mainly a C# and Java background.

~~~
eptcyka
Were you expecting the same keywords for the same things in a different
language? The original Rust designers had a goal to have all keywords be under
5 characters in length to try and make the language as small as possible. I do
not think that this is an issue. But to each his own, I guess.

------
bryanlarsen
While true, it's missing the forest for the trees.

Rust sucks because it takes several weeks to become proficient in its use.

That's a huge expense for any person or company that wants to use it. It may
be worth it long term to switch to Rust, but if you fail in the short term
there may be no long term to worry about.

[https://news.ycombinator.com/item?id=13430108](https://news.ycombinator.com/item?id=13430108)

~~~
panic
Would professionals in any other industry complain about a tool that took only
weeks to learn? If a particular language really does help us write better
software, a few weeks is a tiny amount of time to spend learning it. I think
we focus too much on the experience of the people who write programs and not
enough on the experience of the people who use them.

~~~
kazinator
They would probably complain if there were 50 different tools (each of which
taking only weeks to learn) all promising to solve the same problems in
different ways, and each largely excluding the other 49.

------
ainar-g
The website is slow for me, so here's a cached version in case anyone needs
it:
[https://webcache.googleusercontent.com/search?q=cache:IdCGkc...](https://webcache.googleusercontent.com/search?q=cache:IdCGkcAL4Z4J:https://wiki.theory.org/YourLanguageSucks+&cd=1&hl=en&ct=clnk&gl=ru&lr=lang_de%7Clang_en%7Clang_ru)

"Why Rust Sucks" is at the very end.

------
indeyets
IDE Support: [https://intellij-rust.github.io](https://intellij-
rust.github.io)

------
sumitgt
Looks like C# has one of the smallest list of complaints. :)

[https://wiki.theory.org/YourLanguageSucks#C.23_sucks_because](https://wiki.theory.org/YourLanguageSucks#C.23_sucks_because)

~~~
discreditable
Meanwhile Javascript's is the longest!

[https://wiki.theory.org/YourLanguageSucks#JavaScript_sucks_b...](https://wiki.theory.org/YourLanguageSucks#JavaScript_sucks_because)

------
camus2
Rust is nice and developers absolutely get why it works the way it does( to
provide strong memory safety guarantees, eliminate usual bugs found in C/C++
programs).

Here is the issue: A lot of developers actually like the C/C++ freedom they
have even if it leads to horrible bugs as they are used to program the way
they do.

Others are people that don't care about memory management and are fine with
GC, nil errors and race conditions.

