3 ms·

I was following the article and nodding my head all the way up to the Rust section, at which point I lost track because I'm not too familiar with Rust :) It's

I was following the article and nodding my head all the way up to the Rust section, at which point I lost track because I'm not too familiar with Rust :) It's also not clear to me how `if let , while let , let-else` help (and how you'd use them), or what an "ergonomic sum type" is and how it helps with exceptions. Would be really cool if there was a code snippet in Rust comparing/explaining the advantage over Java for each benefit.

LAC-Tech 2y ago
"if let" is rusts answer to Java's "isPresent" method. if let Some(val) = my_optional_value { // perform some side effect with val }
- brabel 2y ago
  In the context of this blog post, an example with Result would be more suitable though. if let Ok(value) = fun_can_fail() { // success, use value } else { // error, but we don't care which one when using if-let }
  - Expurple 2y ago
    This isn't the only pattern that `if let` is suitable for. It's often used without an `else`, as a syntax sugar for match value { the_only_case_that_we_care_about => { // Do something with the bound value. }, _ => {}, // Don't do anything, we don't care about the other cases at all. }
moomin 2y ago
The basic idea is that an exception is just data, so you can just treat it as part of the return type. Most of the rest of it is constructs that make it easy to work with, which mostly means making things behave similarly to the way exceptions work. But with the option to just treat it as regular data rather than complex catch try rethrow logic. Checked exceptions were inferior to this because they was outside of the type system; saying “This type or three possible exceptions” was so painful people stopped using. With this approach it’s just a type and has whatever name you like.
- Expurple 2y ago
  > “This type or three possible exceptions” was so painful people stopped using. A reader on Reddit has also pointed out [1] that it's literally impossible to represent "n possible exceptions" generically. Java makes you manually write out exactly 3 exceptions in the signature, or exactly 1 exception in the signature, or exactly 0 exceptions in the signature... [1] https://www.reddit.com/r/rust/comments/1h3kdye/rust_solves_the_issues_with_exceptions/lzsnn7g/ https://www.reddit.com/r/rust/comments/1h3kdye/rust_solves_t...
Expurple 2y ago
> Would be really cool if there was a code snippet in Rust comparing/explaining the advantage over Java for each benefit. Yeah, I thought about that. But the post kept and kept expanding in scope so I decided to instead hyperlink where I could. > It's also not clear to me how `if let , while let , let-else` help (and how you'd use them) All three of those are hyperlinks in the post. > what an "ergonomic sum type" is Here, I mean language support for defining and using sum types[1] without verbose code that doesn't reflect the programmer's intent well. A typical sum type implementation in Java uses a sealed interface. You can't implement interfaces on "foreign" types that you don't control, like `boolean`. You often have to define extra wrapper classes that distract you when navigating the codebase and also hurt performance: public sealed interface MutuallyExclusiveFlags permits FlagA, FlagB {} public record FlagA(boolean value) implements MutuallyExclusiveFlags {} public record FlagB(boolean value) implements MutuallyExclusiveFlags {} Meanwhile, in Rust: pub enum MutuallyExclusiveFlags { FlagA(bool), FlagB(bool), } No boilerplate, no extra types, no unnecessary performance cost. This whole object takes only 2 bytes of memory on the stack! [2] I didn't go into detail on this, because the post isn't about introducing sum types. > and how it helps with exceptions The part about "exceptional flow" describes some cases where Result-based error handling is preferable to using exceptions. Language support for sum types is necessary to properly express Result values and the sets of possible error values inside. [1] https://en.wikipedia.org/wiki/Tagged_union https://en.wikipedia.org/wiki/Tagged_union [2] https://play.rust-lang.org/?version=stable&mode=debug&edition=2021&gist=316ac4f5922988cffffeceb5c60fe59a https://play.rust-lang.org/?version=stable&mode=debug&editio...

LAC-Tech 2y ago

"if let" is rusts answer to Java's "isPresent" method. if let Some(val) = my_optional_value { // perform some side effect with val }

brabel 2y ago
In the context of this blog post, an example with Result would be more suitable though. if let Ok(value) = fun_can_fail() { // success, use value } else { // error, but we don't care which one when using if-let }
- Expurple 2y ago
  This isn't the only pattern that `if let` is suitable for. It's often used without an `else`, as a syntax sugar for match value { the_only_case_that_we_care_about => { // Do something with the bound value. }, _ => {}, // Don't do anything, we don't care about the other cases at all. }

moomin 2y ago

The basic idea is that an exception is just data, so you can just treat it as part of the return type. Most of the rest of it is constructs that make it easy to work with, which mostly means making things behave similarly to the way exceptions work. But with the option to just treat it as regular data rather than complex catch try rethrow logic. Checked exceptions were inferior to this because they was outside of the type system; saying “This type or three possible exceptions” was so painful people stopped using. With this approach it’s just a type and has whatever name you like.

Expurple 2y ago
> “This type or three possible exceptions” was so painful people stopped using. A reader on Reddit has also pointed out [1] that it's literally impossible to represent "n possible exceptions" generically. Java makes you manually write out exactly 3 exceptions in the signature, or exactly 1 exception in the signature, or exactly 0 exceptions in the signature... [1] https://www.reddit.com/r/rust/comments/1h3kdye/rust_solves_the_issues_with_exceptions/lzsnn7g/ https://www.reddit.com/r/rust/comments/1h3kdye/rust_solves_t...

Expurple 2y ago

> Would be really cool if there was a code snippet in Rust comparing/explaining the advantage over Java for each benefit. Yeah, I thought about that. But the post kept and kept expanding in scope so I decided to instead hyperlink where I could. > It's also not clear to me how `if let , while let , let-else` help (and how you'd use them) All three of those are hyperlinks in the post. > what an "ergonomic sum type" is Here, I mean language support for defining and using sum types[1] without verbose code that doesn't reflect the programmer's intent well. A typical sum type implementation in Java uses a sealed interface. You can't implement interfaces on "foreign" types that you don't control, like `boolean`. You often have to define extra wrapper classes that distract you when navigating the codebase and also hurt performance: public sealed interface MutuallyExclusiveFlags permits FlagA, FlagB {} public record FlagA(boolean value) implements MutuallyExclusiveFlags {} public record FlagB(boolean value) implements MutuallyExclusiveFlags {} Meanwhile, in Rust: pub enum MutuallyExclusiveFlags { FlagA(bool), FlagB(bool), } No boilerplate, no extra types, no unnecessary performance cost. This whole object takes only 2 bytes of memory on the stack! [2] I didn't go into detail on this, because the post isn't about introducing sum types. > and how it helps with exceptions The part about "exceptional flow" describes some cases where Result-based error handling is preferable to using exceptions. Language support for sum types is necessary to properly express Result values and the sets of possible error values inside. [1] https://en.wikipedia.org/wiki/Tagged_union https://en.wikipedia.org/wiki/Tagged_union [2] https://play.rust-lang.org/?version=stable&mode=debug&edition=2021&gist=316ac4f5922988cffffeceb5c60fe59a https://play.rust-lang.org/?version=stable&mode=debug&editio...