3 ms·

There would probably be a much longer list of issues if ESR had converted to Rust instead, but the syntax for error returns is quite interesting. Rust and Go bo

There would probably be a much longer list of issues if ESR had converted to Rust instead, but the syntax for error returns is quite interesting. Rust and Go both opt not to have exceptions, instead they use error return values. The original Python code using exceptions was: sink = transform3(transform2(transform1(source))) Making that use error return values looks quite verbose in Go, but Rust has syntax specifically for that case, making it quite manageable: sink = transform3(transform2(transform1(source)?)?)?

devmop 7y ago
It's ugly either way but for clarity you can move the error checks into the transformation leaving the call point clean. i.e transform1 returns (result, error) and transform2 accepts (result, error) and short-circuits if err is not nil. It allows the expressive and succinct description of a transformation list but with a bunch of messiness hidden.
- kofejnik 7y ago
  something something Maybe monad
- andrewzah 7y ago
  This isn't ideal, because it forces each successive function that takes a Result type to add handling code in the case of an error. fn(fn(fn()?)?)? is a bit gnarly but better than duplicate code like that, imo.
gameswithgo 7y ago
> if ESR had converted to Rust instead, Rust would have solved three of his complaints with Go: Sum types, iterators, and generics. Borrow checking can get especially tricky with graph algorithms though, so perhaps that would have been a new issue.
- xvilka 7y ago
  For graph algorithms there is a good Petgraph[1][2] crate, so many common operations can be done in no time. [1] https://crates.io/crates/petgraph https://crates.io/crates/petgraph [2] https://github.com/petgraph/petgraph https://github.com/petgraph/petgraph
steveklabnik 7y ago
ESR tried Rust a while back, and decided to go with Go in general.
- deleted 7y ago
  [deleted]
ASalazarMX 7y ago
the final ")?)?)?" is kinda unsettling, but I can't explain why.
pk2200 7y ago
He evaluated Rust and Go a few years ago and strongly preferred Go. https://blog.ntpsec.org/2017/01/18/rust-vs-go.html https://blog.ntpsec.org/2017/01/18/rust-vs-go.html

devmop 7y ago

It's ugly either way but for clarity you can move the error checks into the transformation leaving the call point clean. i.e transform1 returns (result, error) and transform2 accepts (result, error) and short-circuits if err is not nil. It allows the expressive and succinct description of a transformation list but with a bunch of messiness hidden.

kofejnik 7y ago
something something Maybe monad
andrewzah 7y ago
This isn't ideal, because it forces each successive function that takes a Result type to add handling code in the case of an error. fn(fn(fn()?)?)? is a bit gnarly but better than duplicate code like that, imo.

gameswithgo 7y ago

> if ESR had converted to Rust instead, Rust would have solved three of his complaints with Go: Sum types, iterators, and generics. Borrow checking can get especially tricky with graph algorithms though, so perhaps that would have been a new issue.

xvilka 7y ago
For graph algorithms there is a good Petgraph[1][2] crate, so many common operations can be done in no time. [1] https://crates.io/crates/petgraph https://crates.io/crates/petgraph [2] https://github.com/petgraph/petgraph https://github.com/petgraph/petgraph

steveklabnik 7y ago

ESR tried Rust a while back, and decided to go with Go in general.

deleted 7y ago
[deleted]

ASalazarMX 7y ago

the final ")?)?)?" is kinda unsettling, but I can't explain why.

pk2200 7y ago

He evaluated Rust and Go a few years ago and strongly preferred Go. https://blog.ntpsec.org/2017/01/18/rust-vs-go.html https://blog.ntpsec.org/2017/01/18/rust-vs-go.html