Hacker News Reader

Comment by elpakal | Hacker News Reader

Chiming in here as a Swift dev - I find its generics system incredibly helpful and end up writing something that uses generics about once a month. To those Go programmers who think they will never use them - it’s worth a little learning, and once you do you will find more ways to use them to make your code more applicable.

View on HN

Chiming in as a fervent Go dev that's also a huge fan of generics: Generics are awesome, but always seem to add a ton of complexity. Everyone starts with just "oh, `func Reverse(slice []T)` is so obvious" kind of thing, but that's like saying `fmt.Println("Hello World")` is simple. It's simple cause you are doing a simple thing.

That said, I do want generics to come to Go, just... with an emphasis on what Go is, not just "here, let's replicate X's generics in Go". I am interested in the contracts implementation.

> Generics are awesome, but always seem to add a ton of complexity

The team I work in use generics all the time and I'm not sure what complexity you are referring to. Care to elaborate? Is it some edge cases or are you talking about from a compiler perspective or something else?

To me, not having generics is like saying let's skip handling bools and just store them in strings as "true" or "false". It's such a weird thing from my point of view.

I think TypeScript is a good example of one extreme. You've got conditional types, literal types, type mapping, and a bunch of other very advanced parameterized types.

(I also think it makes sense for TypeScript given JavaScript idioms; it mainly falls over when the caller has to interpret some very complicated error messages, however)

Compiler perspective (fast compiles are a core part of Go, IMO), various tradeoffs(fast compile? fast runtime? binary size? Pick 1 or 2), and seeing code bases that get out of control with generics and such.

Note that, for all of that, I'm still in favor of adding generics in Go, as I do see the value they can add. I'm just pointing out that "bashing" on Go devs on not knowing what generics are or how they can be useful is both non-productive and probably generally wrong. Plenty of us are saying "Man, if I had generics, this would have been less code/cleaner/more reusable!", just the other various tradeoffs outweigh the actual cost of using a different language. Go's ability to drop a very junior dev (or just one that has never use Go) into a codebase and have them be almost immediately productive is incredible.

> various tradeoffs(fast compile? fast runtime? binary size? Pick 1 or 2)

Interfaces are boxed already, so you've paid the price without having type safety. Simply treat a polymorphic function as if it accepted interface{}.

Try to read code that abuses generics you’ll see what GP means.

I can't write confusing code using just integers by abusing names to confuse you. You can write crappy code. Point?

"protocol can only be used as a generic constraint because it has Self or associated type requirements"

Pettifoging. I don't care what people do with them.

I know how to use them. They are valuable to me.

> To those Go programmers who think they will never use them - it’s worth a little learning, and once you do you will find more ways to use them to make your code more applicable.

There was a story I came across once. It went something like this:

The proponents of every gizmo think their gizmo is superior to the others, because it's got these useful features that the others lack, and isn't encumbered by the weird useless stuff those other languages have.

If only they spent time to understand those "weird useless features"...

I think you're talking about the Blub Paradox, by the guy who started this site.

Huh. Yeah, that's exactly it. Funny coincidence :)

Your presentation seems less directional than the original Blub article, FWIW.

Indeed. I remembered some aspect of directionality, but couldn't remember how to present it in as compelling a way.

(Also, I don't really agree with some objective single value gradient for programming languages. As for anything with multiple dimensions of value, it's not sortable)

Yeah, I think the less directional presentation is probably better. While we can certainly fit things to various hierarchies (approximately or exactly), enough of programming extends beyond pure expressivity (especially into tooling, social, workflows) that it's easy to not get how useful something can be without the relevant context. (This is something that I'm trying to remember, working in JS now after a few years of professional Haskell.)

From a psychological perspective, the non-directional presentation is also more likely to leave people less defensive and more receptive to the thesis.

This is the Blub Paradox. http://wiki.c2.com/?BlubParadox

What is it when you know about the power of features of the "higher level" languages, like generics, but still chose the "blub language" because of other reasons, like ease of hiring devs?

"Worse is better"

or just "Better has multiple dimensions", and not all of them are "Theoretically purer" or "look how succinct I can write this code". "How hard is it to hire devs?" is just one of those dimensions.

Reply on news.ycombinator.com