Can you give an example of Rust incorporating "whatever cool thing every other language has added"?
I have never had the experience of Rust code becoming write-only after a month, and I don't know anyone else who has either.
I have never had the experience of Rust code becoming write-only after a month, and I don't know anyone else who has either.
Rust, though, suffers from being too clever, making it a language in which you can make concise, powerful solutions, but it can making grokking the code difficult, inefficient and error prone.
This is where our egos step forward and we announce that it's No Problem For Me, but we've all experienced a situation where we've leveraged a powerful language to do some amazing things, and then a month later it is a gruelling, headache inducing experience trying to figure out what is doing what, where, so we announce that we'll just rewrite the whole thing.
Can you explain specifically how Rust is supposedly too clever?
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..."
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."
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.
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"!
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?
This kind of answers doesn't belong here imo.
Trying to inject an invented narrative to quiet comments you don't like absolutely doesn't belong here.
Outside of the borrow checker and invocations relateeld thereto, Rust is fairly simple and transparent. The borrow checker forces you to think through things which are common sources of error before you can code things, which is mostly good, but a necessary cost of that is you also have to learn a whole vocabulary, symbology, and analytic approach around it.
While that does (at least until you've climbed the borrow checker learning curve, a place I haven't gotten past myself) make it harder to grok some code and, even moreso, makes it harder to write some code, I don't find that it promotes false understanding of code as much as very clear lack of understanding of what bits of unfamiliar code are doing.
OTOH, while there are simpler approaches to subsets of the same issues, I don't know that there's anything which really offers what Rust offers at lower cognitive cost.
I'm pretty new to Rust and can understand the critique... I think the biggest issue really comes down to a lot of code written, and an ever evolving canonical way of doing things. I think it'll get better with time, and does have some nice features for workflows that are difficult in Go.
Personally, I'm a huge fan of Node/JS as I just get stuff done. Most of my work doesn't need the ultimate in memory/performance as a lot of it is just gluing things together and it does very well as a scripting environment imho. Windows, Mac, Linux and very little friction. I like JS as a language and will leverage functional, some oop and procedural styles in different aspects of an application where they're a better fit for that aspect. Most languages aren't that flexible.