Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Go: Support for Generic Methods

github.com

Post reply on HN
Print view View original

121–130 of 288 posts

Re: Go: Support for Generic Methods

#121

Post by 9rx »

stouset wrote: post #113
9rx wrote: post #46

Earlier quoted context omitted.

The social landscape doesn't depend on anyone actually using it. However, 1.0 isn't a significant milestone like you suggest either. For a current example, Zig is relatively popular today despite not yet reaching 1.0.

Do you just forget the things you write in earlier comments? > Rust is older than Go and it was already confusing people into thinking enums and sum types are the same thing Of course the social landscape depends on people actually using it. None of the people who weren’t using Rust at the time were magically confused about enums and sum types by the mere existence of some new and experimental language. Rust barely e…

> Of course the social landscape depends on people actually using it.

That's nonsense. Brainfuck has shaped the social landscape despite effectively nobody using it, and absolutely nobody using it for any real work. The social landscape is not at all dependent on use.

> And given the history of Go and the notoriety of its core team for flatly ignoring prior work in programming languages

Huh? Go comes straight out of prior work. It is nearly indistinguishable from Alef. What the Go language flatly ignored was being innovative. Reasonably so, of course. It wasn't trying to innovate in programming languages so that we'd have another to throw on the heap of languages nobody uses. It was trying to solve a specific business problem using well-established methods.

Re: Go: Support for Generic Methods

#122

Post by stouset »

9rx wrote: post #117
stouset wrote: post #115

Earlier quoted context omitted.

> You're almost there, but it is wildly considered to be massive mistake in context of arrays. From Tony Hoare: "I call it my billion-dollar mistake. It was the invention of the null reference in 1965. At that time, I was designing the first comprehensive type system for references in an object-oriented language (ALGOL W). My goal was to ensure that all use of references should be absolutely safe, with checking perfo…

> Like by not remembering to check if a pointer is nil? Rule of thumb is to not introduce values that aren't valid. Equally, don't put in -1 for an age value, even if the language allows you to. You might later forget to validate that the age value is valid. Yes, mistakes are possible, but these types of mistakes are pretty rare. There is some value in eliminating the possibility of those mistakes, sure, but we canno…

Ah the good old “just be a perfect programmer and you won’t run into any issues” argument. Haven’t heard that one in awhile.

Re: Go: Support for Generic Methods

#123

Post by kbolino »

nasretdinov wrote: post #68
ncruces wrote: post #50

Earlier quoted context omitted.

To be replaced by the surprise when you figure out these methods don't implement interfaces. Still, in this case, half the feature is better than none at all, IMO.

Generic interfaces are going to be implemented later too if I'm reading correctly. So no real surprises there :). I guess the only surprise yet is that generic interfaces aren't supported, so generic methods physically can't satisfy any interface

Generic interfaces already exist. Generic interface methods, which would be relevant, are not planned. The reason is outlined early in the proposal: nobody knows how to implement them efficiently. Rust has the same problem, for what it's worth: dispatchable functions on dyn-compatible traits cannot be generic [1].

[1]: https://doc.rust-lang.org/reference/items/traits.html#r-item...

Re: Go: Support for Generic Methods

#124

Post by 9rx »

stouset wrote: post #122
9rx wrote: post #117

Earlier quoted context omitted.

> Like by not remembering to check if a pointer is nil? Rule of thumb is to not introduce values that aren't valid. Equally, don't put in -1 for an age value, even if the language allows you to. You might later forget to validate that the age value is valid. Yes, mistakes are possible, but these types of mistakes are pretty rare. There is some value in eliminating the possibility of those mistakes, sure, but we canno…

Ah the good old “just be a perfect programmer and you won’t run into any issues” argument. Haven’t heard that one in awhile.

If only you had made it to the second paragraph.

Hey, at least we can now understand why you have such a hard time with nil, so that's something.

Re: Go: Support for Generic Methods

#125

Post by the_gipsy »

skywhopper wrote: post #78
tines wrote: post #64

Earlier quoted context omitted.

From another commenter here: > The post quotes the Go FAQ as saying, "we do not anticipate that Go will ever add generic methods".

Is anyone actually mad about this, or do people just bring it up to stir the pot? Who cares what the FAQ says? They've worked out a way to add it easily in a backwards compatible way that can solve some problems. They had not identified this solution at the time they wrote the FAQ, and Go has been perfectly usable without this feature for 16 years.

You just can never trust what the go team says.

Re: Go: Support for Generic Methods

#126

Post by Matl »

the_gipsy wrote: post #125
skywhopper wrote: post #78

Earlier quoted context omitted.

Is anyone actually mad about this, or do people just bring it up to stir the pot? Who cares what the FAQ says? They've worked out a way to add it easily in a backwards compatible way that can solve some problems. They had not identified this solution at the time they wrote the FAQ, and Go has been perfectly usable without this feature for 16 years.

You just can never trust what the go team says.

Yeah, because software is not meant to evolve and people are not meant to either.

Re: Go: Support for Generic Methods

#127

Post by ivanjermakov »

TheChaplain wrote: post #3
h1fra wrote: post #2

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

It's not a bad thing to realize that one can be wrong and then strive for change.

Worst thing a programming language can do is introduce core semantics changes after 1.0. See Python 2 -> 3 and Zig's *gates.

Re: Go: Support for Generic Methods

#128

Post by ivanjermakov »

whoiskevin wrote: post #21
maccard wrote: 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.

https://en.wikipedia.org/wiki/Worse_is_better

Re: Go: Support for Generic Methods

#129

Post by tialaramex »

kbolino wrote: post #123
nasretdinov wrote: post #68

Earlier quoted context omitted.

Generic interfaces are going to be implemented later too if I'm reading correctly. So no real surprises there :). I guess the only surprise yet is that generic interfaces aren't supported, so generic methods physically can't satisfy any interface

Generic interfaces already exist. Generic interface methods, which would be relevant, are not planned. The reason is outlined early in the proposal: nobody knows how to implement them efficiently. Rust has the same problem, for what it's worth: dispatchable functions on dyn-compatible traits cannot be generic [1]. [1]: https://doc.rust-lang.org/reference/items/traits.html#r-item...

Or to look at that from another angle, if you were to define a Trait which has generic methods that Trait won't be "dyn-compatible" meaning that you can't do dynamic dispatch with this trait, which may be irrelevant to you (if you don't want dynamic dispatch anyway) or a showstopper (if you needed it, now your project won't compile).

Re: Go: Support for Generic Methods

#130

Post by [deleted] »

ncruces wrote: post #50
nasretdinov wrote: post #18

Lack of generic methods was really surprising to me when I was first trying to use generics in Go. Nice to see it being actually implemented

To be replaced by the surprise when you figure out these methods don't implement interfaces. Still, in this case, half the feature is better than none at all, IMO.

[deleted]
Post reply on HN