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

41–50 of 273 posts

Re: A Proposal for Adding Generics to Go

#41

Post by DaiPlusPlus »

hackyhacky wrote: post #33
DaiPlusPlus wrote: post #30

Earlier quoted context omitted.

C doesn’t lack safety by-design - it’s hobbled by its history and constraints imposed by its userbase - otherwise C would have major breaking changes more often.

C absolutely lacks type-safety by design. Otherwise what would malloc return, besides void*? How would you implement generic containers in C, without using macros or void*? Edit: formatting

* malloc would accept a typename argument T and return T*

* calloc would a;so accept a typename T and count and return T[count]*

* Generic containers could be implemented as something closer to C++ templates (or preprocessor macros on steroids, like T4, as you suggest).

Re: A Proposal for Adding Generics to Go

#42

Post by philosopher1234 »

cratermoon wrote: post #20
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 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...

Re: A Proposal for Adding Generics to Go

#43

Post by mrnothing_123 »

hackyhacky wrote: post #29
kitkat_new wrote: post #18

Earlier quoted context omitted.

The lack of generics makes it only more complex. Simplicity: yes, but in a senseful manner. Omitting generics is not senseful to me.

I agree. But if you like generics, why not use a language that already has them, e.g. Rust, Haskell, etc.

maybe you already use go-lang, and want generics.

Re: A Proposal for Adding Generics to Go

#44

Post by thomascgalvin »

lkramer wrote: post #26
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,…

This is not the first time I argue this case, but I would go a step further and say that not having generics is feature of Go. There are plenty of languages out there with Generics. I use several of them. I use Go when that suits me, and it's typically for cases where high readability trumps doing a lot of magic with generics. I think only once or twice have I thought to myself, "this would have been better with Gene…

Generics aren't magic, and they aren't Turing complete, like C++ templates. They're just a way to avoid copy-pasting code.

Having `Set` and `Set` is far more readable than `class FooSet` and `class BarSet`, where the code is exactly the same aside from a search-and-replace.

You also run into issues where someone finds a bug in `FooSet`, but doesn't know `BarSet` exists, and forgets to patch both. Now, you have two divergent copy-paste classes.

Generics solve a bunch of real-world problems, in a very simple manner.

Re: A Proposal for Adding Generics to Go

#45

Post by wejick »

throw_m239339 wrote: post #32
azhenley wrote: post #2

How many different proposals for generics have there been?

Actually not that much, I remember 2 very different proposals, including this one. The previous one was confusing as F and the antithesis of the simplicity Go claims it abides by. It felt very much like a plot to add generics without ever using the word generics anywhere and looking too much like Java/C#/... The current proposal is basically what you'd expect from generics in a programming language, but a bit more li…

I'm curious what's the issue with go routine and what kind of fix ADA bring?

Re: A Proposal for Adding Generics to Go

#46

Post by andolanra »

johnnycerberus wrote: post #19
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 would say that in the case of Rust, generics are on the list of those "few other bonuses". There are other things in Rust that are more attractive and innovative. Rust is as complex as C++ (which is not a compliment) but saner and safer, without undefined behavior. Though, at the rate they add new features, I can see it becoming rapidly a kitchen sink.

Rust is a reasonably complex language, but—having programmed professionally in both—I don't think it's nearly as complex as C++. Rust features for the most part are orthogonal to each other, whereas C++ features tend to have weird interactions with each other that are really hard to track and understand. (The one place where Rust starts to get messier in terms of feature interactions is async Rust, but luckily you can program Rust just fine while ignoring the async features.)

Consider initialization: C++ has dozens of different ways of initializing objects that in turn interact in complicated ways with move semantics and references and so forth. Rust's initialization story by contrast is straightforward: you just make the thing you want to make using struct or enum literals and maybe wrap those initializers in functions if you want.

Re: A Proposal for Adding Generics to Go

#47

Post by DaiPlusPlus »

hackyhacky wrote: post #37
peawee wrote: post #31

Earlier quoted context omitted.

And that's (part of) why C needs to go.

Sure. But why not replace it with something that is type-safe AND already has generics, like Rust? Why are we trying to get a do-over on Go?

At this point it’s history: Go and Rust both got started around the same time - one by Mozilla and the other by Google. They’ve both reached critical-mass over the past ~10 years - so expecting one of them to disappear is like expecting Autodesk to choose between 3ds and Maya...

Re: A Proposal for Adding Generics to Go

#48

Post by lkramer »

deskamess wrote: post #36
lkramer wrote: post #26

Earlier quoted context omitted.

This is not the first time I argue this case, but I would go a step further and say that not having generics is feature of Go. There are plenty of languages out there with Generics. I use several of them. I use Go when that suits me, and it's typically for cases where high readability trumps doing a lot of magic with generics. I think only once or twice have I thought to myself, "this would have been better with Gene…

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.

Re: A Proposal for Adding Generics to Go

#49

Post by hackyhacky »

DaiPlusPlus wrote: post #41
hackyhacky wrote: post #33

Earlier quoted context omitted.

C absolutely lacks type-safety by design. Otherwise what would malloc return, besides void*? How would you implement generic containers in C, without using macros or void*? Edit: formatting

* malloc would accept a typename argument T and return T* * calloc would a;so accept a typename T and count and return T[count]* * Generic containers could be implemented as something closer to C++ templates (or preprocessor macros on steroids, like T4, as you suggest).

There is no typename in C.

Re: A Proposal for Adding Generics to Go

#50

Post by dgb23 »

I find the proposal interesting. Type constraints might help to reason about a given abstraction. If I understand correctly they behave quasi like sum types over interfaces.

From skimming here: https://go.googlesource.com/proposal/+/master/design/go2draf...

They don't feel like generics in for example Java (my Java is rudimentary), but rather like an abstraction over interfaces.

Can anyone elaborate on this?

Post reply on HN