5 ms·

Just goes to show how out of touch with established programming language research and practice the golang authors are. Now they're re-inventing exceptions, but

by apta 7y ago

Just goes to show how out of touch with established programming language research and practice the golang authors are. Now they're re-inventing exceptions, but badly. It seems a lot of things in golang were done just for the sake of being different, with nothing to back it up.

hu3 7y ago
Not only is your belittling of Go authors gratuitously offensive but it is uninformed as well. That is just one of the many proposals that Go received along the years and there's no intent to implement it at the moment.
- AnimalMuppet 7y ago
  I'd say it's uninformed for a completely different reason. Look at the bios of the Go authors. "Out of touch with established programming language research"? Seriously? "Making different choices than you would have" != "out of touch with research" - especially when they know the research better than you do!
  - apta 7y ago
    > Look at the bios of the Go authors. Appeal to authority fallacy. Furthermore, this was evident several times when discussions about things like generics came up. I think they even admitted it at some point.
    - AnimalMuppet 7y ago
      > Just goes to show how out of touch with established programming language research and practice the golang authors are. When you said that, was also the appeal to authority fallacy.
      - apta 7y ago
        Which authority? I observed other languages like Kotlin, Scala, Rust, D, C#, Java, C++ and saw what they have in terms of program design and features.
        AnimalMuppet 7y ago
        "Established programming language research". That's a set of authorities, even if you didn't name them. Kotlin, Scala, Rust, D, C#, Java, and C++ are not language research. They're existing practice.
        apta 7y ago
        It's more like an appeal to a consensus if you will, since those languages converged on a set of good established practices (that came out of research obviously) that have actually shown to make a positive difference (e.g. Rust, Scala, Kotlin, and soon Java and C#, have sum types, and pattern matching), and the way they deal with errors (Result type in Rust - where the compiler actually forces you to deal with errors unlike golang, and exceptions in the rest, which again, don't let errors slip through accidentally unlike golang). The golang authors threw away all that (and are still dismissive of things like sum types) because of, well nothing really to back it up. The same reason they have null pointers whereas all new languages moved away from them, and some like C# are being retrofitted to address them. I think the rationale they gave to having null pointers is that "they're part of the underlying machine" or some ridiculous reason like that, which further proves my point that they're out of touch with established programming research and practices.
        AnimalMuppet 7y ago
        > The golang authors threw away all that (and are still dismissive of things like sum types) because of, well nothing really to back it up. Because of multiple decades at Bell Labs, which was the computer science research facility at the time. And because of multiple decades of experience using many languages to write a huge amount of real-world software. And because of specific problems that they found with using C++ in their specific environment. Look, you don't think go was the right way to go. That's fine. You even base it on having used go and not liking it. It's good that you're basing your opposition on experience, not just theory. But don't claim that the go authors are ignorant of programming language theory just because of the direction they chose. They are not ignorant at all, and they chose the direction they did with full knowledge of what others were doing. It may turn out to be a mistake, but it wasn't from ignorance.
dang 7y ago
"Please don't post shallow dismissals, especially of other people's work. A good critical comment teaches us something." https://news.ycombinator.com/newsguidelines.html https://news.ycombinator.com/newsguidelines.html
marcus_holmes 7y ago
"try" as proposed here has nothing to do with exceptions as other languages implement them. whether that's a good thing itself is another conversation
Cthulhu_ 7y ago
> It seems a lot of things in golang were done just for the sake of being different, with nothing to back it up. Take an afternoon to go through the Go FAQ [0] (they answer why they don't have exceptions), design documents [1], including this fairly recent one [2] about error handling - they explicitly discuss exceptions and the pros / cons - and that's just what ended up in the design documents / FAQ, there's been at least ten years worth of discussion gone into that beforehand. Do some googling before making accusations like that please. [0]: https://golang.org/doc/faq#exceptions https://golang.org/doc/faq#exceptions [1]: https://github.com/golang/go/wiki/DesignDocuments https://github.com/golang/go/wiki/DesignDocuments, https://github.com/golang/proposal https://github.com/golang/proposal [2]: https://go.googlesource.com/proposal/+/master/design/go2draft-error-handling-overview.md https://go.googlesource.com/proposal/+/master/design/go2draf...
- apta 7y ago
  I'm aware of their rationales, what I'm saying is that they don't make sense and are dismissive, and have no studies at all to back them up. It's there in the first link you posted for example, "we believe exceptions lead to convoluted code". Belief here is not sufficient, it must be conclusively shown that it's otherwise, especially given that subjectively speaking it is possible in golang for errors to slip and not be handled at all (I saw it in real code bases), much much worse than any "convoluted" code that exceptions may result in (again it's very subjective - the way golang handles errors results in much longer code that's harder to follow).

by apta 7y ago

hu3 7y ago

Not only is your belittling of Go authors gratuitously offensive but it is uninformed as well. That is just one of the many proposals that Go received along the years and there's no intent to implement it at the moment.

AnimalMuppet 7y ago
I'd say it's uninformed for a completely different reason. Look at the bios of the Go authors. "Out of touch with established programming language research"? Seriously? "Making different choices than you would have" != "out of touch with research" - especially when they know the research better than you do!
- apta 7y ago
  > Look at the bios of the Go authors. Appeal to authority fallacy. Furthermore, this was evident several times when discussions about things like generics came up. I think they even admitted it at some point.
  - AnimalMuppet 7y ago
    > Just goes to show how out of touch with established programming language research and practice the golang authors are. When you said that, was also the appeal to authority fallacy.
    - apta 7y ago
      Which authority? I observed other languages like Kotlin, Scala, Rust, D, C#, Java, C++ and saw what they have in terms of program design and features.
      - AnimalMuppet 7y ago
        "Established programming language research". That's a set of authorities, even if you didn't name them. Kotlin, Scala, Rust, D, C#, Java, and C++ are not language research. They're existing practice.
        apta 7y ago
        It's more like an appeal to a consensus if you will, since those languages converged on a set of good established practices (that came out of research obviously) that have actually shown to make a positive difference (e.g. Rust, Scala, Kotlin, and soon Java and C#, have sum types, and pattern matching), and the way they deal with errors (Result type in Rust - where the compiler actually forces you to deal with errors unlike golang, and exceptions in the rest, which again, don't let errors slip through accidentally unlike golang). The golang authors threw away all that (and are still dismissive of things like sum types) because of, well nothing really to back it up. The same reason they have null pointers whereas all new languages moved away from them, and some like C# are being retrofitted to address them. I think the rationale they gave to having null pointers is that "they're part of the underlying machine" or some ridiculous reason like that, which further proves my point that they're out of touch with established programming research and practices.
        AnimalMuppet 7y ago
        > The golang authors threw away all that (and are still dismissive of things like sum types) because of, well nothing really to back it up. Because of multiple decades at Bell Labs, which was the computer science research facility at the time. And because of multiple decades of experience using many languages to write a huge amount of real-world software. And because of specific problems that they found with using C++ in their specific environment. Look, you don't think go was the right way to go. That's fine. You even base it on having used go and not liking it. It's good that you're basing your opposition on experience, not just theory. But don't claim that the go authors are ignorant of programming language theory just because of the direction they chose. They are not ignorant at all, and they chose the direction they did with full knowledge of what others were doing. It may turn out to be a mistake, but it wasn't from ignorance.

dang 7y ago

"Please don't post shallow dismissals, especially of other people's work. A good critical comment teaches us something." https://news.ycombinator.com/newsguidelines.html https://news.ycombinator.com/newsguidelines.html

marcus_holmes 7y ago

"try" as proposed here has nothing to do with exceptions as other languages implement them. whether that's a good thing itself is another conversation

Cthulhu_ 7y ago

> It seems a lot of things in golang were done just for the sake of being different, with nothing to back it up. Take an afternoon to go through the Go FAQ [0] (they answer why they don't have exceptions), design documents [1], including this fairly recent one [2] about error handling - they explicitly discuss exceptions and the pros / cons - and that's just what ended up in the design documents / FAQ, there's been at least ten years worth of discussion gone into that beforehand. Do some googling before making accusations like that please. [0]: https://golang.org/doc/faq#exceptions https://golang.org/doc/faq#exceptions [1]: https://github.com/golang/go/wiki/DesignDocuments https://github.com/golang/go/wiki/DesignDocuments, https://github.com/golang/proposal https://github.com/golang/proposal [2]: https://go.googlesource.com/proposal/+/master/design/go2draft-error-handling-overview.md https://go.googlesource.com/proposal/+/master/design/go2draf...

apta 7y ago
I'm aware of their rationales, what I'm saying is that they don't make sense and are dismissive, and have no studies at all to back them up. It's there in the first link you posted for example, "we believe exceptions lead to convoluted code". Belief here is not sufficient, it must be conclusively shown that it's otherwise, especially given that subjectively speaking it is possible in golang for errors to slip and not be handled at all (I saw it in real code bases), much much worse than any "convoluted" code that exceptions may result in (again it's very subjective - the way golang handles errors results in much longer code that's harder to follow).