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

221–230 of 261 posts

Re: Why Generics?

#221

Post by grumdan »

weberc2 wrote: post #196
hajile wrote: post #175

Earlier quoted context omitted.

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.

I have found Rust to be a nice middle-ground for this. Sure, the borrow checker takes some getting used to, but it features an ML-style type system (though I still miss some extensions to Haskell's type system available in GHC), rock-solid tooling, and a comprehensive well-documented standard library. The high quality of third-party crates also surprised me. Whether the C-like syntax is sane is debatable though.

Re: Why Generics?

#222

Post by rndmio »

ernst_klim wrote: post #216
hajile wrote: post #206

Earlier quoted context omitted.

If StandardML had even a fraction of the money behind go, there would simply be no contest. Ocaml is billed as the pragmatic ML, but the syntax really sucks and nominally typed structs aren't nearly as good. They also have 3 competing standard libraries. Haskell is too ivory tower. Most devs simply can't be bothered. StandardML is that awesome middle. The language choices are pragmatic compared to haskell (mutable re…

>nominally typed structs aren't nearly as good OCaml structs are structurally typed. > They also have 3 competing standard libraries. There is only one standard library, stdlib.

You know what he meant, if you want functionality comparable to the Go stdlib you are going to have to choose between Core or Batteries, then for async do you choose Async or Lwt? And as said the build system (when you're used to Go) is poor. I like a lot of what OCaml offers, but there's a lot of friction.

Re: Why Generics?

#223

Post by ernst_klim »

rndmio wrote: post #222
ernst_klim wrote: post #216

Earlier quoted context omitted.

>nominally typed structs aren't nearly as good OCaml structs are structurally typed. > They also have 3 competing standard libraries. There is only one standard library, stdlib.

You know what he meant, if you want functionality comparable to the Go stdlib you are going to have to choose between Core or Batteries, then for async do you choose Async or Lwt? And as said the build system (when you're used to Go) is poor. I like a lot of what OCaml offers, but there's a lot of friction.

> if you want functionality comparable to the Go stdlib you are going to have to choose between Core or Batteries

He is talking about SML here.

Care to elaborate, what Go has to do with Core or Batteries? Both are mostly container libraries, and you don't need them since most of the useful staff is in stdlib.

Check revdeps in OCaml, nobody uses batteries, and nearly nobody safe JS uses Core.

XML parsers, Lwt, servers are in separate packages, which is the only and right thing to do.

>then for async do you choose Async or Lwt

Lwt, it's a non-question. Async is for JaneStreet only.

> And as said the build system (when you're used to Go) is poor.

Dune [1] is far superior to Go's build system. Extremely fast, composable, supporting packaging and os-dependent configurations, extremely easy to config. No abomination like "import github.com/package" or "//go:" in your code.

Go build system doesn't have even a fraction of nice features dune have. For example I could `dune utop ./path/to/my/libs` to build my libs and run a nice repl to test them.

Go doesn't even let you to configure your warnings precisely.

[1] https://dune.build/

Re: Why Generics?

#224

Post by saturn_vk »

weberc2 wrote: post #94
jknoepfler wrote: post #88

The decision to overload parentheses to express generic type is the only part of this spec I find nauseating. It doesn't scan well, and doesn't have a precedent in any major generic implementation I'm aware of. <, [, @-annotation... I don't care. Just don't mush it into the function declaration with the same syntax that encloses parameter.

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.

Some helpful syntax highlighting will probably help with these cases, I should think.

Re: Why Generics?

#225

Post by saturn_vk »

haolez wrote: post #2

Personally, I prefer the current interfaces-based solution to generics. It's a little verbose, but keeps the language simple. However, I think that the people we should be listening most are the ones developing huge projects in Go, like Kubernetes. Would having generics with this new contracts thing make it easier to develop and maintain e.g. Kubernetes? I'm truly curious.

I take it you've never actually read the K8s source code.

Re: Why Generics?

#226

Post by saturn_vk »

baby wrote: post #135
theli0nheart wrote: post #106

Earlier quoted context omitted.

I don't think it's as clear-cut as you make it seem. Generics greatly reduce the amount of code we need to read in exchange an slight increase in abstraction. In my opinion, the tradeoff is worth it, especially given that Go already has abstractions that are more difficult to grok than generics, which, all things considered, aren't that hard to understand.

It’s not worth it because most people tend to abuse them.

do you have any statistics that can back your claim?

Re: Why Generics?

#228

Post by rowanG077 »

gizmo686 wrote: post #137
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…

Inheritance makes generics difficult. For instance, if A If you are just reading the array, you would want Array[A] This problem doesn't come up in ML style languages because they do not make use of inheritence.

It's not so difficult. It's just covariance and contravariance. C# has long solved this issue. https://docs.microsoft.com/en-us/dotnet/csharp/programming-g...

Re: Why Generics?

#229

Post by kragen »

grumdan wrote: post #104
iainmerrick wrote: post #74

Maybe this is unfair, but it’d be great if the Go devs could just say “generics will work similarly to [C# / Java / Swift / D / whatever], except that we’ll address [problems] with [adjustments]”. Rather than going through this whole rigmarole of resisting adding generics too early because all existing implementations are bad, then slowly reinventing the wheel from scratch, then finally ending up with something prett…

> 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…

Golang doesn't have subtyping.

Re: Why Generics?

#230

Post by tgb »

cousin_it wrote: post #208
gizmo686 wrote: post #137

Earlier quoted context omitted.

Inheritance makes generics difficult. For instance, if A If you are just reading the array, you would want Array[A] This problem doesn't come up in ML style languages because they do not make use of inheritence.

That seems like a problem with inheritance + mutability, not inheritance on its own. After all, if B is a subtype of A, then we can make List[B] a subtype of List[A] as long as lists are immutable. Appending an A to List[B] returns List[A], what's the problem? :-) In fact some ML style languages (like OCaml) do have inheritance and it works fine with generics. Some generic types (like lists) will be covariant, others…

The same problem happens with immutable types. Does a function of type Int -> A extend a function type Int -> B? How about A -> Int extending B -> Int? The answers to these are opposite.
Post reply on HN