Hacker News Reader

Comment by sam0x17 | Hacker News Reader

Meanwhile Crystal lang has had generics for years and years. Just saying :D

That said, super excited to see Go maturing to the point where they address the #1 complaint about the language. Maybe I'll actually pick it up once this goes through!

View on HN

I don't know why "having generics" is regarded as an end unto itself, or even a particularly important feature. The more experienced I've become as a developer, the more I realize that the things that matter tend to be tooling, ecosystem, learning curve, documentation, standards, performance, etc. The things that tend not to matter so much are type system particulars. If people can make crazy money with dynamically typed languages, having a type system that provides static guarantees for 95% of use cases (beyond which you have to opt into dynamic typing via interface{}) is honestly fine. It's not elegant, but it gets the job done for a huge swath of software. Generics are nice to have, but I think people blow them wildly out of proportion.

EDIT: My implicit criterion for programming languages is the extent to which they facilitate software development, not some pursuit of elegance unto itself (although I fully empathize with the latter). These two things are not particularly congruent, but I often get the vibe that much criticism of Go assumes that it exists to be elegant instead of practical.

Cuts down on code and eases refactoring. Makes it faster to go from my mind to my code! (Once you get past the syntactical reading bump.) I'm really looking forward to really cleaning up some database and report code in particular. Bummed we won't see it in Go until at least 2022 though.

No doubt, but again we're talking about a single digit percentage of code paths, and again there are entire blockbuster applications written without any static typing at all. It'll be a nice feature for sure, but it's not like world-class software wasn't written in Go before nor will Go+generics be a "Java-killer".

Better just to flag language war comments, which otherwise strangle threads like kudzu.

> Generics are nice to have, but I think people blow them wildly out of proportion.

The main alternative is code generation, which is slow, brittle and hostile to easy version control.

I'd rather have a code type system than a system typing out code.

Fully agree that generic type system is nicer than code generation; however, code generation thankfully isn't the only alternative nor even the best. Rather, as previously mentioned, we can use `interface{}` which is roughly the same as using dynamic types for the relevant bit of code. If people can make blockbuster apps with dynamically typed languages (100% of code paths are dynamically typed), it's really not a big deal that Go makes you drop into dynamic typing for <5% of code paths.

I don't see interface{} as an improvement over code generation.

I think you'll find that your opinion is very fringe, but by all means, go forth and use code generation.

My opinion is that I greatly prefer generics to either.

Having genetics as a good option is great. Using interface{} works too, but is a kludge if you have to do it alot. You lose performance to reflection and gain runtime errors that are hard to handle. It's not the best part of Go, far from it.

Codegen can work around weakness in a language, but the key is a build system that generates code, compiles it, and then throws it away. Checking it in is a mistake, because you have to start reviewing it if there’s any possibility of editing it.

lol

Reply on news.ycombinator.com