Rust severely disappoints me | Hacker News Reader

Rust severely disappoints me

esr.ibiblio.org

46 pointsgeodel68 comments

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_...)

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/). 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.

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.

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.

I run into this a lot with other languages (c#). Google thinks older == better. It's terrible in any not so stable environment.

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.

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

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.

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

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

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?

Previous discussion on /r/rust: https://www.reddit.com/r/rust/comments/5nl3fk/rust_severely_...

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.

> With Rust you say 42.

This is, strictly speaking, not true. Rust is an "everything[1] is an expression language", and so if you have some sort of block, it will evaluate to its last expression.

But if you want to do an early return, you must write it, or if you don't like the default Rust style, you can write it.

This is consistent with other languages, just not C.

1: not literally everything, but most things.

> This is consistent with other languages, just not C.

TIOBE Index January 2017. The top 10 languages are Java, C, C++, Python, Visual Basic, Javascript, Perl, Assembly, PHP

Except for Assembly, where the comparison makes no sense, all of these languages have return expression. Yes, there are other languages that use last expression but they are most definitely not common languages and the most common languages use return expression.

It just seems unnecessary. It isn't clear what they got out of it.

Perl has implicit return.

Ruby has a similar pattern. It's a pretty popular language.

Correlation is not causation. Having return expressions does not make or break a language.

Python and JS do have return expressions in the context of lambdas.

I'm not very fond of this pattern in untyped languages (Ruby, Perl) because it can lead to accidental returns, but I'm pretty happy with having it in a typed language.

You can do some very nice things with that sort of syntax. Being able to assign values based on an if statement is one example that just makes life a little better. Just a tiny bit. :)

JavaScript supports implicit return in anonymous functions:

    let lowercased = names.map(name => name.toLowerCase());

The thing all those languages have in common is mutability by default. Being able to return values from if/else eliminates a lot of variables that would need to be mutable otherwise.

> There is a return statement; it just can't return anything

What? Return works exactly like it does in C, it's just not required as much.

> warning: unnecessary parentheses around `if` condition

I'm confused about how reducing the amount of required syntax is "gratuitous syntax."

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.

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.

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.

> There is a return statement; it just can't return anything

There are lots of languages out there that have implicit return, such as scala and ocaml and f#.

Your examples are glossed over too quickly. So far, I'm trying to see what you are saying, but I don't get it. In short, I'm open to being convinced, but you aren't making your points convincingly.

Want to make a detailed list of your so-called "gratuitous" syntax and invite discussion, point by point, in an open-minded way?

If there is a simpler syntactic way to capture the semantics and design goals of Rust, I think people would be open to hearing it.

I don't think you'll feel the same way after you invite discussion around it.

These are just minor syntax complaints though. You get used to it, and start to appreciate some of this stuff quickly IMO.

I spent far too much time trying to figure out how to use string and str. That's where it becomes absurd. I'm fine with fighting with the type/memory systems a bit, but when something that seems simple becomes a confusing mess it's just frustration.

The second edition of the book uses String and &str to explain ownership and borrowing, since this is a common pitfall: http://rust-lang.github.io/book/ch04-00-understanding-owners...

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

The reason this is very good is closures, which have the same return semantics as functions, are often a single expression, and are most useful to fit on one line. `.filter(|x| x.foo_bar() < some_other.foo_bar())`. Removing the return statement helps here.

Its a behavior shared with many (but not all) languages that make heavy use of anonymous functions.

Swift does support this also, but they limited it so they could also get rid of semicolons entirely.

You can say `return 42;` and it will return 42 as expected.

Rust doesn't require parens in an if expression because it requires brackets. You could silence the warning and use parens though.

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

Which tutorial are you referring to?

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/ is online and written by people involved in the rust language development.

... and http://rust-lang.github.io/book/ is even better!

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?

Yes, this is the second edition.

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

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

I don't have the patience to read a book about a programming language. What I need is crisp insights and honestly the book you linked is just way too time consuming. I just need the essence and I will learn as I dig deeper into the language.

IMO, Rust in 2017 is not going to be a first language for anyone. Just put a document that helps people who already know C/C++ very well. I could very well have misunderstood the goal of Rust because that might explain why such a doc doesn't exist.

I have to admit, I find it a little amusing that you're saying that as a C++ programmer you don't have the patience to read a (relatively short) book, given that learning C++ itself requires reading arguably many books, each of which are much larger than the Rust book.

FWIW, learning C++ was not fun.

> One should just assume that people already know C/C++/Java etc coming to learn rust.

It's not so simple. People coming from different languages know different things. Folks coming from JS may not understand the stack or how to operate in a non-GCd environment. Folks coming from C may not understand what a closure is. Folks may not come from a language with generics. Folks may not come from a language with a static type system.

All this piles up, and you effectively have to teach all of it if you want a document that anyone can use to learn Rust.

The "guessing game" tutorial is only an intro to the language. It can't explain many things without getting too large, and it's part of the book, so it expects you to continue. You don't need to read the whole book, just the first few chapters (and each chapter is pretty small, not the size of a "chapter" in typical physical programming book).

If you want a different way to learn Rust, try http://rustbyexample.com/index.html

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.

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.

As rust developer from a higher-level languages , I really struggled with that ,then I discovered format!() macro ,maybe they should make it more visible to new developers.

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

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.

Rust does, by the way.

One of Rust's selling points is literally that it has very easy zero-overhead C interop.

Like in Python, you're free to call your libc's exported symbols directly.

IMO it's a good thing rust doesn't support open()/read()/write()/close() directly and doesn't document it alongside the higher level abstractions.

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

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)

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.

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.

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.

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.

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.

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.

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.

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

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

Is that a bad thing? That's the ultimate in equality.

Are you kidding? Because that's not remotely equality at all. In fact, this comment itself seems rather sexist, since you're advocating that women are only equal to men if they're treated like men.

That's what equality is, treating people equally. Are you advocating that women be treated differently? That would be sexist.

Advocating for the idea that woman should be happy they're being treated like men is not equality. It's blatant inequality, and you're coming just short of explicitly saying that women are inferior to men.

So you think women should be treated differently to men? That is sexual discrimination.

I'm not sure you're grasping the equality concept. Treating people the same is equality. Treating different genders differently is sexism.

Someone here is clearly sexist, but it's not me.

Edit - instant down votes, the sjw debate philosophy.

Do you also greet your mother with "Hey dad", or do you refer to her by a different word because of her gender?

Of course I don't. But Mum's job was to stay at home, look after the kids and have dinner on the table at 6pm. That was a very gendered households, not uncommon at the time.

Are you saying that this gendered language should continue?

No. But using the wrong gendered language for someone is still bad. In fact, this is why in general lots of folks advocate for the usage of singular "they" when speaking of people with unknown gender. This is the problem with "hey guys" in the first place; there are gender neutral ways of addressing groups of people. Yet you are choosing the non gender neutral way of doing it.

You haven't been arguing against gendered language here, you're arguing for using gendered language -- just gendered language for the same gender -- for everyone, when gender-neutral language has existed for centuries.

-----

Equality is about treating men and women the same. Having women feel like a fish out of the water by having their identity rejected is not the same. Having women feel like their identity is being rejected is not the same.

Equality does not mean rejecting individuality. Equality is not assuming that everyone is Bob and has the same personality, emotions, and gender as Bob. That's unfair to people who aren't Bob. Equality is treating them the same, or more specifically not treating someone worse because of an aspect of their existence that they have little control over. You can and should still respect their identity.

If male and female identity would be identical, then neither would be male and female identity. It would be human identity, for which both women and men should equally be happy with.

If we treat women as men, we are also treating men as women. A major part of the equality feminism (the dominated faction within feminism until the start of the 21th century) had this as their primary concept. People gave kids either gender neutral colors, or switched them randomly and had both girls and boys wearing pink and blue clothes. However, this practice and theory of feminism was dethroned by difference feminism that believes that people are different, should be treated as different, but end up with equal results. This was then incorporated as part of the modern feminism practice, for which postmodern feminism (current minority faction) is rejecting which also happens to lean towards equality feminism style of practice.

Reply on news.ycombinator.com