5 ms·

> that's once per 30 or so lines. 2 or 3 percent of the code ... I really prefer the Java "force you to catch exception" model much more to this. And that 2%-3

> that's once per 30 or so lines. 2 or 3 percent of the code ... I really prefer the Java "force you to catch exception" model much more to this. And that 2%-3% doesn't include where errors should have been checked but were not. For instance run programs without stdout ("./program 1>&-") and most Go console programs will just happily write to nowhere whereas almost all Java ones error out immediately. Closing stdout doesn't often matter, but sometimes things like this are important. I don't understand how in the 2010s it's okay to make a language with worse reliability. And worse "JavaDoc" equivalent. Go should be better than C and Java in every category and it's just not better in way too many.

sangnoir 12y ago
Language design is about trade-offs. Broadly speaking: being good in one category means being bad in another.
- 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.
- frowaway001 12y ago
  This is nonsense.
NateDad 12y ago
My go code is way more reliable than my exception-language code, because I know exactly where it can fail and what happens when it does. It is much harder to see where exceptions can happen and what the code paths will be when errors happen. Why is not having stdout automatically an error condition? Lots of programs should work fine with no stdout. If a program requires stdout and doesn't fall when it's missing, that's a bug (and pretty easy to fix).
- bsdetector 12y ago
  > Why is not having stdout automatically an error condition? In UNIX the file handle an opened file gets is the next available, lowest number. Closing stdout means that the program opens a file and it gets file handle 1 instead of a higher number. Then it writes something to stdout, which is an alias for file handle 1, but instead it writes to the opened file. I believe this caused some security bugs in passwd or maybe su where you could run it without stderr and "Password:" would be written to the passwd file instead of stderr. ...but these specifics are beside the point, which is that it is next to impossible to anticipate the problems an unhandled error can create. Java's checked exceptions can be annoying when you have to add some extra "throws X" or handle every case, but my experience is that I never had the slightest doubt over how a method could fail or what needed to be done to handle errors. For unchecked exceptions maybe you have a point, although their failure mode for unhandled errors is still to abort the program rather than to continue on with undefined behavior as in Go.

sangnoir 12y ago

Language design is about trade-offs. Broadly speaking: being good in one category means being bad in another.

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.
frowaway001 12y ago
This is nonsense.

NateDad 12y ago

My go code is way more reliable than my exception-language code, because I know exactly where it can fail and what happens when it does. It is much harder to see where exceptions can happen and what the code paths will be when errors happen. Why is not having stdout automatically an error condition? Lots of programs should work fine with no stdout. If a program requires stdout and doesn't fall when it's missing, that's a bug (and pretty easy to fix).

bsdetector 12y ago
> Why is not having stdout automatically an error condition? In UNIX the file handle an opened file gets is the next available, lowest number. Closing stdout means that the program opens a file and it gets file handle 1 instead of a higher number. Then it writes something to stdout, which is an alias for file handle 1, but instead it writes to the opened file. I believe this caused some security bugs in passwd or maybe su where you could run it without stderr and "Password:" would be written to the passwd file instead of stderr. ...but these specifics are beside the point, which is that it is next to impossible to anticipate the problems an unhandled error can create. Java's checked exceptions can be annoying when you have to add some extra "throws X" or handle every case, but my experience is that I never had the slightest doubt over how a method could fail or what needed to be done to handle errors. For unchecked exceptions maybe you have a point, although their failure mode for unhandled errors is still to abort the program rather than to continue on with undefined behavior as in Go.