6 ms·

Go seems to have been developped by true masters that really understand that less is more. "The key point here is our programmers are Googlers, they're not res

Go seems to have been developped by true masters that really understand that less is more. "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 Ignoring complexity on the language level simply passes the buck to application code, and developers end up paying that price across the ecosystem in perpetuity. They've also kept a laser sharp focus on working on things that really matters and took the time to do things right. Go's async model is underspecified, its implementation of generics incurs runtime overhead, much of the "wonderful tooling" only exists because of severe shortcomings in the language design and/or compiler implementation, its FFI is... difficult, etc. To be blunt, the values that Go embraces are none of the values I seek in a programming language or community. And I feel sorry for anyone too heavily invested in Go to turn back.

bsaul 3y ago
golang concurrent programming is by far the best i've ever used for its application domain which is mainly infrastructure middlewares running in a connected environment. The tradeof between language features and maintainability is also IMHO the best in class. Never before have i ever looked at a stdlib sourcecode and told myself "hu, yeah i see how that works".
jstimpfle 3y ago
I'll offer a different take: Thinking that complexity can be offloaded into the language is not seeing the whole picture. Offloading complexity into the language works for the simple cases, but the more one is trying to fit a solution into a physical box with physical constraints, and the more flexibility is required from the business logic, the situation will change in such a way that more control about the specific of the solution becomes a requirement, and the language shortcuts will fit less and less, to the point where they become a liability. Doubly so if it is difficult or impossible to unwrap the layers of language features. Of course, many problems can be solved with just a few Python scripts, or even with a huge pile of them. On the other hand, we can find a possible explanation why it could make sense for some teams to code huge apps in low-level languages (C or C++) or languages with few language features (e.g. Golang), or even to try and control the whole stack by maintaining their own language infrastructure.
- SubjectToChange 3y ago
  the situation will change in such a way that more control about the specific of the solution becomes a requirement, and the language shortcuts will fit less and less, to the point where they become a liability. This is exactly what Go does. Languages like C++ or Rust make it possible to expose and interact with those complex requirements, whereas Go takes it away in the name of “simplification”. Just look at all of the insane hacking tailscale does on Go to make it work for them.
  - jstimpfle 3y ago
    Any example? I honestly don't know tailscale nor have I programmed seriously in Go. I can understand that sometimes you want tools to quickly cut through obstacles, however I've also noticed that applying such tools without extreme care, like on a regular basis, seems to always lead into local maxima and at some point these choices have to be reconsidered. One explanation for this phenomenon that I've found is that language features are typically accessed using special syntax, because otherwise they could be library features. Well, it's hard or typically even impossible to abstract over syntactic uses of such features. For example, it's hard to automate the definition of a class based on more abstract concepts, when such creation has to be done as explicit syntax instead of using a builder-style API that iteratively adds members and methods.

bsaul 3y ago

golang concurrent programming is by far the best i've ever used for its application domain which is mainly infrastructure middlewares running in a connected environment. The tradeof between language features and maintainability is also IMHO the best in class. Never before have i ever looked at a stdlib sourcecode and told myself "hu, yeah i see how that works".

jstimpfle 3y ago

I'll offer a different take: Thinking that complexity can be offloaded into the language is not seeing the whole picture. Offloading complexity into the language works for the simple cases, but the more one is trying to fit a solution into a physical box with physical constraints, and the more flexibility is required from the business logic, the situation will change in such a way that more control about the specific of the solution becomes a requirement, and the language shortcuts will fit less and less, to the point where they become a liability. Doubly so if it is difficult or impossible to unwrap the layers of language features. Of course, many problems can be solved with just a few Python scripts, or even with a huge pile of them. On the other hand, we can find a possible explanation why it could make sense for some teams to code huge apps in low-level languages (C or C++) or languages with few language features (e.g. Golang), or even to try and control the whole stack by maintaining their own language infrastructure.

SubjectToChange 3y ago
the situation will change in such a way that more control about the specific of the solution becomes a requirement, and the language shortcuts will fit less and less, to the point where they become a liability. This is exactly what Go does. Languages like C++ or Rust make it possible to expose and interact with those complex requirements, whereas Go takes it away in the name of “simplification”. Just look at all of the insane hacking tailscale does on Go to make it work for them.
- jstimpfle 3y ago
  Any example? I honestly don't know tailscale nor have I programmed seriously in Go. I can understand that sometimes you want tools to quickly cut through obstacles, however I've also noticed that applying such tools without extreme care, like on a regular basis, seems to always lead into local maxima and at some point these choices have to be reconsidered. One explanation for this phenomenon that I've found is that language features are typically accessed using special syntax, because otherwise they could be library features. Well, it's hard or typically even impossible to abstract over syntactic uses of such features. For example, it's hard to automate the definition of a class based on more abstract concepts, when such creation has to be done as explicit syntax instead of using a builder-style API that iteratively adds members and methods.