3 ms·

Enums and iota weirdness made my love for Go start to crack. I learned about abstract data types and discriminated unions, then wondered why Go didn't have tho

Enums and iota weirdness made my love for Go start to crack. I learned about abstract data types and discriminated unions, then wondered why Go didn't have those. The prevalence and overuse of interface{} undermined type safety at jobs I had writing Go and errors from this apparently popular style of Go programming filled the logs. Then I saw someone say "Go's error handling on values is good, but it's better in a language with Either". I looked up examples, and indeed it seemed nicer and retained the value proposition of errors as values. I wish Go had either. Then bugs started happening in code that was copy pasted... but why was it copy pasted? Lack of generics were the final straw and I started playing with Haskell in the evenings. It gave me the type safety I wanted and more. It's not perfect, but it's based on a philosophy I believe is more correct than the worse is better values of Go that seek micro-level simplicity at the cost of macro-level complexity.

Groxx 5y ago
>micro-level simplicity at the cost of macro-level complexity That pretty succinctly covers a lot of my not-fond-about-Go reasons too. There's a lot to like about Go for small projects - I've replaced a lot of my CLI-writing languages/tools with Go code and it's a dramatic improvement and I'm quite happy with it for that. But it falls apart badly when you're trying to do highly-stable, highly-correct, or highly-complex things. Not being able to know what errors can be returned is a HUGE source of missing error handling. Fatal errors containing only "not found" after passing through dozens of calls wastes a ridiculous amount of troubleshooting time. Not-so-minor mismatches between reality and Go's SDK are covered up in awkward, error-prone ways with no real alternatives (because the core library can and does do things you cannot). https://fasterthanli.me/articles/i-want-off-mr-golangs-wild-ride https://fasterthanli.me/articles/i-want-off-mr-golangs-wild-... for a much more detailed decline into madness because of all this. If you are sufficiently careful, almost none of this is a problem, true. Experts are consistently able to write safe C code, right? ........right? --- Honestly I expect generics to be a pretty significant improvement. E.g. intrusive concurrency control is unbelievably error-prone in bulk, and generics will let us finally have safe and easy higher level constructs for most code. I also know of a few projects I've touched that will likely be able to remove 10-20% of the codebase just because we won't have to go to great lengths to maintain (or check after abandoning) type safety. It's a simple and reasonable implementation of generics, especially since there's no inheritance to worry about. I'm looking forward to it... but I probably still won't like Go.

Groxx 5y ago

>micro-level simplicity at the cost of macro-level complexity That pretty succinctly covers a lot of my not-fond-about-Go reasons too. There's a lot to like about Go for small projects - I've replaced a lot of my CLI-writing languages/tools with Go code and it's a dramatic improvement and I'm quite happy with it for that. But it falls apart badly when you're trying to do highly-stable, highly-correct, or highly-complex things. Not being able to know what errors can be returned is a HUGE source of missing error handling. Fatal errors containing only "not found" after passing through dozens of calls wastes a ridiculous amount of troubleshooting time. Not-so-minor mismatches between reality and Go's SDK are covered up in awkward, error-prone ways with no real alternatives (because the core library can and does do things you cannot). https://fasterthanli.me/articles/i-want-off-mr-golangs-wild-ride https://fasterthanli.me/articles/i-want-off-mr-golangs-wild-... for a much more detailed decline into madness because of all this. If you are sufficiently careful, almost none of this is a problem, true. Experts are consistently able to write safe C code, right? ........right? --- Honestly I expect generics to be a pretty significant improvement. E.g. intrusive concurrency control is unbelievably error-prone in bulk, and generics will let us finally have safe and easy higher level constructs for most code. I also know of a few projects I've touched that will likely be able to remove 10-20% of the codebase just because we won't have to go to great lengths to maintain (or check after abandoning) type safety. It's a simple and reasonable implementation of generics, especially since there's no inheritance to worry about. I'm looking forward to it... but I probably still won't like Go.