
Rust severely disappoints me - geodel
http://esr.ibiblio.org/?p=7294
======
Manishearth
This post is pretty inaccurate.

A lot of this is discussed in the reddit thread
([https://www.reddit.com/r/rust/comments/5nl3fk/rust_severely_...](https://www.reddit.com/r/rust/comments/5nl3fk/rust_severely_disappoints_me/))

For one, string concatenation is the second example in the documentation for
strings, and is very googleable.

I can't believe the author linked to a 2 year old closed issue about epoll and
assumed that the single comment there is still applicable. mio has existed for
more than a year now. You can find epoll crates on crates.io.

The further comments about CSP have to do with solely the stdlib not wanting
to have selection. It is true that there's no consensus on which third party
crate to choose, but this is sort of the spirit of Rust's ecosystem; you can
just pick the one that fits your needs best.

Currently, however, the Rust team _is_ working on a "blessed" async IO
solution that the ecosystem is converging on
([http://tokio.rs/](http://tokio.rs/)). I'm not expecting a newcomer to the
language to know that, this comment is more of an FYI for folks who are
interested in using Rust for this in the future.

While Rust doesn't have a BDFL, the core team is a pretty small (and mostly
like-minded) group, and they do set design direction and priorities.

\------------

It is true that Go is simpler than Rust and easier to pick up. I like Go for
this (and other reasons). Rust _does_ take effort to get started with. We can
improve here, but I'm skeptical we'll ever reach the same level as Go.

~~~
jandrese
IMHO, the author of the article ran into the same thing I did when starting
Rust. You look at the official docs then want to do something slightly
different so you hit up Google and run across mostly obsolete information and
examples that don't work anymore.

~~~
Manishearth
Yeah, this has been slowly reducing, but is still somewhat an issue. Not an
excuse to rely on a two year old closed issue, though.

------
dj-wonk
I understand that new things can be hard. But valuable skills pay back in more
ways than one.

Yes, getting comfortable with Rust takes time. I'm still on that journey.
However, I am encouraged the simple maxim: "Discomfort is often a good sign of
learning."

Learning and productivity are coupled. If you stop investing in learning, your
productivity will not grow optimally. (Argument from the "Capability Trap", a
systems dynamics assessment of working harder versus working smarter.)

I'd like to share two personal examples of tough learning curves.

1\. Learning inferential statistics deeply can be challenging sometimes. It
requires that I think differently and more precisely. Still, I have found it
rewarding.

2\. I had a large amount of cognitive dissonance in a particular class in
graduate school where we read widely and shifted perspectives on sustainable
development every week. The economic, environment, moral, human, and
architectural aspects of the topic do not neatly reconcile. This awareness is
really important and builds the ability to connect with people with many
different worldviews without dismissing them.

It seems to me that sometimes people don't see _why_ a set of new concepts or
approaches is _worth the effort_. I get it. I can see why someone might get
disappointed at first. But I think such a view is too narrow. Once you get
over the hump, I have found the learning curve pays off.

~~~
newsat13
Sorry, this logic makes no sense. Just because you are having discomfort does
not mean it has any value.

~~~
dj-wonk
I think you would agree that learning is not only about adding more
information to your brain. Concepts must be reconciled. For many people,
feeling some internal inconsistency (call it cognitive dissonance if you like)
is strongly associated with challenging one's preconceived notions. The
trigger is often external stimulus. That's why many people find that feeling
uncomfortable is a useful proxy to pushing yourself intellectually.

~~~
newsat13
I honestly don't understand what you are talking about.

~~~
dj-wonk
The general topics I'm talking about quite interesting:

    
    
      * https://en.wikipedia.org/wiki/Cognitive_dissonance
      * https://en.wikipedia.org/wiki/Learning_curve
      * https://en.wikipedia.org/wiki/Psychology_of_learning
    

I recommend this systems dynamics paper for proposing a simple model to help
quantify the tradeoff between investment and execution:

[http://web.mit.edu/nelsonr/www/Repenning=Sterman_CMR_su01_.p...](http://web.mit.edu/nelsonr/www/Repenning=Sterman_CMR_su01_.pdf)

The logic there applies to many contexts, including:

    
    
      * working "smarter" vs. harder
      * investing in a new skill vs. executing using existing skills
      * investing in workforce education vs pushing them to work longer hours
    

If you are interested in a conversation and trying to understand, may I
request that you ask specific questions?

------
kibwen
Previous discussion on /r/rust:
[https://www.reddit.com/r/rust/comments/5nl3fk/rust_severely_...](https://www.reddit.com/r/rust/comments/5nl3fk/rust_severely_disappoints_me/)

------
CalChris
_The learning curve was far worse than I expected_

This has been true for me as well. Rust seems to have gratuitous syntax. If C
did something and there was another way to do it then that other way was
chosen.

With C if you want to return the value 42 then you say _return 42_ ; With Rust
you say _42_. There is a return statement; it just can't return anything. If
you say _if (a == b)_ Rust says:

    
    
      warning: unnecessary parentheses around `if` condition 
    

I'm willing to put up with this nonsense because of the safety guarantees. But
really, it reminds me of _Bananas_ :

    
    
      In addition to that,
      all citizens will be required
      to change their underwear
      every half hour.
      Underwear will be worn on the outside
      so we can check.
    

Edit: I got this a little but not a lot wrong. _return 42_ is supported but
then it isn't clear at all why _42_ is necessary. So my complaint of
gratuitous syntax stands as does my respect for Rust's safety guarantees.

~~~
Manishearth
Be aware that there are plenty of languages out there that have these same
syntax decisions. Rust did not choose things because it wanted to "not look
like C", if anything Rust has tried to keep its syntax roughly C-like with
braces and stuff to not be too surprising. Rust avoids parentheses in if
conditions because Rust enforces braces in if bodies -- you only need one or
the other for parsing to work. C chooses the opposite decision, and C has
plenty of problems with omitting braces.

Also, `42` will only return at the end of a block. It's _different_ , but not
a magical return that can be placed anywhere. The return statement works
exactly like C.

"Rust's syntax is different from C" is perhaps the mildest criticism I can
think of Rust. Thank you.

~~~
fjrieiekd
In fairness, it's harder to learn Rust as one has to be aware of when and when
not to put semi-colons, otherwise the compiler chokes with an unhelpful error.
It also looks very weird to see a trailing value just hanging at the end of a
long function.

I much prefer the decisions Swift made in this area, with no semicolons and
implicit returns only for short functions.

This isn't to knock Rust or the work that you guys do, just a part of the
language that can be learned, but does impose a speed bump during that
learning process.

~~~
Manishearth
I mean, yeah, but you can say the exact same thing about braces in C. Rust
lets you use explicit return all the time (with semicolons everywhere), _if
you want to_. C lets you use explicit braces all the time, _if you want to_.

Rust also lets you use expression returns by omitting semicolons, which is a
common programming style. C also lets you omit braces, which is a common
programming style. Being common programming styles, you have to deal with them
often. Both are a bit confusing to wrap your head around at first. I find that
Rust's confusingness is fine because you can't goof up with it; the compiler
will error if you do. C on the other hand will happily let you mess up your
braces and still compile.

Again, this is _different_ , not worse.

------
newsat13
Rust is trying to solve well known problems. What is unique about rust is how
it solves them. To emphasize that, what is required is a document that clearly
explain how it's done and how the syntax of Rust is helping the cause.

Instead the tutorial is filled with printf! (Saying it's a macro. What is !
doing there? Why is it needed) and then &mut Str (I already noted Str is
mutable, why do I need mut again). The tutorial comes across as very
apologetic (using phrases like it's complex, will read later etc) instead of
being confident about the issues being solved.

What I find lacking is a document that can explains quickly what is being
solved, how it's being solved and general overview of the language. I don't
know of any language that cannot do this. Nobody is picking Rust as the first
language. One should just assume that people already know C/C++/Java etc
coming to learn rust.

I will appreciate any links to help my Rust journey (please no books!).

~~~
eridius
Why no books? You're explicitly rejecting the most useful documentation there
is. Maybe you mean no printed books by third parties, which would be a
reasonable restriction, but [https://doc.rust-
lang.org/book/](https://doc.rust-lang.org/book/) is online and written by
people involved in the rust language development.

~~~
steveklabnik
... and [http://rust-lang.github.io/book/](http://rust-lang.github.io/book/)
is even better!

~~~
eridius
Is that the new version of the book? I was wondering where that was. I grabbed
my link from rust-lang.org. When will the new book take its place?

~~~
steveklabnik
Yes, this is the second edition.

My coauthor will not allow me to prognosticate on dates :)

~~~
eridius
That's understandable, as long as you don't procrastinate either ;)

------
cpeterso
It seems like there is an opportunity for Rust to improve its learning curve
by adding an "easy std" library that wraps some of the byte juggling
headaches. People coming from scripting languages or who just want to write a
quick program, for example, might not care that using a + operator to
concatenate two string objects might implicitly allocate memory. And they
still have strong static types and the option to access bytes when necessary.

~~~
eridius
People who want to write code as if it were a scripting language might want to
just pick a different language than Rust. Nobody said everybody has to write
in Rust. Either Go or Swift might be a good choice for those people.

------
carlosdp
There is no such thing as a "simple IRC server" =P Never a great choice to
evaluate a language with imo.

------
smcdow
I don't have the time to learn a new language that doesn't expose POSIX/Linux
APIs. I may never use them, but I want them there in case I need them. You
never know.

~~~
steveklabnik
Rust does, by the way.

------
serge2k
> I have discovered that Rust is not, or not yet, a language suitable for
> long-term infrastructure work

because it's missing an API and you can't write your concurrency the way you
want.

I don't think that's a very strong argument.

That learning curve is nasty though. Too much is too tricky to get right.

------
GFK_of_xmaspast
The obvious explanation is that ESR is not actually as masterful a programmer
as he thinks he is. (Also of note that it only took two comments before one of
his readers starts getting mad at the SJWs)

~~~
eridius
Wow, the comment thread on that page is incredibly toxic. I still don't
understand how the commenters there think that a discussion about the
technical merits of a programming language has the slightest thing to do with
social justice.

~~~
CyberDildonics
I agree with you and also think the comments are toxic, but there is no doubt
that Rust decided to mix their language with the idea that the creators need
to dictate what is ok to say.

~~~
eridius
Please elaborate. The only thing I can think of that comes close is the fact
that the community forums for Rust discussion that are moderated by the Rust
team have codes of conduct. But that's a very good thing! And if you don't
like that for whatever reason, then you can go use some discussion forum
that's not moderated by the Rust team. Nobody said you're forced to use
r/rust, or #rust-lang, or users.rust-lang.org to talk about Rust. But
regardless, rules of conduct on public forums are not the same thing as saying
that the language itself is in any way associated with social justice.

~~~
CyberDildonics
But you do agree they dictate what is ok to say on reddit, irc, newsgroups,
and github correct? I've seen people scolded for saying 'hey guys'. You can
say that is a good thing, but to me it seems like a passive aggressive way to
show authority over someone with a virtue contest.

The problem is that it turns a meritocracy into something that can be
sidestepped and warped by one person claiming to be offended. In practice
someone scolds another person for something that they say might offend someone
reading.

I also haven't seen any sort of evidence that it solves a problem. It seems to
me to be a solution in search of a problem. I don't think it magically takes
care of toxic people.

~~~
Manishearth
We don't ban people for saying "hey guys", we politely tell them that not
everyone is a guy and that's pretty much it.

I can name plenty of women that I know that are put off from participating in
such communities because everyone just assumes that they are male. Individual
occurrences are nbd, but in aggregate it gets really annoying. It's a good
thing to teach the community to avoid such behavior.

The Rust community is one of the nicest online communities I've come across.
We get feedback every week from folks happy to participate in the community
and contribute to ecosystem/core because it's very nice. I'd say that's plenty
evidence it's doing some good.

~~~
CyberDildonics
First, you are equating a blanket 'hey guys' with assuming everyone is a guy
which is nonsense. It is a generic greeting, and you decide it is worth
flexing authority over another adult, not to mention it is the definition of
bike-shedding.

Then, you are attributing people's hard work of being helpful with a 'code of
conduct' which is unfair to their efforts. The people helping build up rust
aren't doing it because someone decided to dictate the greetings they can use.

~~~
Manishearth
The code of conduct doesn't dictate which kind of greetings to use. Nobody has
dictated that in the Rust community. Community members just politely ask that
you don't use some greetings. Nobody will stop you from continuing to do so.

The "hey guys" thing isn't about intent. People are aware that you are not
assuming that everyone is a guy. They are asking that you be considerate of
people who have to deal with being misgendered all the time and made to feel
like they don't belong. There is no authority being flexed. It's usually
regular community members asking not to use "hey guys", not moderators. (This
is also a super rare occurrence anyway).

No, I'm not talking about helpfulness, I'm talking about people being _nice_.
That's exactly what the code of conduct is about, and it seems to achieve that
goal pretty well.

~~~
pitaj
> being misgendered all the time

Saying "guy" isn't misgendering because it's a gender neutral pronoun. People
call women "guys" all the time. Most people realize this.

