Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

A Proposal for Adding Generics to Go

blog.golang.org

Post reply on HN
Print view View original

121–130 of 273 posts

Re: A Proposal for Adding Generics to Go

#121

Post by esarbe »

lkramer wrote: post #100
coldtea wrote: post #60

Earlier quoted context omitted.

> The only real cases I can see is creating new data structures Half of programming is creating new data structures. The other half is tranformations (e.g. map, filter, reduce, min, max, etc) which also benefit from being generic.

Sorry, when I said new data structures, I meant containers like maps and list, which I very rarely get to create day to day. I can see it for your transformations, but I have seldom seen cases where generics would really help (usually we're talking about comparing complex structure types that will need custom code anyway).

How about sets?

Re: A Proposal for Adding Generics to Go

#122

Post by jrockway »

joshlemer wrote: post #62
fileeditview wrote: post #58

Earlier quoted context omitted.

Yes and that's probably why there is no set in the go std lib. You just can use struct{}{} as (empty) value in a map.

I thought the idomatic approach was to represent sets with map[key]bool

A map[T]bool has 3 states for every key; absent, true, and false. A map[t]struct{} has 2 states for every key; absent, and present.

People new to Go tend to pick map[T]bool or map[T]int because they're used to using bools and ints throughout their code, but struct{} is the correct value type for sets. (That is not to say that a counting set, map[T]int is useless, however. If you need that, use that!)

Re: A Proposal for Adding Generics to Go

#123

Post by sam_lowry_ »

stickfigure wrote: post #99
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 remember thinking something similar about my Java 1.4 codebase back in the early 2000s. It's fine, right? What could I be missing? The answer is: A lot.

I miss Java 1.4. It was small and concise. Java 5 added so much that none knows all of it. Just look at the length of Java Generics FAQ. It's hilarious.

Re: A Proposal for Adding Generics to Go

#124

Post by esarbe »

hackyhacky wrote: post #6

As much as I've cursed the lack of generics and the limited expressiveness of Go's type system, it's hard for me to reconcile these proposals with what I know of Go. Go was conceived as a small language, a successor to C, and purposely eschewed "new-fangled" features of modern languages. Whether the result is good is a matter of taste, but I feel that retroactively bolting on a modern type system will simultaneously…

I don't think that Go ever was a very good successor to C. Go might have been conceived as a systems language, but simply because of the GC it can never ever fill that niche.

Go is a perfectly fine middleware language, but no C replacement. (Rust does much better in that regard).

Re: A Proposal for Adding Generics to Go

#125

Post by efaref »

lights0123 wrote: post #72
schpaencoder wrote: post #34

Earlier quoted context omitted.

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 int…

While the compile times are a bit slower, one of the advantages of the strict type system is you don't need to compile to an executable quite as often.

Most of the time your IDE's messages (or "cargo check" output) is sufficient to find all the things the compiler will complain about.

I usually find that once I've fixed all of those, I compile it once and it just works.

Re: A Proposal for Adding Generics to Go

#126

Post by tomlu »

cletus wrote: post #10

Another comment mentions this is the third (serious) attempt at adding generics to Go. Is there any concise history of these attempts (including this one)? I'd like to understand the gist of these proposals and what ultimately derailed them. By themselves these proposals are pretty inscurtable.

The major difference is the first proposal separated interfaces from concepts, later proposals (very wisely) unified them. Only concepts could be used in type constraints.

They also switched from parenthesis () to square brackets [], thankfully.

Re: A Proposal for Adding Generics to Go

#127

Post by jrockway »

lkramer wrote: post #48
deskamess wrote: post #36

Earlier quoted context omitted.

The introduction of generics would not change your workflow though. You could still happily "not use it" and keep matters readable. Others who wanted it, would use it.

Mostly concerned about having to read other people's code that uses it.

That ship already sailed with widespread misuse of interfaces. Consider:

    package foo

    type T interface { func Bar() }

    func New() T {
       return &someotherpackage.ImplPickedAtRuntime{...}
    }
Now whenever you see:

    x := foo.New()
    x.Bar()
You have no idea where to read the code for Bar. For maximum fun, ImplPickedAtRuntime should then contain members that were allocated in the same way. What should be a simple M-. then eats up your entire afternoon.

Re: A Proposal for Adding Generics to Go

#128

Post by abhijat »

skrtskrt wrote: post #95
cpascal wrote: post #84

Earlier quoted context omitted.

I'm taking my second crack at learning Rust and I have to say I've made a lot more progress this second attempt. It could be just giving things time to stew in my head, but I really think it's because I'm using rust-analyzer with vscode and before I was using RLS. Rust-analyzer is a much richer experience and its informative error messages and suggestions lessens the learning-curve drastically.

I am having the exact same experience. I think one think that could seriously be improved is high-quality explanations of Rc, RefCell, etc, and where and why they are used. I have found myself piecing together explanations from various books, Reddit threads, etc just to try to wrap around these.

In my experience a combination of the rust book followed by the too many linked lists book was enough to give a pretty good idea of Rc, RefCell etc and how they can be used.

Re: A Proposal for Adding Generics to Go

#129

Post by AlphaSite »

anderspitman wrote: post #110
bcrosby95 wrote: post #103

Earlier quoted context omitted.

I think they're talking about the simplicity of C. But yeah, I like to think of Go as a Java for the new millennium. We're a Java shop and lots of people hate some of the newer changes to the language. And how OOP focused it is. I think Go would be a better fit because it seems to match the philosophy of our team more. But don't really think it's worth the switch for us.

I've used Java and Go. I find Go a far superior experience. Part of that is the standard library which seems to strike a perfect balance providing what you need but not too much. I also think a lot of it has to do with the culture of the languages. Kotlin is a pretty nice language, but using it for Android still makes me want to hit my computer with a hammer because the over-abstraction of the Java ecosystem is madde…

I was under the impression modern Java was becoming more functional than more OO (or at least de-emphasising inheritance).

Re: A Proposal for Adding Generics to Go

#130

Post by jrockway »

dhagz wrote: post #57
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…

I'm currently working on a project that depends on the k8s APIs and I haven't noticed ballooning compile times. I'm only pulling in k8s.io/api, k8s.io/apimachinery, and k8s.io/go-client though.

I have the same experience. I maintain lots of software that directly depends on k8s.io/go-client and it feels the same as any other Go project.
Post reply on HN