| ▲ | packetlost 10 months ago |
| Rust and Go's lack of stack traces are basically equivalent in that you need to call an additional function to add the stack context to the error result. For go you use fmt.Errorf, in Rust you use .context from anyhow (bad practice in many contexts IMO) or .inspect_err + log. It's rather unfortunate that neither has an easy way of capturing a line number + file easily and appending it to the context. Go could easily do it, I think. Oh well. I agree that Go should really have an analogue to Rust's `?`, but you can't really do that in a sane way without sum types to represent your conditions. The very multiple-return style error propagation makes it impractical to do. IMO Go should add really basic tagged unions and rework the stdlib to use them, but such a change would probably necessitate a v2. |
|
| ▲ | miki123211 10 months ago | parent | next [-] |
| > I agree that Go should really have an analogue to Rust's `?`, but you can't really do that in a sane way without sum types to represent your conditions. The very multiple-return style error propagation makes it impractical to do. There was a proposal for a `try`, which I still think should have been adopted. Under that proposal, `someComplicatedExpression(try(functionReturningError()))` would be converted to `foo, err := functionReturningError(); if err != nil{return zeroValue, zeroValue, err}; someComplicatedExpression(foo)` |
| |
| ▲ | packetlost 10 months ago | parent [-] | | You would need some form of compile-time reflection/specialization to implement that properly (what if the second return value isn't an error? What if there's only 1 return value?). Further, you would lose the ability to add context to the error branch via fmt.Errorf, which seems rather critical to understandable error conditions. I'm not sure I would be satisfied with any implementation of try as the language is now, I assume the Go language team would probably feel the same. |
|
|
| ▲ | dfawcus 10 months ago | parent | prev | next [-] |
| > I agree that Go should really have an analogue to Rust's `?`, but you can't really do that in a sane way without sum types to represent your conditions. The very multiple-return style error propagation makes it impractical to do. There is always the Odin style 'or_return' operator, which is defined for a similar situation. https://odin-lang.org/docs/overview/#or_return-operator |
| |
|
| ▲ | the_gipsy 10 months ago | parent | prev | next [-] |
| > Go should really have an analogue to Rust's `?`, but you can't really do that in a sane way without sum types It could be just some simple (hey, that's what go wants to be, right?) macro thing, that just does the everyday `if err!=nil{return ..., err}` for you without having to juggle (and think about) vars. b := g(f()?)?
// var b B
// {
// var a A
// var err error
// a, err = f()
// if err != nil {
// return *new(A), *new(B), err
// }
// var b B
// b, err = g(a)
// if err != nil {
// return *new(A), *new(B), err
// }
// // no accidental reuse of err
// }
I mean look how much utterly useless noise this is, and count all the opportunities for mistakes that wouldn't get caught by the compiler. |
| |
| ▲ | baranul 10 months ago | parent [-] | | For a more corporate driven and controlled language, once it goes down a certain direction, it appears really hard for it to stop the train or get enough momentum to change directions. Easy examples are generics, enums, sum types, etc... Therefore other languages (influenced by Golang), like V (vlang.io), Odin (odin-lang.org), Jai, C3... made such improvements. One could argue that it's more a matter of if people are going to be brave or open-minded enough to try something different or go in a different direction. |
|
|
| ▲ | pdimitar 10 months ago | parent | prev [-] |
| RE: Golang v2, they clearly said they will not do it and will double down on backwards compatibility with exceptions powered by env vars and/or CLI switches. |
| |
| ▲ | 9rx 10 months ago | parent | next [-] | | Technically, Go v2 signified the transition away from Google control to the project being directed by the community. That happened several years ago. Go v2 is already here and has been for a long time. The stdlib is also at v2 now (e.g. math/rand/v2). You must mean the language? They said that a language v2 (go2) is probably unnecessary – that any future additions could be added without breaking the existing language. I don't expect simple tagged unions would need to break anything. A v2 (or even v3, perhaps) stdlib would be necessary to take advantage, like the parent suggests, but that has never been ruled out and is already the status quo. | | |
| ▲ | packetlost 10 months ago | parent [-] | | This was what I was referring to. The stdlib is what would need to see backwards-compatibility-breaking changes, not the language itself. | | |
| ▲ | pdimitar 10 months ago | parent [-] | | I am not sure how would that work? F.ex. how would you introduce tagged unions and make the language 100% backwards-compatible... but not the stdlib? I admit I have no idea. | | |
| ▲ | 9rx 10 months ago | parent [-] | | The stdlib would remain 100% backwards compatible, but the implication was that he would want to see certain existing features of the stdlib amended with modified versions that leverage the new tagged unions. He imagined that modification would necessitate v2 stdlib packages to maintain sensibility. | | |
| ▲ | pdimitar 10 months ago | parent [-] | | Oh. Silly me, I am ashamed for failing reading comprehension so badly. Thanks for clarifying, that makes sense. |
|
|
|
| |
| ▲ | packetlost 10 months ago | parent | prev [-] | | I'm fully aware of that. |
|