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

Notes on the Go2 Generics Draft

jmoiron.net

Post reply on HN
Print view View original

111–116 of 116 posts

Re: Notes on the Go2 Generics Draft

#111

Post by Exuma »

dunpeal wrote: post #26
Exuma wrote: post #25

Can someone explain in terms to someone who hasn't really used a static typed language what "generics" are? I've only used javascript and ruby.

In a static language, functions, classes, and types are often parametrized by other types. For example, with a function: imagine you wrote a `sum(array)` function. In Ruby that's not a problem, because array can contain any types, as long as they support the + operator (aka duck typing). Any function can also return any type of object. In a static language, however, an array that holds floats has a different type tha…

Awesome, so this makes sense. So I guess people are against it because they like the explicit simple nature of Go rather than some sort of abstraction magic?

Re: Notes on the Go2 Generics Draft

#112

Post by piano »

nemo1618 wrote: post #24

I'm glad I'm not the only one sad to see generics invading a perfectly good language. Programmers love generics because they enable higher-order abstractions, and programmers love abstractions -- code that isn't DRY is like an itch we need to scratch. Programmers also hate special cases, because they feel restrictive and inconsistent: I recall quite a few people protesting that Go's 'range' keyword shouldn't be restr…

> Go tries to be non-magical, and sadly that can take much of the whimsy out of programming.

That's a weird thing to say seeing that Go very much is magical... Slices/arrays are magical and so are maps, channels and channel operators, the make() function and a whole bunch of other features.

I think your understanding is filpped. Generics are not a way to add magic, they remove magic. That's the whole point. Unfortunatelly, that which one doesn't understand may seem like magic to them even though it's not.

For example, compare a channel implementation in Go and Rust. In Go, the whole thing is pretty much magic. In Rust, it's just another struct that the compiler treats in no special way. Getting familiar with the magic of Go channels is only good for working with Go channels, the knowledge is not applicable for any other part of the language nor other languages. Learning generics on the other hand gives you better understanding of numerous features in multiple languages.

Re: Notes on the Go2 Generics Draft

#113

Post by piano »

nemo1618 wrote: post #95
mort96 wrote: post #71

Earlier quoted context omitted.

I'm curious, what's a better solution for generics if you want some kind of container which doesn't need to care what type it contains? Is the better solution to just use the current C-style void* s everywhere and manually cast your objects to and from void* (or in Go's case, interface{}), leaving type safety to the programmer? Or is the argument that people shouldn't need to write containers, and all necessary conta…

I've been writing Go for five years and I've never had a pressing need to create my own generic container type. The built-in types -- arrays, slices, maps, and channels, or some composition of them -- have proved sufficient. When I do need a new type of container, it either ends up being specialized for a specific type, or it accepts generic types via interface. Like, I need a red-black tree for this one algorithm, b…

> But the way I see it, 95%+ of programs don't truly need generics.

Yes, they do. Pretty much 100% of programmers in statically-typed language need to use generic types/functions.

The "95%+" thing is just an observation that one typically needs to define type-parametrized structures of function very seldom. This is true, but it's in no way a good point against adding generics, because those remaining ~5% of cases are crucial for peaceful programming the other ~95% of times. That's why Go has built-in generic types, but as it's adoption grows, it's becomming clear they won't do any more...

> In fact, I think most people asking for "generics" would have their true needs met by adding a few more built-ins to the language.

You argued against magic and now you'd like to add some more of it to the language...

Re: Notes on the Go2 Generics Draft

#114

Post by sebe »

pjmlp wrote: post #84
giovannibajo1 wrote: post #77

Earlier quoted context omitted.

There’s precedent that Google’s brand doesn’t make people magically swallow programming languages without thinking: Dart. I think it’s disingenuous to reduce Go success to some Google marketing operation. I dislike Google as a brand in the way they design products and their weak privacy stance, but I love Go nonetheless.

Dart suffered from Google politics, trying to take over JavaScript, and then being dropped by Google's own teams (Chrome and Angular). Being rescued by AdWords team, and now having Flutter team as their last hope. Go hasn't suffered from such politics. Let's not forget that Go is a mix of Oberon-2 and Limbo, both a failure regarding market adoption, in spite of their technical qualities.

Some dart ramblings. Seems to me, that the Chrome team is responsible for Dart demise and its later flutter inspired resurgent.

Flutter was started by people in the chrome team, as an experimental project called sky.

With regards to making it possible to include the dart vm the oilpan project was started.

Oilpan, the replacement of reference counting in Blink, with a tracing garbage collector, this would have made it possible for dart vm to sit along side v8 in chrome.

Oilpan was started in 2013 and instead of taking months, it took years, I think it finally arrived in 2016. Here is a dart video from io 2013 announcing oilpan. https://youtu.be/huawCRlo9H4

Re: Notes on the Go2 Generics Draft

#115

Post by dunpeal »

Exuma wrote: post #111
dunpeal wrote: post #26

Earlier quoted context omitted.

In a static language, functions, classes, and types are often parametrized by other types. For example, with a function: imagine you wrote a `sum(array)` function. In Ruby that's not a problem, because array can contain any types, as long as they support the + operator (aka duck typing). Any function can also return any type of object. In a static language, however, an array that holds floats has a different type tha…

Awesome, so this makes sense. So I guess people are against it because they like the explicit simple nature of Go rather than some sort of abstraction magic?

I can't speak for all of them, but generics do tend to add a bunch of rules to a language, and make it more complex than before.

Re: Notes on the Go2 Generics Draft

#116

Post by cbolton »

Animats wrote: post #23

That's elaborate. More elaborate than expected for Go. I was expecting something more like explicit parameterized types. Go already has those - maps and channels are parameterized types. You just can't define new parameterized types. Extending Go to allow those would be a smaller step. That doesn't get you overloaded functions, though. The designers of this wanted the ability to define a new function F(T x) which wor…

It violates the rule "You should never have to tell the computer something it already knows."

Not really: the contract is an explicit list of requirements with API compatibility guarantees for future versions. The computer cannot guess that from the current implementation.

Post reply on HN