I don’t see how this is inspired by Rust in any way, except perhaps by reusing ?, however, ? works completely different in Rust.
An earlier Go porposal tried to introduce try, which more closely matched how Rust works (although not exactly). This is a departure from that proposal which brings this proposal is even further away from Rust than before.
In any case I am very disappointed by this magic operator which only works for statements (I can’t believe it doesn’t support chaining, bleah), introduces new syntax for handling errors (whereas unwrap_or_else in Rust is just a method that takes a closure, and of course there is also map_err and many other useful methods) and just ignores types altogether, digging itself further into a compatibility hole where they won’t ever be able to add sum types to the language.
My disappointment is immeasurable and my day is ruined.
Actually, that’s a good question. Did I accidentally write “RUST”? 🤣 I’m blaming it on a lack of coffee, since I posted that before getting through my first cup. If you read through the proposal, you’ll see that it’s inspired by Rust (or RUST 🤣), but still significantly different.
I’m actually just amazed that Go is considering such a significant change, and possibly including code rewriting tools to make it more easily adopted. Having written a lot of C, the cut and paste error reporting (or infinitely nested blocks) aren’t actually that off-putting to me (not that I like them), but this proposal seems likely to be a significant improvement for a lot of Go code. I’m not currently working in Go, but I like to read the discussions when language designers consider making big changes … I always learn a lot!
The comments on the thread that I linked to are pretty interesting as well, including some alternative suggestions that pare back the change without losing much functionality.
There’s already a good discussion of this.
Cool, thanks! I missed that one.
I don’t see how this is inspired by Rust in any way, except perhaps by reusing
?, however,?works completely different in Rust.An earlier Go porposal tried to introduce
try, which more closely matched how Rust works (although not exactly). This is a departure from that proposal which brings this proposal is even further away from Rust than before.In any case I am very disappointed by this magic operator which only works for statements (I can’t believe it doesn’t support chaining, bleah), introduces new syntax for handling errors (whereas
unwrap_or_elsein Rust is just a method that takes a closure, and of course there is alsomap_errand many other useful methods) and just ignores types altogether, digging itself further into a compatibility hole where they won’t ever be able to add sum types to the language.My disappointment is immeasurable and my day is ruined.
What is RUST? Linked issue appears to refer to the programming language “Rust”.
Use the “suggest” button instead of being sarcastic.
Actually, that’s a good question. Did I accidentally write “RUST”? 🤣 I’m blaming it on a lack of coffee, since I posted that before getting through my first cup. If you read through the proposal, you’ll see that it’s inspired by Rust (or RUST 🤣), but still significantly different.
I’m actually just amazed that Go is considering such a significant change, and possibly including code rewriting tools to make it more easily adopted. Having written a lot of C, the cut and paste error reporting (or infinitely nested blocks) aren’t actually that off-putting to me (not that I like them), but this proposal seems likely to be a significant improvement for a lot of Go code. I’m not currently working in Go, but I like to read the discussions when language designers consider making big changes … I always learn a lot!
The comments on the thread that I linked to are pretty interesting as well, including some alternative suggestions that pare back the change without losing much functionality.
https://encrypted-tbn0.gstatic.com/images?q=tbn:ANd9GcSkxwMSHoJK0LllX0jKXnPDEO6QS62Dt3lG-ZZT3ibgWg0RNKZ_mTQObZNg&s=10