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

Why Generics?

blog.golang.org

Post reply on HN
Print view View original

191–200 of 261 posts

Re: Why Generics?

#191

Post by mcguire »

mitchellh wrote: post #66

It might be fun to share my viewpoint from an angle that's probably fairly unique. I've started a number of large, highly deployed Go projects: Terraform, Vault, Packer, Consul, Nomad, and numerous libraries and other things. I started a company that employs hundreds of full time Go developers. Go has been one of our primary languages since Go 1.0 (and I used it prior to that). Let me start by saying that there are _…

"Having written these numerous large, complex systems, I believe there are less than 10 instances where generics would've been super helpful."

If you wrote Python, you'd probably be saying, "there are less than 10 instances where type declarations..."; you could make similar statements about concurrency or a host of other features.

And you'd be more or less right.

Here's the deal: a language with generics is very different from a language without generics. You write different code, you solve problems differently, you think differently. This is why they should have had generics in version 1.0 and why adding them later seems so underwhelming to some of us. Generics have a lot of advantages, but you are going to be looking at a bizarre mixture of programming styles for a long time.

Re: Why Generics?

#192

Post by mcguire »

merlincorey wrote: post #153

As a functional leaning programmer, I think it's striking that the resulting draft is essentially a curried function whose first parameter is the type! func Reverse (type Element) (s []Element) { first := 0 last := len(s) - 1 for first This is later called like: Reverse(int)(s) Which if this were a curried function, would also be callable like: Reverse(int, s) Now I wonder if facilities for currying functions might b…

I hate to tell you, but you're on your way to dependent types.

Re: Why Generics?

#193

Post by bushin »

Nevermindmine wrote: post #109
Vendan wrote: post #47

Earlier quoted context omitted.

Chiming in as a fervent Go dev that's also a huge fan of generics: Generics are awesome, but always seem to add a ton of complexity. Everyone starts with just "oh, `func Reverse(slice []T)` is so obvious" kind of thing, but that's like saying `fmt.Println("Hello World")` is simple. It's simple cause you are doing a simple thing. That said, I do want generics to come to Go, just... with an emphasis on what Go is, not…

> Generics are awesome, but always seem to add a ton of complexity The team I work in use generics all the time and I'm not sure what complexity you are referring to. Care to elaborate? Is it some edge cases or are you talking about from a compiler perspective or something else? To me, not having generics is like saying let's skip handling bools and just store them in strings as "true" or "false". It's such a weird t…

"protocol can only be used as a generic constraint because it has Self or associated type requirements"

Re: Why Generics?

#194

Post by weberc2 »

enneff wrote: post #119
weberc2 wrote: post #94

Earlier quoted context omitted.

Agreed, specifically it creates ambiguities in parsing (for computers but worse: for humans). Given Foo(x), you can’t tell if it’s a function call or a generic type without knowing what x refers to. You need context from afar to disambiguate.

You can tell if it’s a function call or a generic type based on where it is used; the local context. Function calls are either statements or expressions. Types appear in declarations.

Reverse(x)(y)

Is that a function that returns a function or a generic Reverse function specialized over type x, invoked with argument y?

Re: Why Generics?

#195

Post by mcguire »

sp527 wrote: post #149

This process took way too long. I've already moved back to Python3 and am super happy with it. The truth is most software doesn't really need the performance benefit Golang offers and you can code up something in Python in at least half to a third of the time it would take in Golang. Aside from agility, there's one other benefit that imo matters a lot: reduced LoC. If there's one thing I've learned in my career, it's…

Can I sell you some Pony: https://www.ponylang.io/

Re: Why Generics?

#196

Post by weberc2 »

hajile wrote: post #175
grumdan wrote: post #104

Earlier quoted context omitted.

> because all existing implementations are bad I'm also not sure why in OOP-land, generics are this crazy experimental weird feature, when in functional languages, people figured out how to implement parametric polymorphism (the original term for generics) in quite reasonable ways. I get that subtyping adds some complexity, but overall I don't understand why such a basic way to build abstractions is so controversial…

If go ever showed people the awesomeness of StandardML or Ocaml/ReasonML (and their amazing type systems), I think the language would lose a lot of users.

This is confusingly phrased. Do you mean "If Go people were ever shown ... ML"? I would totally drop Go for an ML language if any of them had a sane syntax, usable build tooling (including native, static compilation by default), and a (single) decent standard library.

A super awesome type system is worthless without the basic requirements for scalable software development.

Re: Why Generics?

#197

Post by mcguire »

dimgl wrote: post #7
mlevental wrote: post #4

why are people obsessed with simplicity? there's a quotation my Einstein that I like to keep in mind: "make things as simple as they can be but no simpler". the implication being that if you make things too simple then you actually break things. lack of generics makes for software that's actually more complex than it needs to be. Take for example Swift: lots of complex features (protocols, all manner of functional tr…

I have yet to find one practical application for generics in the apps I've built in Go.

If you've never used a screwdriver, all you can say about screws is that they make crappy nails.

Re: Why Generics?

#198

Post by weberc2 »

helper wrote: post #189
shhsshs wrote: post #159

Earlier quoted context omitted.

a := Bar(baz)(buzz) Is Bar a `func(some) func(thing) other` or is it a `func(type T)(some) other`? You need to know what “baz” is to be able to tell.

Normally you wouldn't write that since the compiler will be able to infer the baz type based on buzz (assuming this is a call to a generic function).

That's a fair point, but there are still times when being explicit is useful or even required, and it doesn't hurt to use syntax that disambiguates easily.

Re: Why Generics?

#199

Post by enneff »

weberc2 wrote: post #194
enneff wrote: post #119

Earlier quoted context omitted.

You can tell if it’s a function call or a generic type based on where it is used; the local context. Function calls are either statements or expressions. Types appear in declarations.

Reverse(x)(y) Is that a function that returns a function or a generic Reverse function specialized over type x, invoked with argument y?

When a function returns a function, you rarely just call it immediately in Go. But even if that were common (and maybe it would become common with generics? I'd have to think that through) it is uncommon to have a type name as unrecognizable as 'x'.

I've always been a big advocate for unambiguous, clear code, especially in Go, but I don't see a big potential for confusion here.

Re: Why Generics?

#200

Post by agrajag »

shhsshs wrote: post #159
enneff wrote: post #119

Earlier quoted context omitted.

You can tell if it’s a function call or a generic type based on where it is used; the local context. Function calls are either statements or expressions. Types appear in declarations.

a := Bar(baz)(buzz) Is Bar a `func(some) func(thing) other` or is it a `func(type T)(some) other`? You need to know what “baz” is to be able to tell.

Yeah, it's ambiguous, but be realistic: how often are you calling a function with a function return just to invoke that directly?

You usually won't see much of either sinice the type argument is only necessary when it can't be inferred.

Post reply on HN