Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

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


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


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

[2] https://github.com/petgraph/petgraph


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.


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.


something something Maybe monad


He evaluated Rust and Go a few years ago and strongly preferred Go.

https://blog.ntpsec.org/2017/01/18/rust-vs-go.html


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


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




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: