4 ms·

While your comment is sort of true, it's not applicable here really. We know how to handle errors better than this. Go's error handling is C style. We've since

by TheDong 12y ago

While your comment is sort of true, it's not applicable here really. We know how to handle errors better than this. Go's error handling is C style. We've since found exceptions, Maybes, and friends which are very powerful. What you said implies that when Rust chooses to use Maybes they're somehow being bad at something. That's simply false; computer science as a field has advanced and one of these advancements (not even that recent of one) is improved understandings of how strong type systems can be used to make code, including errors, safer. Go completely ignores this of course and they're not doing it for a tradeoff that I can see. They gain nothing in terms of performance for not having this type (everything is already a reflect/Value anyways, so much for not having the baggage that you'd need for generics) and everything in terms of having a worse language. Being good at something doesn't instantly mean you're bad at something else. In fact, I wouldn't even claim that's the general case. If you disagree, you're welcome to point out the tradeoffs at work here. I think your comment is just a vaguery that is completely untrue in this instance.

enneff 12y ago
The corresponding loss to Rust's gain is language complexity.
- deleted 12y ago
  [deleted]
- kibwen 12y ago
  I think this argument is depressingly uncharitable. One of Rust's goals was to remove the "feature" of null pointers. In its place rose the feature of tagged unions, to support the `Option` type. This is strictly trading one feature for another. Once this necessary task was completed, Rust was happily able to reap all the benefits of tagged unions elsewhere, such as with the `Result` type. It is not greater language complexity, it is merely the reuse of simple language features to empower developers to create more robust software. Now, I am not among those saying that Go needs tagged unions, or any other feature for that matter (no, not even that one). I think Go is a good language, sometimes to the surprise of my peers. But what's disheartening to me is seeing a Go core developer imply that Go is literally the baseline for programming language simplicity, in effect papering over all the various tradeoffs that programming language design entails.
  - enneff 12y ago
    You mischaracterised my point. Go is hardly the baseline for language simplicity. We just made a different set of trade offs to the Rust team, and I believe Go is the simpler (not simplest) language.
marktangotango 12y ago
>> We've since found exceptions, Maybes, and friends which are very powerful. I think, and someone correct me if this is wrong, that implementing exceptions in Go is prohibited by go routines. The stereotypical way to implement exceptions is using setjmp/longjmp which unwind the stack back to a known location. Since go routines are implemented as continuations, any particular executing go routine may or may not have it's stack in context, and I'm not sure what it means to unwind stacks across multiple continuations, ie is it even possible? So that's one possible example.
- pcwalton 12y ago
  > I think, and someone correct me if this is wrong, that implementing exceptions in Go is prohibited by go routines. No. Go already has all the runtime functionality necessary to support exceptions via panic/recover.
NateDad 12y ago
The tradeoff is complexity. You need to define a maybe for your return value, which needs generics. Whereas Go gets 80% of the functionality with multiple returns which are like 10% odd the complexity (and are useful in other ways).
- pcwalton 12y ago
  You don't have to have generics to use enums for error handling any more than you need generics to use tuples for error handling. The thing you need is enums/algebraic data types/sum types. See for example the first answer to this SO question on error handling in Swift, which doesn't use generics at all: http://stackoverflow.com/questions/24010569/error-handling-in-swift-language http://stackoverflow.com/questions/24010569/error-handling-i...

by TheDong 12y ago

enneff 12y ago

The corresponding loss to Rust's gain is language complexity.

deleted 12y ago
[deleted]
kibwen 12y ago
I think this argument is depressingly uncharitable. One of Rust's goals was to remove the "feature" of null pointers. In its place rose the feature of tagged unions, to support the `Option` type. This is strictly trading one feature for another. Once this necessary task was completed, Rust was happily able to reap all the benefits of tagged unions elsewhere, such as with the `Result` type. It is not greater language complexity, it is merely the reuse of simple language features to empower developers to create more robust software. Now, I am not among those saying that Go needs tagged unions, or any other feature for that matter (no, not even that one). I think Go is a good language, sometimes to the surprise of my peers. But what's disheartening to me is seeing a Go core developer imply that Go is literally the baseline for programming language simplicity, in effect papering over all the various tradeoffs that programming language design entails.
- enneff 12y ago
  You mischaracterised my point. Go is hardly the baseline for language simplicity. We just made a different set of trade offs to the Rust team, and I believe Go is the simpler (not simplest) language.

marktangotango 12y ago

>> We've since found exceptions, Maybes, and friends which are very powerful. I think, and someone correct me if this is wrong, that implementing exceptions in Go is prohibited by go routines. The stereotypical way to implement exceptions is using setjmp/longjmp which unwind the stack back to a known location. Since go routines are implemented as continuations, any particular executing go routine may or may not have it's stack in context, and I'm not sure what it means to unwind stacks across multiple continuations, ie is it even possible? So that's one possible example.

pcwalton 12y ago
> I think, and someone correct me if this is wrong, that implementing exceptions in Go is prohibited by go routines. No. Go already has all the runtime functionality necessary to support exceptions via panic/recover.

NateDad 12y ago

The tradeoff is complexity. You need to define a maybe for your return value, which needs generics. Whereas Go gets 80% of the functionality with multiple returns which are like 10% odd the complexity (and are useful in other ways).

pcwalton 12y ago
You don't have to have generics to use enums for error handling any more than you need generics to use tuples for error handling. The thing you need is enums/algebraic data types/sum types. See for example the first answer to this SO question on error handling in Swift, which doesn't use generics at all: http://stackoverflow.com/questions/24010569/error-handling-in-swift-language http://stackoverflow.com/questions/24010569/error-handling-i...