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

81–90 of 273 posts

Re: A Proposal for Adding Generics to Go

#81

Post by masklinn »

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

The problem of doing that is twofold:

* each key now has 3 possible states (true, false, and unset) rather than two

* a bool takes 1 byte to store (which may get more problematic due to alignment, I've never checked what the memory layout of go's map is so I don't know how much of a concern it is there)

An empty struct fixes these issues: a key being present means the item is in the set, and an empty struct is zero-sized.

edit: apparently go maps are laid out as buckets of 8 entries with all the keys followed by all the values, so there's no waste due to padding at least.

Re: A Proposal for Adding Generics to Go

#82

Post by atombender »

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?

One challenge there is that identity is only supported for some built-in types — only primitives, and structs of primitives; no pointers, slices, maps.

If you want a set of some complex kind of value that contains non-map-indexable types like slices and pointers, then you have build an indirection around it.

A good set implementation needs to support a comparison operation. I really wish this existed for Go maps, too.

Re: A Proposal for Adding Generics to Go

#83

Post by lkramer »

coldtea wrote: post #61
lkramer wrote: post #48

Earlier quoted context omitted.

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

If others people code uses it, then those other people deemed it useful. So the argument for not having them now becames either: (a) they rather not have it available, because you personally don't find it useful (b) those using generic don't know what they're doing, and only people not using generic are smart, so it's better to not have them to prevent the clueless from being able to use them

Like I said, I use (and like) several languages that have Generics, and when I need to do something where it makes sense, I can reach for those. For me there was an advantage in having a language where it wasn't an option. Your (b) scenario is quite a strawman. I have seen plenty of good code using Generics, but sure, there is subset of code written using Generics that is not good, and I think it becomes easier to obfuscate code and make it hard to read if you have Generics, that might just by my bias, and I think I'm tainted from C++ and hopefully it will never become as bad as what you can encounter there.

I'm not trying to make out that Generics have no place in Computer Science. I was trying to make the case for it being nice that there was a language that didn't have it, and was building on the grandparent saying that he didn't miss it that often, which mirrors my experience with Go.

Re: A Proposal for Adding Generics to Go

#84

Post by cpascal »

skrtskrt wrote: post #14
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 like Go, but I too in the meantime have dipped my toes into Rust and it's just so much better without being that much more complex. The learning curve is real but quite a bit overstated I think.

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.

Re: A Proposal for Adding Generics to Go

#85

Post by masklinn »

candiddevmike wrote: post #54
lkramer wrote: post #51

Earlier quoted context omitted.

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).

I think you're looking at it wrong. You can absolutely solve it with interfaces, the problem is those interface methods are identical, so it's duplicative.

> I think you're looking at it wrong. You can absolutely solve it with interfaces

There are lots of generics use case you either can't solve at all with interfaces, or you have to contort every which way and usually lose something in the process (type-safety, performances, readability, …).

Re: A Proposal for Adding Generics to Go

#86

Post by whateveracct »

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…

parametric polymorphism does not make code harder to read

you know what's hard to read? hand-rolled for loops & select blocks combined to wrangle concurrency.

the no1 benefit of parametric polymorphism in Go is going to be abstracting over concurrency

Re: A Proposal for Adding Generics to Go

#87

Post by nine_k »

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…

With all the CVEs we see every month due to what can be only called design flaws in C, I have a hard time saying that C did fine for last 30 years.

For C+=1, I'd look at Zig; it unfortunately lacks the excellent corporate support that Go enjoys.

To me, Go looks much like early Java, only with a much better concurrency and saner "OOP". If anything, generics made Java better in many ways, without sacrificing performance or usability. It took 7 years for Java; it's going to take closer to 10 years for Go, bur better late than never.

Re: A Proposal for Adding Generics to Go

#88

Post by zenlot »

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.

If anyone wants to check fast compile times try Delphi, RAD Studio has community edition which is amazing. It feels like it compiles while you type :)

Re: A Proposal for Adding Generics to Go

#89

Post by jcelerier »

pkaye wrote: post #15
jcelerier wrote: post #12

every language designer who does not understand c++ is doomed to reinvent it I mean, seriously, func F[T any](p T) { ... }

What is wrong with that syntax?

? nothing is wrong, it's just a different way to spell

    template
    void F(T p) { ... }

Re: A Proposal for Adding Generics to Go

#90

Post by nine_k »

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…

A successor to C with mandatory garbage collection? Sorry, it's a wrong ballpark.
Post reply on HN