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

161–170 of 273 posts

Re: A Proposal for Adding Generics to Go

#161

Post by echelon »

andolanra wrote: post #46
johnnycerberus wrote: post #19

Earlier quoted context omitted.

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

Rust is as complex as C++, but it hides features from use unless you know you need them.

If you use vanilla Rust, it honestly feels quite high level, almost like Ruby or Python.

Re: A Proposal for Adding Generics to Go

#162

Post by johnnycerberus »

benibela wrote: post #157
johnnycerberus wrote: post #116

Earlier quoted context omitted.

I expect anything that has a little Pascal inside to be blazing fast.

And they have already added generics to Pascal It really makes Go look like a joke

The features I like about Go do not overlap with the ones of Pascal. But yes, it makes Go look underdeveloped in that department.

Re: A Proposal for Adding Generics to Go

#163

Post by [deleted] »

lkramer wrote: post #51
thomascgalvin wrote: post #44

Earlier quoted context omitted.

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…

Can you give a real world example that couldn't be solved with interfaces? The only real cases I can see is creating new data structures, (for instance if you wanted to create your own map type).

[deleted]

Re: A Proposal for Adding Generics to Go

#164

Post by TheDong »

randomdata wrote: post #159
TheDong wrote: post #148

Earlier quoted context omitted.

Can you give examples of specific language features of go that prevent you from making questionable design choices, that require you to "get the design right up front"? When I hear that, the first things that come to mind are things like haskell's IO monad, which forces you to model IO better than go or most other languages, or haskell's other state monads which similarly force you to model state more explicitly. I t…

> Can you give examples of specific language features of go that prevent you from making questionable design choices, that require you to "get the design right up front"? No, obviously. I said that Go doesn't give you an escape hatch if you screw up. It does nothing to protect you from screwing up. I specifically said that the challenge was in learning how to not screw up as the language doesn't help you deal with or…

Aaah, I read "Go requires that you get the design right up front" totally wrong, as in "go prevents you from getting the design wrong", not "go lets you get the design wrong, and then doesn't help you".

I still don't get your contrast to other languages though. Are there specific language features other languages have that let you paper over crappy designs?

Re: A Proposal for Adding Generics to Go

#165

Post by jacques_chester »

dilap wrote: post #156
jacques_chester wrote: post #136

Earlier quoted context omitted.

It doubles down on Go's assumption that git repository === a proper package/module system. It mixes up URLs and URNs. If your git repositories aren't tagged just so , then go mod throws its hands up and simply invents a whacky snapshot version. Because it can't itself properly determine "earlier version" from "later version" on that snapshot, you often wind up with multiple snapshots from the same repo, not infrequen…

Huh, interesting, thanks for the response. Does that mean Kubernetes is not following the version tagging policy in its repos? That seems...surprising!

Kubernetes has its own tagging scheme, which makes perfect sense in its context.

Re: A Proposal for Adding Generics to Go

#166

Post by uncledave »

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.

Yeah that's ok until you have 20 million lines of generic ridden crapola pumped out by the lowest bidder. That's the hell I spent a good chunk of the last few years untangling on the C# front. Let's model this correctly! Oh no someone said fuck it, lets just use a bunch of generic data types!

Dictionary>>, SortedSet>>>

Several thousand out of bounds, missing keys, null reference exceptions, hash collisions and the hair starts to get thin on top. I'm not even sure I'm happy with it for abstract data types.

Please can we keep Go special.

Re: A Proposal for Adding Generics to Go

#167

Post by joshlemer »

tptacek wrote: post #79
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 a…

Correct. As someone not doing Rust full time I do get tripped up on Rust's pervasive generics. Things like, "should I take a T argument here, or a U: Into, or U: AsRef" etc. Just seems like there's a lot of open world choices in the language which make it hard to get going quickly as a beginner

Re: A Proposal for Adding Generics to Go

#168

Post by brundolf »

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

It seems to me like generics are extremely important for "library code", and not super important for "application code" (and in fact they can sometimes create more confusion than they're worth in the latter context). Go also seems like a language that thrives in smaller-scale, application-focused contexts (microservices being the obvious example).

So in this light, and with the basic generic data structures supplied by the standard library, it seems to make sense for "user-level" Go code to generally be better-off without generics

Of course the line between "library" and "application" code isn't well-defined (especially if you consider libraries outside of the standard one), which is probably where most of the pain-points are coming in

Re: A Proposal for Adding Generics to Go

#169

Post by cratermoon »

moocowtruck wrote: post #115
cratermoon wrote: post #28

I look forward to generics in Go. Yes, it's possible to do it with reflection, interfaces and interface{}, but it's not typesafe, it's not fast, and it's prone to code bloat. I'm a fairly late-comer to generics, I never programmed seriously in C++, I avoided generics in Java initially, and I wrote a lot of code in less statically-typed languages. Ever since the first serious talk of generics in Go 2.0 I've endeavored…

generics in go will be a great addition, also it is important to realize generics in java and go are different such that go uses structural typing vs nominal

Yup, and they are different from generics/templates in C++ as well.

Re: A Proposal for Adding Generics to Go

#170

Post by setr »

alkonaut wrote: post #150

Finally. Hope it gets approved. It's strange that they don't consider Print[T](x T) instead of Print[T any](t T). The "any" could just be omitted without loss of anything. Especially since repeated types with the same constraints indeed DO omit it! Print2[T1, T2 any]

well, it doesn't omit it; it just applies it to all preceding arguments that didn't have a qualifier, same as normal golang function arguments. It's still being explicit about the constraint being `any`
Post reply on HN