They might not be strictly language issues, but if they are symptomatic of idiomatic rust then they are “sins of rust”. Something about the language promotes writing it using these kinds of idioms.
Just like French speakers don’t pronounce 80% of the written syllables because it’s impractical to speak fast with all of them…language features (or lack of them) drive how the language is used.
(BTW the implicit return behaviour on a missing semicolon sounds like Chekhov’s footgun)
Something about the language promotes writing it using these kinds of idioms.
As someone who has used Rust professionally for 3 years, the idioms are good. I wouldn’t want the idioms to go away, and I don’t particularly want the style/aesthetics of the language to change unless it can be done without negatively affecting the idioms.
It’s not a situation where the aesthetics are actually bad, it’s just different than what most programmers are used to, but almost all of the differences are for pretty good reasons. With enough familiarity and practice you’ll start to recognize those differences as benefits of the language rather than detriments.
But I think a lot of people have so much inertia about tweaking their way of thinking that they don’t feel motivated to try long enough to make it over that hump, especially when their expectations get set by rabid Rust promoters like myself who insist that Rust is vastly superior to any other languages in almost all situations. The stark contrast between how good they’re told the language is and how they feel when first exposed to it might be too much whiplash for some people.
I recognise that different languages have different styles, strengths and idioms. One of my pain points is when people write every language as if it’s naughties java. Enough with the enterprise OoP crap.
I’ve also learnt languages like Haskell to expand and challenge the way I think about software problems. I learnt a lot doing it. That doesn’t stop a lot of Haskell code looking like line noise to me because it over-uses symbols and it being close to impenetrable in a lot of cases when you read somebody else’s code.
I think the aesthetics of Rust are the wrong side of the line. Not as bad as something like Haskell (or Perl), but still objectionable. Some things seem to be different even though there’s pre-existing notation. Things seem to be dense, magical, and for the compilers benefit over the readers (as an outsider).
I’ve been learning Zig recently and the only notational aspect I struggled with was the pointer/slice notation as there’s 5 or 6 similar forms that mean fairly different things. It has other new concepts and idioms to learn, but on the whole it’s notation is fairly traditional. That has made reading code a lot more approachable (…which is a good thing because the documentation for some aspects sucks).
The implicit return is perhaps the most dubious of them. I don’t mind it for simple functions, but they are not so good in anything large and with multiple return sites. Even more so when developers choose to implicitly return 4 chained method calls inside a closure with else cases.
But the rest aren’t really sins, they are mostly new or different concepts or ways to do something. And if there is a sin, it’s largely because the language itself has a complexity larger than others.
Taking my own examples here, lambdas are just fine, but the move semantics are cumbersome to deal with. But we need to do it some way, to indicate that a value is actually being moved into the closure. Maybe there are better ways and they make into the language in the future.
Conditional values and let statements and such is a good consequence of Rusts design choice with returning Results or Option types. Just because it’s different doesn’t make it a sin. Just takes time to learn the right way. I think most come from an exception based language, and that has a differnet code flow than what Rust has.
Lifetimes are hard though, and I feel a lot of the introduction is made excessively hard with the simple naming. It’s as of every programming tutorial used single letter variable names. Lifetimes isn’t something I’m that good with either, mostly because I haven’t had to use that complexity yet.
I think that’s a great set of criticisms.
They might not be strictly language issues, but if they are symptomatic of idiomatic rust then they are “sins of rust”. Something about the language promotes writing it using these kinds of idioms.
Just like French speakers don’t pronounce 80% of the written syllables because it’s impractical to speak fast with all of them…language features (or lack of them) drive how the language is used.
(BTW the implicit return behaviour on a missing semicolon sounds like Chekhov’s footgun)
As someone who has used Rust professionally for 3 years, the idioms are good. I wouldn’t want the idioms to go away, and I don’t particularly want the style/aesthetics of the language to change unless it can be done without negatively affecting the idioms.
It’s not a situation where the aesthetics are actually bad, it’s just different than what most programmers are used to, but almost all of the differences are for pretty good reasons. With enough familiarity and practice you’ll start to recognize those differences as benefits of the language rather than detriments.
But I think a lot of people have so much inertia about tweaking their way of thinking that they don’t feel motivated to try long enough to make it over that hump, especially when their expectations get set by rabid Rust promoters like myself who insist that Rust is vastly superior to any other languages in almost all situations. The stark contrast between how good they’re told the language is and how they feel when first exposed to it might be too much whiplash for some people.
I recognise that different languages have different styles, strengths and idioms. One of my pain points is when people write every language as if it’s naughties java. Enough with the enterprise OoP crap.
I’ve also learnt languages like Haskell to expand and challenge the way I think about software problems. I learnt a lot doing it. That doesn’t stop a lot of Haskell code looking like line noise to me because it over-uses symbols and it being close to impenetrable in a lot of cases when you read somebody else’s code.
I think the aesthetics of Rust are the wrong side of the line. Not as bad as something like Haskell (or Perl), but still objectionable. Some things seem to be different even though there’s pre-existing notation. Things seem to be dense, magical, and for the compilers benefit over the readers (as an outsider).
I’ve been learning Zig recently and the only notational aspect I struggled with was the pointer/slice notation as there’s 5 or 6 similar forms that mean fairly different things. It has other new concepts and idioms to learn, but on the whole it’s notation is fairly traditional. That has made reading code a lot more approachable (…which is a good thing because the documentation for some aspects sucks).
The implicit return is perhaps the most dubious of them. I don’t mind it for simple functions, but they are not so good in anything large and with multiple return sites. Even more so when developers choose to implicitly return 4 chained method calls inside a closure with else cases.
But the rest aren’t really sins, they are mostly new or different concepts or ways to do something. And if there is a sin, it’s largely because the language itself has a complexity larger than others.
Taking my own examples here, lambdas are just fine, but the move semantics are cumbersome to deal with. But we need to do it some way, to indicate that a value is actually being moved into the closure. Maybe there are better ways and they make into the language in the future.
Conditional values and let statements and such is a good consequence of Rusts design choice with returning Results or Option types. Just because it’s different doesn’t make it a sin. Just takes time to learn the right way. I think most come from an exception based language, and that has a differnet code flow than what Rust has.
Lifetimes are hard though, and I feel a lot of the introduction is made excessively hard with the simple naming. It’s as of every programming tutorial used single letter variable names. Lifetimes isn’t something I’m that good with either, mostly because I haven’t had to use that complexity yet.