4 ms·

golang is older than that at this time. They deliberately ignored proven concepts in programming language design for some hand-wavy goal of "simplicity", making

by apta 7y ago

golang is older than that at this time. They deliberately ignored proven concepts in programming language design for some hand-wavy goal of "simplicity", making unsubstantiated claims about "programming in the large" and "scalabilty" along the way.

nine_k 7y ago
To quote some other HN comments: "systems PHP", "If I need a well designed language, I have Rust. Go's sell for me is it's so naively simplistic it's actually useful when your team members are idiots". These are a bit harsh, but sort of hints on the target audience: people who have neither a lot of programming experience, nor a developed taste, but have practical problems to solve without shooting themselves in the foot.
- Insanity 7y ago
  That seems unnecessarily harsh towards Go programmers in my opinion. Languages have different up and downsides and different areas where they shine. There's plenty of people with a lot of programming experience writing Go, and whose taste might just have diverged a bit from the "mainstream". :)
  - nine_k 7y ago
    Yes; I stated so. This is a cultural clash; there is an ample demand for a language with explicitly and harshly limited expressiveness, to prevent the C++ problems from ever happening. Go also is a safe enough language so I'd take it over C any moment where possible.
  - TurboHaskal 7y ago
    It being harsh does not make it any less true. Go is self admittedly catering to the lowest common denominator of developers. And boy it works... I have to write a lot of Go myself. I detest it, and use it only because the industry dictates so.
Thaxll 7y ago
"proven" yeah C++ template and Java half baked generics are really proven ...
- nine_k 7y ago
  Java's generics solve vastly more problems than they cause. Yes, I'd rather Sun go with an ML lookalike in 1997, but such was the intellectual fashion, and also computers were bitterly slow at the time, so a compiler had to be simple.
F-0X 7y ago
>They deliberately ignored proven concepts in programming language design Not really. Generics, as a standalone feature, is not useful for much more than just container types. Go has generic container types, so woot, no need for plain generics. Languages like Haskell which utilise generics for more useful things do so with other features. In Haskell's case, it's typeclasses, in other languages, it might be operator overloading. If you have a type T, you can't do shit with it unless you know something more about it. A type T that has a notion of + though can be checked at compile time and functions can "add" generically. Well Go has interfaces. You can stick an Add() method on all the structs you might want to pass "generically" to a function, and add them. So indeed, Go certainly is much simpler for having skipped "proper" generics, since they get to skip all the complicated stuff that makes them actually useful.
- morelisp 7y ago
  > Go has generic container types, so woot, no need for plain generics. There are dozens of common types that give the lie to this (the standard Go claim), like sync.Map, sync.Value, lru, or pool. Type classes are a feature that arises from having generics, not one that you need to take advantage of generics.

by apta 7y ago

nine_k 7y ago

To quote some other HN comments: "systems PHP", "If I need a well designed language, I have Rust. Go's sell for me is it's so naively simplistic it's actually useful when your team members are idiots". These are a bit harsh, but sort of hints on the target audience: people who have neither a lot of programming experience, nor a developed taste, but have practical problems to solve without shooting themselves in the foot.

Insanity 7y ago
That seems unnecessarily harsh towards Go programmers in my opinion. Languages have different up and downsides and different areas where they shine. There's plenty of people with a lot of programming experience writing Go, and whose taste might just have diverged a bit from the "mainstream". :)
- nine_k 7y ago
  Yes; I stated so. This is a cultural clash; there is an ample demand for a language with explicitly and harshly limited expressiveness, to prevent the C++ problems from ever happening. Go also is a safe enough language so I'd take it over C any moment where possible.
- TurboHaskal 7y ago
  It being harsh does not make it any less true. Go is self admittedly catering to the lowest common denominator of developers. And boy it works... I have to write a lot of Go myself. I detest it, and use it only because the industry dictates so.

Thaxll 7y ago

"proven" yeah C++ template and Java half baked generics are really proven ...

nine_k 7y ago
Java's generics solve vastly more problems than they cause. Yes, I'd rather Sun go with an ML lookalike in 1997, but such was the intellectual fashion, and also computers were bitterly slow at the time, so a compiler had to be simple.

F-0X 7y ago

>They deliberately ignored proven concepts in programming language design Not really. Generics, as a standalone feature, is not useful for much more than just container types. Go has generic container types, so woot, no need for plain generics. Languages like Haskell which utilise generics for more useful things do so with other features. In Haskell's case, it's typeclasses, in other languages, it might be operator overloading. If you have a type T, you can't do shit with it unless you know something more about it. A type T that has a notion of + though can be checked at compile time and functions can "add" generically. Well Go has interfaces. You can stick an Add() method on all the structs you might want to pass "generically" to a function, and add them. So indeed, Go certainly is much simpler for having skipped "proper" generics, since they get to skip all the complicated stuff that makes them actually useful.

morelisp 7y ago
> Go has generic container types, so woot, no need for plain generics. There are dozens of common types that give the lie to this (the standard Go claim), like sync.Map, sync.Value, lru, or pool. Type classes are a feature that arises from having generics, not one that you need to take advantage of generics.