5 ms·
"Go feels under-engineered because it only solves real problems" This belies a multitude of real problems Go doesn't solve, like generics or preventing data ra
by bascule 12y ago
"Go feels under-engineered because it only solves real problems"
This belies a multitude of real problems Go doesn't solve, like generics or preventing data races
- zackbloom 12y agoAs he said in the article, neither seem to be problems which come up in practice. I maintain about twelve Go services running in production, and neither failure has cost me any significant amount of time.
- the_af 12y agoWhat kills me is that generics (or any other programming language abstraction) are not problems, but problem-solving tools. Technically speaking, they are never needed, if your definition of "not needed" is "I can work without them". You don't need anything beyond assembly language, really. The thing with most tools and abstractions is that you don't appreciate them until you use them -- when you truly use them, not merely when you learn about them. Then you wonder how you ever lived without them. You don't know if failing to use an abstraction hasn't cost you a significant amount of time until you've embraced their use. To me, this is a variant of the Blub paradox at work.
- bascule 12y agoI constantly see users of Go running into these problems. If you haven't, good for you I suppose.
- enneff 12y agoGenerics are not a problem to be solved, they're a tool to solve problems.
- bascule 12y agoThe lack of generics is definitely a problem. You can't write generic code, and end up having to write your own thunks for each type you want to use. The standard library can't expose generic facilities that work on any type. This should be evidenced by the fact that Go is the only mainstream statically typed language without parametric polymorphism. Worse, trying to bolt it on after the fact has generally lead to ugly solutions, like C++ templates or Java's generics. I expect Go will eventually follow Java's lead and bolt on generics awkwardly.
- enneff 12y ago> The lack of generics is definitely a problem. Not to me. Not to the author of this article. > I expect Go will eventually follow Java's lead and bolt on generics awkwardly. Nope. They'll either be done right or not at all. We're not ignoring Java's mistakes.
- bascule 12y agoI guess you're a fan of rewriting type thunks over and over and over again, and don't care about the standard library implementing functionality or reusably. Whatever floats your boat, but in both C++ and Java people got tired of writing type-thunking boilerplate over and over again and eventually got features added to the language to fix the problem. At this point I'm not sure how Go can do generics well, so if "right or not at all" is really the bar, then Go will probably never get them.
- deleted 12y ago[deleted]
- jhawk28 12y agoHow does go not prevent data races? It has a race detector, channels, and atomics.
- bascule 12y agoYou can still send mutable state across channels, at which point it is shared and potentially racy. Race detectors only help you catch data races in the act (e.g. in production), they don't prevent them from happening in the first place. Wikipedia has a nice description: https://en.wikipedia.org/wiki/Go_(programming_language)#Race_condition_safety https://en.wikipedia.org/wiki/Go_(programming_language)#Race...