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

231–240 of 261 posts

Re: Why Generics?

#231

Post by imtringued »

agrajag wrote: post #200
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.

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.

In Haskell this happens every time you call a function with two or more arguments.

Re: Why Generics?

#232

Post by hajile »

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.

> OCaml structs are structurally typed.

You can read about Ocaml's nominal record typing in the [ReasonML docs](https://reasonml.github.io/docs/en/record) (it's more clear there IMO).

SML gets this right in my opinion. If I create a record `{foo = "abc", bar = 123}`, I can pass that record on to ANY function that needs a record that looks like {foo:string, bar:int} fields because it looks at the structure rather than the type of the record constructor.

Another nice property of the SML approach is that you don't need named arguments. Instead, pass a tuple with names (aka a record). One set of syntax rules covers both cases. I also rather like the ability to access record fields with the hash syntax (eg, `#foo myrecord`) when I don't want to destructure.

Re: Why Generics?

#233

Post by kragen »

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…

> 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]”.

This is basically how C++ was designed, and it turns out not to work very well; the [adjustments₁] for [feature₁] turn out to introduce not only unanticipated [problems₁] with [feature₁] itself but also new and previously unimagined [problems₂] with [feature₂]. So the Golang designers prefer to take a much more cautious approach than the Lumbergh approach you're suggesting. So far it seems to have worked out well — the language is not without its compromises, and it's substantially more complicated than it was at first, but it's a very reasonable compromise.

Re: Why Generics?

#234

Post by snazz »

mcguire wrote: post #187
snazz wrote: post #91

Earlier quoted context omitted.

I wonder if there's room for a language that is small, allows for nearly limitless abstraction, and still has great tooling. Go is (or, you could argue, was) small, and now has better tooling, but is just beginning to increase its ability to create abstractions. Common Lisp is large (only 200 pages fewer in its spec than C++, if I remember correctly), has unparalleled tooling (like the don't-unwind-the-stack debuggin…

Scheme?

I fleshed my comment out into a blog post yesterday, which got some interest[0] on Lobsters. It appears that modern Scheme is easier to write portably and an even nicer compromise than I had originally thought.

[0]: https://lobste.rs/s/ytuyya/perfect_language_why_go_still_isn...

Re: Why Generics?

#235

Post by majewsky »

btilly wrote: post #190
haolez wrote: post #139

Earlier quoted context omitted.

The one mentioned in the article. It's not a hack: it's a runtime equivalent that requires that your type implements some interface.

It is a hack. The article lists a whole series of things that are standard in other languages that you can't do in go. Here are some examples: Find smallest/largest element in slice Find average/standard deviation of slice Compute union/intersection of maps Find shortest path in node/edge graph Apply transformation function to slice/map, returning new slice/map And here are data structures that other languages have b…

> Multimaps, with multiple instances of a key

Isn't this just map[Key][]Value? The standard library uses these in several places, e.g. url.Values and http.Header, with assorted utility functions.

Re: Why Generics?

#236

Post by karmakaze »

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…

For my own benefit, I agree with this. I just want a more usable language now. Something like ad-hoc structural typing as in TypeScript with aliases seems close.

For the future of languages I appreciate the clean slate effort. Go has been about scoping out a use area sticking a leg there and coming up with something that works well there. At the same time I dont think there will be anything revolutionary, just something that seems simple and compact. I wish them great success and us a short wait.

Re: Why Generics?

#237

Post by weberc2 »

grumdan wrote: post #221
weberc2 wrote: post #196

Earlier quoted context omitted.

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.

Yeah, Rust is the best ML for the things I care about, but after 5 years of on-and-off use, I still haven't adapted to the borrow-checker and a GC is just fine for the applications I write. And learning curve is important too--I need to be able to onboard new developers quickly. Go simply offers the better tradeoffs today for my apps. If someone built a "Rust-lite"--Rust with Go's runtime or Go with Rust's type system (less its lifetimes and borrowing semantics--insofar as those are considered a part of its type system), that would be my primary app dev language. But it's looking like Go is going to get there first with its proposal for generics and hope for sum types.

Re: Why Generics?

#239

Post by Nevermindmine »

baby wrote: post #134
Nevermindmine wrote: post #109

Earlier quoted context omitted.

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

Try to read code that abuses generics you’ll see what GP means.

I can't write confusing code using just integers by abusing names to confuse you. You can write crappy code. Point?

Re: Why Generics?

#240

Post by ernst_klim »

hajile wrote: post #232
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.

> OCaml structs are structurally typed. You can read about Ocaml's nominal record typing in the [ReasonML docs]( https://reasonml.github.io/docs/en/record ) (it's more clear there IMO). SML gets this right in my opinion. If I create a record `{foo = "abc", bar = 123}`, I can pass that record on to ANY function that needs a record that looks like {foo:string, bar:int} fields because it looks at the structure rather th…

>You can read about Ocaml's nominal record typing in the [ReasonML docs](https://reasonml.github.io/docs/en/record) (it's more clear there IMO).

You are confusing records with structures, it seems. Structures exist in module language. Records are nominal in SML as well. Access functions for tuples and records are a dirty ugly hack build-in for convenience, they have nothing to do with structural typing, they are inferred in place.

OCaml has structural typed records, they are called objects.

   let obj = object method pi = 3.14; method name = "Pi" end
   val obj :
is structurally typed record.

> I can pass that record on to ANY function

No, you can't.

    #foo { foo = 42 }
works, but

    fun f x = #foo x
doesn't. It's an ugly hack, typing is still nominal. A hack, just like SML's arithmetic op overload.

Compare it to OCaml, which have proper structural typing for objects and raw polymorphism

    let f x = x#foo
    f :  -> 'a
Edit: sorry, indeed typing is structural since you can write `{x:typ} -> typ`.

Anyways OCaml have structural typed records and raw polymorphism and subtyping support for them.

> Another nice property of the SML approach is that you don't need named arguments. Instead, pass a tuple with names (aka a record).

What's your point? You can use records as arguments in OCaml as well.

Post reply on HN