4 ms·
Go inevitably results in a very large codebase for a given piece of functionality, especially if it’s used alongside Google’s companion projects such as protobu
by woah 6y ago
Go inevitably results in a very large codebase for a given piece of functionality, especially if it’s used alongside Google’s companion projects such as protobufs and grpc. Lack of generics means that it is impossible to generalize over related types, leading to duplicated code, and in some cases, crazy hacks like serializing a struct, passing it through the generic part of the code and then deserializing it again when you need to use it.
Other choices such as structs being initialized with “zero values” in their fields (instead of having a compile error when you forget a field), and the complicated sometimes equivalence of zero values and null create a lot of footguns when refactoring.
Go’s strength is a batteries included stdlib and its looseness can make prototyping faster. But it feels very much like an old school scripting language like php or js, where you have to use countless trivial unit tests to have any confidence about what your code is doing.
- meritt 6y ago> where you have to use countless trivial unit tests to have any confidence about what your code is doing. I don’t understand this. I can read well written code and tell you what it does, including in old school scripting languages. I don’t need countless trivial unit tests.