[deleted]
Generics enabled by default in Go tip
201–210 of 378 posts
Re: Generics enabled by default in Go tip
#202Super excited for this. If you haven't checked out the latest proposal, here's an example of what Option/Result box types might look like (obviously not ready for release, just an experiment): https://go2goplay.golang.org/p/krvTH1_7lwX
This seems somewhat strange to me (and I don't just mean hard on the eyes):
func (o Option[T]) Unwrap() T
Re: Generics enabled by default in Go tip
#203Every HN thread about go: go is useless because it lacks generics. Go adds generics. HN thread: I don't want this. Good case study about the people drawn to comment on a topic.
It’s almost like HN is not a single person
Re: Generics enabled by default in Go tip
#204Not to be contrary for its sake, but I'll say this is one change I'm really not happy about. I feel like it's a change to placate many, while driving a lesser amount away. Which is fine, but still feels like the end of something, as I am one of the aforementioned 'lesser.' As for why...I love above most the simplicity and readability of Go. Any change which encroaches that, which this does, is a net negative to me.
I agree. I feel like generics make more sense in a language like Rust or D or C++ (templates) where you need the performance of compile-time constructs, and generics specifically have that semantic. In Go, it doesn't make as much sense to not simply use an interface for the same purpose since the language is less bare-metal (or, rather, implementation-specific) by design.
It's not just about performance, or really not so much about performance - e.g. when Java added generics, they didn't make it any faster than it used to be when you had to use Object everywhere.
It's about type safety - i.e. catching bugs earlier and more reliably. Every time you have to write an explicit downcast, you are throwing away the benefits of using a statically typed language in the first place. Which is fine, but then why stop halfway, and not just go full dynamic? It doesn't really make sense to have strong typing for scalars but not for collections.
Re: Generics enabled by default in Go tip
#205Not excited about this feature, I guess we'll see how frequently it shows up in unwanted places. Generics in C++ really damage the readability of the code sometimes, maybe the go devs have found a better way. Very skeptical, but the go devs have given me plenty of pleasant surprises before, maybe we get another one here.
The key to readability is programming with readability in mind. Sure, languages play some part in that, but 90% of it is the programmer. Go is simple right now, and generics do complicate it, but even with the simplicity that Go has, people already make a giant mess of it. As soon as you get any advanced feature, people will abuse it -- colossal generic functions that take 5 interface{} arguments (but only ever opera…
> The key to readability is programming with readability in mind
Imo Golang buried that theory. I’ve read a lot of Golang code and it’s always been the clearest and most readable code I’ve read.
Re: Generics enabled by default in Go tip
#206I've never used Go, and from the outside I take a lot of issues with its design choices. But even without having used it I always thought the lack of generics was very interesting and I could see how it was desirable. It's fascinating to me that Go has gotten as far as it has without them (proving that it's possible to), and the mindset shift people describe having around them seems like a really important thing to p…
Java didn't have generics until version 5. They were added 8 years later.
Java didn't have user-defined generics, but it did have parametrized builtin types: arrays. Same thing for C#.
Re: Generics enabled by default in Go tip
#207Super excited for this. If you haven't checked out the latest proposal, here's an example of what Option/Result box types might look like (obviously not ready for release, just an experiment): https://go2goplay.golang.org/p/krvTH1_7lwX
This seems somewhat strange to me (and I don't just mean hard on the eyes): func (o Option[T]) Unwrap() T How does Go know that T is a type parameter here, and not a concrete type named T?
[deleted]
Re: Generics enabled by default in Go tip
#208Go needs custom generics for sure. But it is really a hurry-up to support custom generics for Go in version 1.18. Many problems have not been resolved yet. * should the builtin generics syntax be compatible with the new custom syntax * how many problems will be solved by the custom generics and how much complexities will be added. Is it a good balance?
The second question has been extensively answered by numerous mainstream languages adopting generics in the past, oh, 30 years or so?
Re: Generics enabled by default in Go tip
#209Language flamewars on internet forums are... strange. Why have we all so strongly coupled our identities as programmers to the language we use? Sense of community and a perceived need to defend it? I don't think Go needs generics, but I'm not about to invent obscure edge cases to justify for/against the idea. That's a recurring theme in all defenses of any language. It's not helpful. Use Go if you like the "clarity",…
Go has generics. They're just not (yet) available for you.
So to some it feels like a Tantalus punishment.
Re: Generics enabled by default in Go tip
#210Earlier quoted context omitted.
The langage which already had generics except special-cased to builtins the langage authors really wanted to be generic and they know better than the peons so they have the intellectual capacity to make this determination?
you sound bitter
I'm just believing what Rob Pike told me about his target users for Go.