A Proposal for Adding Generics to Go • Hacker News Board

Re: A Proposal for Adding Generics to Go

#71

Post by johnnycerberus » Tue, Jan 12, 2021, 7:06 PM UTC

jacques_chester wrote: post #25

tschellenbach wrote: post #11

We have a very large Go codebase here at Stream and not having generics is just not really as big of an issue as you think it is. There are plenty of work arounds if you get used to not having generics in the language. The fast compile times of Go are amazing. I was doing some Kotlin a few weeks ago and the difference is crazy. Go: Install deps, compile everything done in 5s. Doing the same in Kotlin, laptop freezes,…

If we're dealing in anecdata, mine is that "Go compiles fast!" is true right up until something in your dependency tree hauls in kubernetes repos, perhaps multiple times. Thanks the "first principles" design of go mod, that's becoming increasingly unavoidable. Kotlin does compile much slower than I would like, but at least I only haul in one version of libraries and 0% of it is generated code. Java is basically insta…

Java, Go, OCaml, Typescript (>=3.9) are in their own league when it comes to compilation speed.

Re: A Proposal for Adding Generics to Go

#72

Post by lights0123 » Tue, Jan 12, 2021, 7:06 PM UTC

schpaencoder wrote: post #34

kitkat_new wrote: post #8

I hope at some point they manage to add it. I, however, discovered Rust in the meanwhile. It has generics. And it is not too complex either and has quite a few other bonuses.

How about the speed of compilation? Is it bearable?

It's very slow for the initial revision, as it has to compile all its dependencies. From there, if you add in full async/await support with a web server framework, you're looking at ~6sec iteration time. If you bring in LLVM's LLD instead of GNU or MSVC, you can bring that down to ~3-4sec. They're working on adding support for their own LLVM competitor, Cranelift, that should further reduce those times. It's only intended for debug/development builds, though, so you'll still need longer compile times for release.

Re: A Proposal for Adding Generics to Go

#73

Post by cratermoon » Tue, Jan 12, 2021, 7:07 PM UTC

philosopher1234 wrote: post #42

cratermoon wrote: post #20

Earlier quoted context omitted.

The golang nuts mailing list archive might be the best place to start. https://groups.google.com/g/golang-nuts

That is surely a history, but concise? Nope...

What I meant was, go ask there.

Re: A Proposal for Adding Generics to Go

#74

Post by anderspitman » Tue, Jan 12, 2021, 7:07 PM UTC

I've been heavy into Go the past year. I love the simple interfaces they've built over some rather complicated things (concurrency, cross-compilation, networking, etc), which really do tend to just work.

I fear that Go will eventually turn into something where we look back and realize we've lost something important by gaining a lot of less importants. The impulse to change things is just too strong these days. C89 has done just fine unchanged for 30 years.

All I want is a C+=1 I can rely on for the next 30 years.

Re: A Proposal for Adding Generics to Go

#75

Post by random5634 » Tue, Jan 12, 2021, 7:09 PM UTC

tschellenbach wrote: post #11

We have a very large Go codebase here at Stream and not having generics is just not really as big of an issue as you think it is. There are plenty of work arounds if you get used to not having generics in the language. The fast compile times of Go are amazing. I was doing some Kotlin a few weeks ago and the difference is crazy. Go: Install deps, compile everything done in 5s. Doing the same in Kotlin, laptop freezes,…

I'm pretty convinced they could have added some additional structure libraries to the standard library and called it good. Some map stuff / set stuff etc.

For many its really not a big deal not having generics, and makes code SO much easier to follow (and compile / debug etc).

Re: A Proposal for Adding Generics to Go

#76

Post by ed25519FUUU » Tue, Jan 12, 2021, 7:10 PM UTC

I'm really mixed about this. As a developer I would love having generics in Go. I can think of a few places in my code I can greatly simplify if they were implemented now.

However, as someone who reads other people's Go code, I'm not a huge fan. One of the greatest things about Go is that a developer can usually one-shot read and understand almost anybody's code because there's a simplicity "forcing-function" applied to everything. To lose that would be a shame.

Re: A Proposal for Adding Generics to Go

#77

Post by masklinn » Tue, Jan 12, 2021, 7:13 PM UTC

jjtheblunt wrote: post #55

egeozcan wrote: post #16

Earlier quoted context omitted.

I actually just need generic Sets. Generic map/reduce on slices wouldn't hurt too. OTOH, it's 2021 and look at what we are wishing. My love/hate relationship with golang is like the one I have with Apple.

isn't generic Sets easily implemented with map being already generic?

> isn't generic Sets easily implemented with map being already generic?

Since Go has neither generic functions nor generic typedefs you can't implement a Set with a generic key type on top of map, you have to reimplement all the set operations for each key type you use.

Re: A Proposal for Adding Generics to Go

#78

Post by eeZah7Ux » Tue, Jan 12, 2021, 7:13 PM UTC

johnnycerberus wrote: post #71

jacques_chester wrote: post #25

Earlier quoted context omitted.

If we're dealing in anecdata, mine is that "Go compiles fast!" is true right up until something in your dependency tree hauls in kubernetes repos, perhaps multiple times. Thanks the "first principles" design of go mod, that's becoming increasingly unavoidable. Kotlin does compile much slower than I would like, but at least I only haul in one version of libraries and 0% of it is generated code. Java is basically insta…

Java, Go, OCaml, Typescript (>=3.9) are in their own league when it comes to compilation speed.

you mean slow?

Re: A Proposal for Adding Generics to Go

#79

Post by tptacek » Tue, Jan 12, 2021, 7:13 PM UTC

kitkat_new wrote: post #8

I hope at some point they manage to add it. I, however, discovered Rust in the meanwhile. It has generics. And it is not too complex either and has quite a few other bonuses.

I went from writing almost 100% Go to an environment where I write 60/40 Rust/Go.

The worst thing we can have on any HN thread is a debate about the virtues of Rust vs. Go. They are different languages with somewhat different long-term goals and very definitely different short-term goals, and these threads are never interesting in anything but a sort of sporting event spectator way.

I will just say that while there are a lot of things I like more about Rust than about Go, generics in Rust come at a cognitive cost. They're infectious; they don't get used the way people say they need them for Go ("I need to be able to sort arbitrary things and have sets of arbitrary types"); they're as fundamental to Rust as interfaces are to Go. It adds a lot of additional indirection.

Re: A Proposal for Adding Generics to Go

#80

Post by __jem » Tue, Jan 12, 2021, 7:13 PM UTC

ed25519FUUU wrote: post #76

I'm really mixed about this. As a developer I would love having generics in Go. I can think of a few places in my code I can greatly simplify if they were implemented now. However, as someone who reads other people's Go code, I'm not a huge fan. One of the greatest things about Go is that a developer can usually one-shot read and understand almost anybody's code because there's a simplicity "forcing-function" applied…

In other words, go is the language you want your coworkers to write, not the language you want to write. :)