Live data from Hacker News

Go: Support for Generic Methods

github.com

31–40 of 288 posts

Re: Go: Support for Generic Methods

#31
post #28

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.

This logic is easily shown to not hold. Why isn't Carbon, Dart, etc. not really popular then?

Re: Go: Support for Generic Methods

#32
post #2

slowly implementing all the things they said we didn't need

They didn't say they never wanted to do generics, but that they did want to take their time and do them right.

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

#33

This 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?

In day-to-day usage, the (fast) compilation speed matters much more than the (slow) implementation of new features.

Re: Go: Support for Generic Methods

#35

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

I liked Objective-C (except the C parts). Such a breath of fresh air coming from C++ which was grown like a cancer with tons of features and you felt trapped by every one of them.

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

#36
post #10

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

The basics of a programming language were wrong. The basics of marketing were very right. Those are not the same.

Re: Go: Support for Generic Methods

#37
post #29

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.

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…

Why is iota a massive kneecap to the language? It is semantically identical to enum in C and Typescript.

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

#38
post #28

Earlier 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?

Its just bitter dorks bitter their pet language with cutting edge programming abstractions didnt make it to the big leagues.

Re: Go: Support for Generic Methods

#39
post #10

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

By that logic Windows would be the best operating system ever and perfect in every way, and anyone who disagrees must be wrong about how an OS should be.

Re: Go: Support for Generic Methods

#40
post #33

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

I totally agree, but I'd go further and argue that slow implementation of new features is itself a desirable trait. It's one of the reasons why why I like both Go and Clojure.
Post reply on HN