3 ms·
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
by 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 agoAny 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.