3 ms·
Not the GP, but for really large code bases, Go is missing a few features that I've noticed: 1) No immutable types. My work team is a huge user of immutable d
by kyrra 7mo ago
Not the GP, but for really large code bases, Go is missing a few features that I've noticed:
1) No immutable types. My work team is a huge user of immutable data stuctures in Java to make sure data passed around to other teams isn't changed. Go doesn't really have a good way to do this.
2) Refactoring can be really annoying (or at least really noisy) because of public/private being defined by capitalization of method/field names.
3) Error handling isn't great. I love Go's errors being just normal values, but the `error` interface is awkward when trying to figure out what kind of errors can be thrown without having in-depth knowledge of the kinds of errors that can be returned. We regularly need to make different decisions depending on the kind of error returned. Knowing which errors can be returned in Go is not defined by the method being called (only in comments).
- oefrha 7mo ago> No immutable types (in Go) The typical answer is opaque types with only readonly methods exported. Not elegant, but it’s there. I guess it’s arguably not a “good way” to do it.
- joeblubaugh 7mo agoIn fact it was “the Java way” for many years and “useless getters” was always a big complaint about Java.
- wbl 7mo agoI think you want sum types which admittedly Go doesn't have in a matchable way. However complex error recovery is an anti pattern for Go.
- gf000 7mo ago> However complex error recovery is an anti pattern for Go. Bit of snark from my side, but that's exactly what makes it less good of a fit for "industry purposes". Go's error handling is possibly the worst out of any "modern" language, it basically copied C's errno which is not something you should have ever done.
- wbl 7mo agoWhy exactly do you have complex error analysis happening above a component that has the error? That's anti modular.
- gf000 7mo agoBecause almost my definition you can't handle errors in the component, otherwise you would have a conditional and not an error. E.g. if I do some IO like "make a copy of these files" and get an error/exception, it's only the caller or maybe even that caller's caller that can properly deal with this condition (e.g. to decide that we will skip the erroneous files or retry).
- peterashford 7mo agoThis was exactly my experience when I first read about Go. I was so excited until I found they were repeating the c experience of check every bloody return value separately. That was the worst feature of c - why copy it
- dinkumthinkum 7mo agoThis is not a dig at Go and this will be controversial but I so struggle to see what problem or area Go is solving outside of CSP. It's a nice language it just feels far too simple and I am really convinced of it as a systems language over Modern C++ and if you want that alternative then we have our rather oxidized friend that seems to more substantial. That's just my take.
- peterashford 7mo agoI code Go at work. I've been using it for just over 3 years. I really like it. I prefer Java, but Go is a much more ergonomic C and its a very pragmatic language. Except for the *%!@ error system, that can burn in hell.