3 ms·

I have enough scars from complex Golang-applications; I'm just wrapping up a port of a 5kloc Golang-codebase to C++ and one of the things that struck me is how

I have enough scars from complex Golang-applications; I'm just wrapping up a port of a 5kloc Golang-codebase to C++ and one of the things that struck me is how much declaring intentions and having them checked by the compiler helps. It's not that easy to prove decreased readability, it's more a gut-feeling of additional effort being required to keep track of everything. It's an issue I've found in any language that favors structural sub-typing, it's just that Golang is pretty exceptional at bragging about about it. What saves Golang in my opinion is the possibility of declaring types in hierarchies, which solves some of the problems; but you still have the issue where random types are part of a hierarchy without any hints in the code except for which methods are implemented.

skybrian 9y ago
Okay, that's better. I agree that in Go, sometimes it's a bit harder to understand the type hierarchy for interface types. Often it doesn't matter; finding all subtypes of io.Writer wouldn't be useful, for example. Also, if you want a closed type hierarchy (such as for an abstract syntax tree), it's possible using a private marker method. The particular thing I'd disagree applies to Go is "error messages produced by structural checking are poorly localized and very hard to understand." I can see how sometimes that might be true for some languages, but I've found Go's error messages for interfaces not matching to be reasonable. Also, there are benefits: the ability to declare a local supertype for a subtype from another package that's not easily modifiable can be very useful, and not having this ability in other language can be rather painful due to the need for adapters. So this seems like an area where there are tradeoffs in language design, not one where there's an obvious winner and the other side is LOLCODE.
- andreasgonewild 9y ago
  Don't get me started on down-your-throat, manual error-handling; imports tied to repositories and opaque, mandatory N*M-threading; the outright hostility to features like flexible locking. Or the overly draconian package reference rules which turns any non-trivial software into a packaging-puzzle. There is plenty more LOLCODE-worthy contraptions in there... Look, they even admit themselves that the primary goal was for the language to be easy enough for beginners to not hurt themselves; which is fine if that's what you're looking for; for me it's mostly a no go, since I need more power than that to not drown in the complexity of the problems I'm solving.

skybrian 9y ago

Okay, that's better. I agree that in Go, sometimes it's a bit harder to understand the type hierarchy for interface types. Often it doesn't matter; finding all subtypes of io.Writer wouldn't be useful, for example. Also, if you want a closed type hierarchy (such as for an abstract syntax tree), it's possible using a private marker method. The particular thing I'd disagree applies to Go is "error messages produced by structural checking are poorly localized and very hard to understand." I can see how sometimes that might be true for some languages, but I've found Go's error messages for interfaces not matching to be reasonable. Also, there are benefits: the ability to declare a local supertype for a subtype from another package that's not easily modifiable can be very useful, and not having this ability in other language can be rather painful due to the need for adapters. So this seems like an area where there are tradeoffs in language design, not one where there's an obvious winner and the other side is LOLCODE.

andreasgonewild 9y ago
Don't get me started on down-your-throat, manual error-handling; imports tied to repositories and opaque, mandatory N*M-threading; the outright hostility to features like flexible locking. Or the overly draconian package reference rules which turns any non-trivial software into a packaging-puzzle. There is plenty more LOLCODE-worthy contraptions in there... Look, they even admit themselves that the primary goal was for the language to be easy enough for beginners to not hurt themselves; which is fine if that's what you're looking for; for me it's mostly a no go, since I need more power than that to not drown in the complexity of the problems I'm solving.