4 ms·
I for one like not having things rushed in which then cannot be changed later on. Does this mean Go is perfect? Not at all. It just means I'd rather have gene
by rubenv 5y ago
I for one like not having things rushed in which then cannot be changed later on.
Does this mean Go is perfect? Not at all.
It just means I'd rather have generics late than fundamentally broken.
- pjmlp 5y agoFor the time we have waited already, what is a couple of years more, right? Now if that would have been part of Go 1.0....
- can3p 5y agoSo far I prefer this approach to any other. I know this type of discussion happens under any go submission, but still - need in generics is overrated, there a ton of code written for all sorts and purposes and scales and it works just fine. And all that without a gigantic marketing push which means that developers simply like it that way it is. Go is about compatibility, being able to control your code base and being confident about results and I'd really prefer them to take their time thinking through a non-critical feature rather then rushing it and exploring all sorts of unexpected side effects down the road.
- pjmlp 5y agoIndeed, only Google paychecks, and two historical figures of UNIX and Plan 9 history, no marketing at all.
- grumpyprole 5y ago"Generics" or parametric polymorphism, first appeared in the 70's. So I don't think including this with Go 1.0 would have been rushing!
- arghwhat 5y agoYeah, about that: just because the theory exists doesn't make it less work to design new elegant typesystems around them. Go actively decided against generics in the beginning to make a small and simple language. We will lose that now.
- grumpyprole 5y agoAs they will need to be retrofitted just like Java had to do, yes I'm sure there'll be warts. Had they been considered from the start, I'm sure it could have been much simpler.