3 ms·
I can answer this one! It manages to have significantly less elegant syntax and behavior than both C and Common Lisp, while also having drastically lower perfor
by metagame 5y ago
I can answer this one! It manages to have significantly less elegant syntax and behavior than both C and Common Lisp, while also having drastically lower performance than both. Alongside that, it's incredibly difficult to port to new systems for little reason other than that the creator decided to make it so. Its package management is also significantly worse than Common Lisp's.
All of this without even getting into Rob Pike (the man largely responsible for its origin, if you're not familiar) saying explicitly it was for people who weren't capable of understanding a better language:
«The key point here is our programmers are Googlers, they’re not researchers. They’re typically, fairly young, fresh out of school, probably learned Java, maybe learned C or C++, probably learned Python. They’re not capable of understanding a brilliant language but we want to use them to build good software. So, the language that we give them has to be easy for them to understand and easy to adopt.»
Rob Pike, 2014.
Go is a fine language, but let's not pretend, here. Rob Pike certainly doesn't.
- to11mtm 5y agoThere's some truth to this. As a C# developer, I get to deal with a lot more: - Bikeshedding over LINQ - Going back and optimizing LINQ - Helping Developers understand someone else's LINQ, Reflection/Attribute Abuse - Helping developers understand new syntax in each version of the language. A large part of Go's philosophy is to more or less take away all of those tools from the Developer and try to force a style of code that is somewhat monotonous, verbose (in a way very different from Java), yet 'readable' by a developer with minimal experience.
- kaba0 5y agoAssembly is just as readable/simple, in that every single line is easy to comprehend. Yet good luck getting the big picture of an assembly program. The same is more or less true of Go. Abstractions can be bad, but in the majority of cases it is the only tool we have against complexity, and a method with an annotation may be thousands time more readable/understandable than the reimplementation of a given identical functionality for the thousands time.