Hacker News Reader

Comment by bsaul | Hacker News Reader

I'm back to programming in swift after half a year of doing go only, and i'm more and more sceptical on the benefits of adding generic programming to the language.

I didn't take the time to really read the spec for go generics, but i really hope the gray beards didn't compromise on letting developers shoot themselves in the foot with overly complex design.

Nowaday i would recommend every developer to go through a 3-month coding session with go, solving real problem, to really appreciate how much one can do with just basic tools and an elegant design (with a few diving session in the stdlib codebase, which is just a pure gem).

This is by far the most important aspect of the language.

View on HN

> I'm back to programming in swift after half a year of doing go only, and i'm more and more sceptical on the benefits of adding generic programming to the language.

That's fine, you won't have to use them, or even use code that depends on generics.

And I won't have to remember a dozens of silly slice tricks each time I have to implement complex data pipelines with different struct types.

https://github.com/golang/go/wiki/SliceTricks

Everybody is happy.

If "you won't have to use it" is something people accepted then wouldn't everyone stick with kitchensink languages like C++ instead of coming up with new "clean" ones like Python, Java, C#, etc? :-P

> If "you won't have to use it" is something people accepted then wouldn't everyone stick with kitchensink languages like C++ instead of coming up with new "clean" ones like Python, Java, C#, etc? :-P

No because C++ still requires some amount of manual memory management, unlike the rest of languages you listed.

I use generics on daily base! Even a basic cache requires generic support. I don't want to litter my code with castings and ifs when there exists a decent solution to do all of the manual undertaking for you. That is what compilers were invented for rather than just generating plain code. You can obviously ignore them if you don't need them; but I can give you gazillion cases where not having generics and doing `interface{}` based casting makes situation messy and repeated on code rather than simpler.

> I'm back to programming in swift after half a year of doing go only, and i'm more and more sceptical on the benefits of adding generic programming to the language.

I'm not sure how the generics implementation in Swift has any bearing on how generics will work in Go.

Especially when the implementation is completely different and have nothing in common with Swift. Go took the ADA route with incomplete type instantiation (with the bonus of type inference).

No, it's just people complaining about generics for the sake of it at that point.

Yeah, it's kind of interesting how two extreme camps have evolved out of the "controversial" decision not to include generics in Go 1.0:

* Camp 1: generics will always be horrible, Go is right not to include it, it's too complex, Go is meant to be simple, etc.

* Camp 2: I will never use Go because it doesn't have generics, serious languages have generics, etc.

When in reality, both camps are pretty much wrong. Yes, generics are useful in a lot of places. But they also add no value in a lot of places. It's really on you to pick the tool you want to use. If you really want generics, pick C++ or Java instead. If you couldn't care less, Go is an option. It's much more fluid than this binarization of the topic has made it out to be.

The issue is that the decision of which language to use at an employer is outside the control of the individual, so they're stuck with it.

Or Camp 3: Go is nice and I can't wait for generics to be included. It doesn't have to be either with or without.

0.3% of my whole life just to test out one single programming language doesn’t sound unreasonable.

Reply on news.ycombinator.com