Enums and nested blocks. I understand the importance of Option and Result, but it's fucking infuriating when I have to check and destructure the result of every function call and either bubble the result up the stack from six levels of nested if let blocks or risk Cloudflaring my program by using .unwrap(). And while I like being able to extract a return value from an if...else expression, the structure gets really convoluted when multiple if and match blocks are nested (of course each one returning a value), and it gets completely fucked once closures are introduced.

I like Rust, but calling it pretty is delusional.

[–] tatterdemalion@programming.dev 4 points 1 day ago

Enums are the best part of the Rust language IMO, so I'm not sure how you can view them as ugly. Having the choice to destructure something is fantastic. You generally aren't required to destructure every return value. Make sure you're using the ? operator as much as possible. If destructuring is getting in your way, it sounds like the code is not very idiomatic.

I can't really comment on your issue with nested if and match. Too much nesting is bad in any language; try extracting more functions and let bindings to make it more readable.

You can enable a clippy lint to deny .unwrap() if you're worried about it.

[–] SorryQuick@lemmy.ca 6 points 1 day ago* (last edited 1 day ago)

You can also use let else.

let (Some(count\_str), Some(item)) = (it.next(), it.next()) else {
    panic!("Can't segment count item pair: '{s}'");
};

But really it’s the exact same as other languages, it just forces you to handle it better. C-based languages will return 0/null/-1 and you’ll have to check all 3 of those because they might not mean the same thing. How is that better?

[–] calcopiritus@lemmy.world 3 points 1 day ago

Most of the times you can just let ... else (which is basically a custom ? if you need if let ... else it's because you actually need 2 branching code paths. In any other language you also do if ... else when you have 2 different code branches. I don't see why this is a rust-specific issue.

[–] roanutil_@programming.dev 17 points 2 days ago

Sum types with associated values are worth it

[–] magic_lobster_party@fedia.io 7 points 1 day ago

I like to use unwrap_or() to define fallback values. The Option API is quite expressive.

[–] marcos@lemmy.world 16 points 2 days ago (1 children)

have to check and destructure the result of every function call

Learn how to use enum error types, how error bubbling works, and how to convert between Options and Results.

It's Rust you are talking about, not Go.

[–] rtxn@lemmy.world -4 points 2 days ago (1 children)

This isn't about some feature of the language being good or bad. It's about Rust being ugly or not. The things I mentioned will always look ugly in the source code.

[–] 5C5C5C@programming.dev 10 points 1 day ago

It's hilarious to me that people talk about "ugly" as if their opinions are objective.

I found Rust unpleasant to look at for the first two weeks of learning it, and now that I've been using it professionally for three years I loathe when I need to read code in other languages.

No other language can rival Rust in showing the exact information needed to understand the code

never too much and never too little

while being concise, correct, and handling all edge cases.

You can be more concise in other languages, but it will come the loss of handling every little possible bug. You can be prettier in other languages, but it will come at the price of adding a lot of useless boilerplate.

Of course there are cases where Rust can be verbose or confusing, but that's when you're doing very esoteric things that would be just as confusing in other languages.

Like any opinion on aesthetics, how someone feels about the prettiness of a language will have far more to do with familiarity than with any objective metrics.

[–] eager_eagle@lemmy.world 7 points 1 day ago

Cloudflaring my program

I'll start using this one