Hacker News Reader

Comment by endorphone | Hacker News Reader

With all due respect, I don't think you're in a position to have a unbiased perspective on this, and I am certain I'm never going to convince you.

But I'll leave it that there have been countless "Rust is too difficult" links for you to find on Google, many of which have been posted on here. And invariably when we discuss Rust the conversation goes like this-

"why is it so complex to do [some simple thing]?"

"Oh well Rust is a System Programming Language, and it's doing important things in important ways"

"Okay, but I'm not building an OS, I'm just..."

[chest puffing, ego's appear, etc]

"Well I certainly have no problem with it..."

View on HN

I’ve found Rust users to be very helpful, especially on Hacker News.

For example, in this thread from two weeks ago someone asks why it’s so frustrating to concatenate strings of mixed types in Rust:

https://news.ycombinator.com/item?id=20124821

And Steve Klabnik offers a friendly and ego-free reply with a simple and helpful option to do just that.

I’m sure there are other examples of flame wars, but I wouldn’t associate Rust advocates with chest puffing and egos at all.

I still can't figure out exactly what design decisions you disagree with, but it sounds like you're objecting to the lack of GC or memory safety. There are some applications for which GC is not appropriate. Maybe you don't work on any of those applications. That's fine, but that's very different from saying Rust is overly complicated.

I think this is a great point that indirectly highlights how people are often talking past each other when a go vs rust debate comes up. People work in different problem domains with different constraints and therefore the a good language choice in one domain might be wrong for the other.

I don't think anyone in the go community would suggest you write a browser in go. Ignoring the GC performance issues, just the awkwardness of using cgo would make most go developers shudder.

Likewise there are many problem domains where a GC'ed language works just fine. In these cases it is appropriate to consider other factors when deciding which language to use. Perhaps your team is made up of a bunch of experienced scala developers, scala might be a good choice for you over go or rust. That doesn't mean your good choice is universally applicable to all teams.

Some teams might care more about getting the most value per cpu cycle possible. Other teams might care more about the time it takes to get a new engineer up to speed in the language. Both of these can be valid reasons to choose a specific language.

I guess what I'm trying to say is: "Try to choose the language (and other tools) that best matches your organizations constraints. Don't assume that other teams have the same constraints."

"too difficult" is not the same as "too clever" or piling on too many features and encouraging errors.

Do you agree with the sibling comment of "Outside of the borrow checker and invocations related thereto, Rust is fairly simple and transparent."? And the assertion that while it's difficult it doesn't make you misunderstand code?

It is kind of sad to see a simple question answered with a personal attack.

This kind of answers doesn't belong here imo.

There is no personal attack in the comment you replied to.

Trying to inject an invented narrative to quiet comments you don't like absolutely doesn't belong here.

> "why is it so complex to do [some simple thing]?"

To be fair to endorphone, this does happen quite often - mostly, because people often fail to immediately grok the sorts of idioms that will easily pass Rust's borrow checker. As a general rule, it's something that is solved by properly dealing with shared mutability and shared ownership. But failing to deal with these is a pretty bad code smell anyway, so IMHO there's nothing wrong with a language which prompts you to do that! Hopefully, we're not going to equate avoiding blatant code smells with "chest-puffing" and "ego"!

Reply on news.ycombinator.com