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

Toward Go 2

blog.golang.org

Post reply on HN
Print view View original

451–460 of 670 posts

Re: Toward Go 2

#451

Post by slantedview »

43224gg252 wrote: post #321
slantedview wrote: post #162

Earlier quoted context omitted.

The idea of needing to come up with use cases for generics is baffling. The existence of generics in numerous other languages already support of plethora of use cases. I really don't get that statement at all.

Then why don't you come up with a legitimate use case?

Because generics have been around for decades, and anyone who can't be bothered to look into the use cases for a feature that spans numerous languages over that time period doesn't deserve the time it takes someone else to spoon feed this information to them. This goes for the author of the article as well.

Re: Toward Go 2

#452

Post by Pxtl »

kernelbandwidth wrote: post #184
fusiongyro wrote: post #2

The paragraph I was looking for is this: > For example, I've been examining generics recently, but I don't have in my mind a clear picture of the detailed, concrete problems that Go users need generics to solve. As a result, I can't answer a design question like whether to support generic methods, which is to say methods that are parameterized separately from the receiver. If we had a large set of real-world use case…

The request for use cases in Go seems a bit like begging the question to me. Since Go doesn't have generics, anything designed in Go will necessarily take this into account and design around this lack. So it's relatively easy to show that Go doesn't have a compelling use case for generics, since the designs implemented in Go wouldn't (usually) benefit from generics! Rust has generics and traits/typeclasses, and the r…

It reminds me of the old urban planning line "You can't decide on the necessity of a bridge based on the number of people who swim across the river".

Users who have heavy need for genetics have already moved away from Go.

Re: Toward Go 2

#453

Post by Retra »

jules wrote: post #449
kevhito wrote: post #428

Earlier quoted context omitted.

Counting the weasel words.... 1. "might be" 2. "not entirely inaccurate" 3. "perhaps others" 4. "things like" 5. "the's reason to believe" 6. "apt enough" And that's just in your first sentence. My impression has always been that the Go core team is very open to the possible addition of generics, but also very wary of the very real downsides that generics have. Nothing I've ever seen from Rob or other core team membe…

What are the very real downsides that generics have?

Binary bloat and general difficulties with how one handles variance in light of people's expectations.

Re: Toward Go 2

#454

Post by slantedview »

treehau5 wrote: post #412
43224gg252 wrote: post #321

Earlier quoted context omitted.

Then why don't you come up with a legitimate use case?

I think this is a fair question. We have a lot of pseudo-intellectuals here that think 90% of their job isn't writing business functions. Not having generics in Go has not hindered me at all in performing the objectives of my business. Everyone wants generics, no one knows why. When I had generics in my previous two roles where I used Java and C# respectively, I can count on two fingers the number of times I needed t…

> Everyone wants generics, no one knows why

This is such a troll'ish statement, but I'll respond anyways because maybe you actually are just that uninformed. Without generics any number of libraries that utilize generic function blocks - Func [1] in C#, Callable [2] in Java, etc., and do things like return the function's type parameter as a method result, would not be possible. This is exceedingly common, at least in libraries. If you want to know how common, let me refer you to my friend http://google.com.

Just because something isn't valuable to you, personally, doesn't mean it's not valuable. As in all aspects of life, not everyone is you.

1. https://msdn.microsoft.com/en-us/library/bb549151(v=vs.110)....

2. https://docs.oracle.com/javase/7/docs/api/java/util/concurre...

Re: Toward Go 2

#455

Post by stefantalpalaru »

kccqzy wrote: post #327
fusiongyro wrote: post #2

The paragraph I was looking for is this: > For example, I've been examining generics recently, but I don't have in my mind a clear picture of the detailed, concrete problems that Go users need generics to solve. As a result, I can't answer a design question like whether to support generic methods, which is to say methods that are parameterized separately from the receiver. If we had a large set of real-world use case…

Generics in Go: https://twitter.com/snoyberg/status/882255351382462464

> Generics in Go: https://twitter.com/snoyberg/status/882255351382462464

Generics and Go: https://github.com/stefantalpalaru/golib-nim

Re: Toward Go 2

#456

Post by aaronblohowiak »

dgacmu wrote: post #442

I should send this to rsc, but it's fairly easy to find examples where the lack of generics caused an opportunity cost. (1) I started porting our high-performance, concurrent cuckoo hashing code to Go about 4 years ago. I quit. You can probably guess why from the comments at the top of the file about boxing things with interface{}. It just got slow and gross, to the point where libcuckoo-go was slower and more bloate…

please do send that to rsc

Re: Toward Go 2

#457

Post by ovao »

jimjimjim wrote: post #246

Here be Opinions: I hate generics. also, I hate exceptions. Too many people are wanting "magic" in their software. All some people want is to write the "Happy Path" through their code to get some Glory. If it's your pet project to control your toilet with tweets then that's fine. But if it's for a program that will run 24/7 without human intervention then the code had better be plain, filled with the Unhappy Paths an…

In Go, the magic right now is actually in special-cased types like map. Generics actually have the potential to reduce the amount of magic as it exists currently.

The design can go badly wrong, of course, but it can also go wonderfully right. Generics are a very important feature to consider for the language.

I have no opinion on exceptions with regard to Go specifically. I think they serve a good purpose in other languages but are often misused.

Re: Toward Go 2

#458

Post by [deleted] »

Retra wrote: post #453
jules wrote: post #449

Earlier quoted context omitted.

What are the very real downsides that generics have?

Binary bloat and general difficulties with how one handles variance in light of people's expectations.

[deleted]

Re: Toward Go 2

#459

Post by randomdata »

lomnakkus wrote: post #82
Spiritus wrote: post #65

Earlier quoted context omitted.

Did you even read the blog post? Such feedback was explicitly asked for.

Asking for use cases when the use cases and benefits are already well-known seems pretty disingenuous to me. (Of both you and the blog post.) ... but, hey, just to indulge you, a few off the top of my head: - Generic containers in libraries (aka not built-in) - Parametricity to restrict user-supplied implementations of interfaces; not quite as valuable in a language with casts, etc., but still reasonably valuable. -…

There are many different ways to provide generics (templates, typeclasses, etc.), each with their own pros and cons. It's not simply a matter of "add generics". And what solution they do come up with is going to bring the given cons those who would be better served by a different generics solution.

The Go team have been long criticized for choosing the option that fits Google, but not the rest of the world. This seems like their attempt to think about what others are doing with the language, beyond their insular experience, so they don't end up with something that fits Google perfectly but falls apart everywhere else.

If they don't take the time to learn how people intend to use generics in Go, the best solution for Google, and Google alone, is what we will get.

Re: Toward Go 2

#460

Post by AlphaSite »

davidp wrote: post #396
_old_dude_ wrote: post #342

Earlier quoted context omitted.

C# does generics specialization at runtime, hard to do if you have no JIT :)

Thanks for the tip, you made me go google some things! [0] Do you need a full-on JIT, or just a runtime? [1] [0]: https://docs.microsoft.com/en-us/dotnet/csharp/programming-g... [1]: https://docs.microsoft.com/en-us/dotnet/csharp/programming-g...

As I understand it it’s JIT in name only, doing the compilation on first run and then never again.
Post reply on HN