Earlier quoted context omitted.
Declaring a highly successful language as having the basics wrong means that you are not correct about the basics that were needed.
It's a highly successful language because (1) it was backed by Google, and (2) created by Robert Griesemer, Rob Pike, and Ken Thompson. If it came out of anywhere else, it might have struggled even to hit the homepage here.
Go: Support for Generic Methods
31–40 of 288 posts
Re: Go: Support for Generic Methods
#32slowly implementing all the things they said we didn't need
Debatable how much they have been "right", although this gets them somewhat closer. And I think they have not been "wrong" in the ways they wanted to avoid (they referenced some issues with Java generics as prior art, although I forget the details).
Re: Go: Support for Generic Methods
#33This is great. Will be useful for data access methods! As for the detractors, from the first generics proposal this was called out as a "not now", not never. There were questions of implementation. They aren't a super large team, and they try to do things incrementally and do them well.
Gophers are usually quite fast, perhaps an elderly turtle would be a better mascot?
Re: Go: Support for Generic Methods
#34Re: Go: Support for Generic Methods
#35Earlier quoted context omitted.
It's not a bad thing to realize that one can be wrong and then strive for change.
Maybe, but personally I've become quite tired of programming languages "organically grown" as opposed to properly designed the first time. After a good decade of C then C++, I found ANSI CL (despite being a massive compromise and unfinished) much more coherent and complete than both.
Objective-C in contrast was a very few additions thoughtfully added that composed cleanly and freed the programmer to actually get things done.
Re: Go: Support for Generic Methods
#36Earlier quoted context omitted.
There’s a fine line between being willing to change your mind and getting the basics wrong. Go has repeatedly gotten the basics wrong.
Declaring a highly successful language as having the basics wrong means that you are not correct about the basics that were needed.
Re: Go: Support for Generic Methods
#37Earlier quoted context omitted.
Declaring a highly successful language as having the basics wrong means that you are not correct about the basics that were needed.
Something can be highly succesful in spite of having glaring design flaws. Nobody is claiming go isn't wildly succesful, but it's _in spite_ of these issues. It was clear over a decade ago that iota, gopath, and lack of generics were massive kneecaps to the language; go changing it's mind on those things isn't progress it's just getting the fundamentals wrong. A good example of where they're kind of stuck is date for…
The trouble is that Rust is older than Go and it was already confusing people into thinking enums and sum types are the same thing, so by using slightly different syntax, iota, Go avoided the whole confusion of users thinking that enums would behave like sum types instead of actual enums.
Is your attempt at making a point that not having sum types is the massive flaw? Sum types are a useful construct, to be sure, but there are plenty of good languages without them. That's more on the design quirk end, realistically.
Re: Go: Support for Generic Methods
#38Earlier quoted context omitted.
It's a highly successful language because (1) it was backed by Google, and (2) created by Robert Griesemer, Rob Pike, and Ken Thompson. If it came out of anywhere else, it might have struggled even to hit the homepage here.
This logic is easily shown to not hold. Why isn't Carbon, Dart, etc. not really popular then?
Re: Go: Support for Generic Methods
#39Earlier quoted context omitted.
There’s a fine line between being willing to change your mind and getting the basics wrong. Go has repeatedly gotten the basics wrong.
Declaring a highly successful language as having the basics wrong means that you are not correct about the basics that were needed.
Re: Go: Support for Generic Methods
#40Earlier quoted context omitted.
Gophers are usually quite fast, perhaps an elderly turtle would be a better mascot?
In day-to-day usage, the (fast) compilation speed matters much more than the (slow) implementation of new features.