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

141–150 of 273 posts

Re: A Proposal for Adding Generics to Go

#141

Post by dangoor »

anderspitman wrote: post #74

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

> The impulse to change things is just too strong these days.

FWIW, I don't think this impulse is there with the Go team. Go progresses quite slowly, from what I've seen as a user over the past 18 months. Generics have been in discussion for a long time with multiple implementations and no real rush to "just ship it".

Re: A Proposal for Adding Generics to Go

#143

Post by recursive »

mikepurvis wrote: post #105
dgb23 wrote: post #70

Earlier quoted context omitted.

Rust has quite a few concepts you won't find in (some of) those languages like borrowing, lifetimes, traits, monomorphization, macros, type semantics around concurrency, (partial) expression based syntax, pattern matching and match guards... However you can litter your code with unwrap and clone to reach the finish line quickly, but then you lose the two main value props of the language and likely lose performance an…

New concepts, yes, but I think anyone who has spent any significant time programming in C++ will immediately recognize the problems that they are solving and how the solution works. That significantly eases the learning curve in my opinion.

But we weren't talking about those who had spent significant time working in C++.

Re: A Proposal for Adding Generics to Go

#144

Post by kitd »

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

Generics make working with reactive APIs much easier, which I think fits with a large chunk of Go's target audience (b/e networked services) quite closely.

Writing APIs to deal with futures, etc, is much easier when you can chain parameterised functions together.

Re: A Proposal for Adding Generics to Go

#145

Post by mseepgood »

fanf2 wrote: post #68
Animats wrote: post #65

Two more levels of blogs down, the actual proposal.[1] Definition: // Print has a type parameter T and has a single (non-type) // parameter s which is a slice of that type parameter. func Print[T any](s []T) { ... } Call: Print[int]([]int{1, 2, 3}) Above, "any" is really just a synonym for "interface{}". You can have more restrictive type constraints on parameterized types by specifying other Go interfaces. This is v…

My understanding from the “Featherweight Go” paper https://arxiv.org/abs/2005.11710 is that generic types will not simply be a synonym for interface{} because the compiler will be able to monomorphize them - they do not require dynamic dispatch like interfaces.

> My understanding from the “Featherweight Go” paper https://arxiv.org/abs/2005.11710 is that generic types will not simply be a synonym for interface{}

The `any` constraint is a synonym for the `interface{}` constraint.

Re: A Proposal for Adding Generics to Go

#147

Post by jcelerier »

esarbe wrote: post #134
jcelerier wrote: post #89

Earlier quoted context omitted.

? nothing is wrong, it's just a different way to spell template void F(T p) { ... }

No, not acually. Generics in Go are vastly different than templates in C++. They might be used for similar things, but whereas Go's generics actually build up on Go's structural typing, templates are ... something completely different again. I mean; C++ templates are Turing complete. They are in the same ballpark as Scala's type machinery. And I say that with adoration.

> I mean; C++ templates are Turing complete.

that's not a very high milestone to achieve. Even java generics are turing complete (https://arxiv.org/abs/1605.05274)

Re: A Proposal for Adding Generics to Go

#148

Post by TheDong »

randomdata wrote: post #114
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,…

The biggest challenge is avoiding the tricks from languages that allow you to use the language to paper over questionable design choices. Go requires that you get the design right up front and provides few escape hatches to save you if you mess up. Which is a good thing, but makes the language (not just the syntax) difficult to learn compared to others.

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 think of rust's lifetime and ownership system, which forces you to correctly model the ownership of types and prevents quite a few bad design patterns (which I see constantly in go btw; the number of times I've seen races due to multiple goroutines writing to a struct is large, the number of times I've seen incorrect synchronization that rust would have prevented is large).

I can't think of anything in go that pushes you towards designing your code well in go, especially when compared to languages with more complete type-systems.

Re: A Proposal for Adding Generics to Go

#149

Post by rbranson »

boyter wrote: post #94
wejick wrote: post #45

Earlier quoted context omitted.

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

Not familiar with Ada but the inability to stop running goroutines from outside it is annoying and leads to a lot of state telling them to exit. Sometimes I just want it to stop now.

How would you expect that to actually work though? If a goroutine could be arbitrarily stopped at any point, that would trivially lead to degenerate program states. A lock could be held open or another goroutine could be waiting on it for a message.

Re: A Proposal for Adding Generics to Go

#150

Post by alkonaut »

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]

Post reply on HN