I can actually see where this is coming from, as I found Rust hard to read when I started out. I do really like Rust for reference, but I do agree Rust is hard to read for someone that has not learned it.

For example:

return statements that are implicit just because the semicolon isn't there. Even better if they occur inside a if block or something like that. Very hard to understanding when you don't know the syntax rules.

Lambda functions, especially when using move semantics too. They are quite simple, but if you don't know the meaning, it's more arcane characters. Especially when this is used inside lots of chained methods, and maybe a multi-line function in the lambda.

A lot for the if let x =... type of stataments are tough the first time around. Same for match statements.

Defining types for use with function::() and such.

Lifetimes, especially when they are all named a, b, c etc. It quickly gets messy, especially when combined with generics or explicitly defined types.

Macros, though not entry level rust to begin with, they are really cumbersome to decode.

None of these are sins of Rust, but for new people they are a hill to climb, and often hard to just "get" based on previous programming experience and reading the code. Rust can be really hard to approach because of these things. This happens in other languages too, but I do feel Rust has a particularly large amount of new concepts or ways to do something. And this is on top of learning lifetimes and borrow semantics.

[–] 5C5C5C@programming.dev 10 points 17 hours ago

This is the most sober take in this thread. I was bothered by all these things you mentioned for the first two weeks of using the language. I begrudgingly accepted them for the following two months because I felt the benefits of the language were worth it. Now all of these things feel natural and I don't give them a second thought.

[–] wewbull@feddit.uk 2 points 15 hours ago (2 children)

I think that's a great set of criticisms.

None of these are sins of Rust, ...

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)

[–] 5C5C5C@programming.dev 6 points 15 hours ago (1 children)

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.

[–] wewbull@feddit.uk 1 points 5 hours ago

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

[–] BehindTheBarrier@programming.dev 3 points 15 hours ago

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.