Generics enabled by default in Go tip • Hacker News Board

Re: Generics enabled by default in Go tip

#271

Post by masklinn » Sat, Aug 21, 2021, 2:02 PM UTC

erik_seaberg wrote: post #242

masklinn wrote: post #234

Earlier quoted context omitted.

> Unfortunately it looks like reflection can’t look up functions in a module at all, which is surprisingly broken. The more time passes the more I think ubiquitous reflection in statically typed languages is what's broken (and a reflection (heh) of deep limitations of the language). So while I could understand having issues with generics breaking existing reflection code (which doesn't seem to be the case), I'm not g…

What good are top-level functions if they’re unreachable from any script interpreter or management RPC server or other languages’ FFI?

I fail to see what any of this has to do with reflection.

> any script interpreter

What are you even talking about.

> or management RPC server

I would very much expect RPC endpoints to be opted in explicitly and statically.

> or other languages’ FFI?

I fail to see why Go-level reflection would be involved in that in any capacity.

> What good are top-level functions

You can call them? From your go code?

Are you saying rust or C can't be because they don't have reflection? That's a strange position.

Re: Generics enabled by default in Go tip

#272

Post by masklinn » Sat, Aug 21, 2021, 2:06 PM UTC

ibraheemdev wrote: post #265

toolslive wrote: post #209

Earlier quoted context omitted.

Go has generics. They're just not (yet) available for you. So to some it feels like a Tantalus punishment.

If you're referring to map[K]V, that's not true. Go doesn't have generics, it uses some compiler magic under the hood specifically for the map type [0]. The generics proposal is being implemented from the ground up. [0]: https://dave.cheney.net/2018/05/29/how-the-go-runtime-implem...

> If you're referring to map[K]V, that's not true. Go doesn't have generics, it uses some compiler magic under the hood specifically for the map type [0].

They're not generic (aka userland) generics, but they're still generics: parametric types, and functions able to work on them generically (you don't have a separate `append` function for every type you might put in a slice).

> The generics proposal is being implemented from the ground up.

Of course it is, the builtins are ad-hoc and half-assed. That doesn't mean they ain't a thing.

Re: Generics enabled by default in Go tip

#273

Post by durbatuluk » Sat, Aug 21, 2021, 2:09 PM UTC

chana_masala wrote: post #211

durbatuluk wrote: post #40

If you want all features of language X (I doubt we will stop at generics) use language X. Stop trying to make all languages the same. I work with programmers from OO background (java) and they can't even grasp the utility of functions as value or closures. Every damn "service" has an interface/generated mock and anemic model. They're desperate waiting for generics for go to "complete". I fear the influx of OO program…

OO !== Generics, at all

I didn't say they're the same. I'm saying people coming from OO complain all the time of lack of generics, inheritance (besides composition) etc.

I teach basic go at my job to help people wanting to migrate, they start the go journey thinking go will do "less" because we don't have all features as their main language. Which reminds me of this phrase:

> 'You cannot reduce the complexity of your problem by increasing the complexity of your language.'

Re: Generics enabled by default in Go tip

#274

Post by masklinn » Sat, Aug 21, 2021, 2:17 PM UTC

SideburnsOfDoom wrote: post #219

tedunangst wrote: post #34

Every HN thread about go: go is useless because it lacks generics. Go adds generics. HN thread: I don't want this. Good case study about the people drawn to comment on a topic.

> Go adds generics. HN thread: I don't want this If generics are a good idea for a language, then it's better to add them in version 0.01 of the language and build up from there with generics as an intrinsic part of the language and standard libraries. No, I don't want _tacked on_ generics. Generics are not in 2021 a "bleeding edge" feature, that _might_ be useful later. They are established and proven in ways that t…

> Generics are not in 2021 a "bleeding edge" feature, that _might_ be useful later. They are established and proven in ways that they were not when Java v1 or C# v1 shipped - both added generics in later releases, with associated compromises.

Generics were hardly bleeding edge by 2002. Doesn't mean the average developer understood the point, but that's hardly a benchmark, and really most people have a hard time understanding what they have no experience with.

And work on .net generics had been going on since 1998, and by the release of 1.0, generics were going to land in 2.0. It simply wasn't done at that point: "Design and Implementation of Generics for the .NET Common Language Runtime" dates back to early 2001, but by late 2001 the spec was still incomplete and debated (https://docs.microsoft.com/en-gb/archive/blogs/dsyme/some-hi... used to have a link but it's dead).

Re: Generics enabled by default in Go tip

#275

Post by puddingforears » Sat, Aug 21, 2021, 2:31 PM UTC

snovv_crash wrote: post #191

puddingforears wrote: post #170

Earlier quoted context omitted.

They make a great stack, though. Cheap to use and easy to implement.

Use a deque at least and amortize the heap allocations...

With generics I could justify the extra engineering work to make such a deque!

Re: Generics enabled by default in Go tip

#276

Post by masklinn » Sat, Aug 21, 2021, 2:32 PM UTC

rustc wrote: post #179

silisili wrote: post #145

Earlier quoted context omitted.

I don't mean to be negative only, and appreciate your reply. But I know what happens in real codebases. Before long, scammy tutorials pop up showing Go as an essentially dynamic language, and that's what bootcampers write. As of today, they are forced to write simple, boring code. I never mind a carefully added thing, for carefully thought of situations, as this probably was. The problem is that I see the abuse from…

> Before long, scammy tutorials pop up showing Go as an essentially dynamic language Sorry are you saying adding generics to Go makes Go closer to dynamic languages? Shouldn't that be the opposite? > I knew a person who insisted on a lot of things when working in a Go code base...one of which was mixed typed tuples. It was ugly, awful code of interfaces all the way down. It's ugly and Go let you know that. A voice of…

Go doesn't even have tuples, where would those even come from?

Re: Generics enabled by default in Go tip

#277

Post by masklinn » Sat, Aug 21, 2021, 2:33 PM UTC

Gibbon1 wrote: post #175

rustc wrote: post #86

Earlier quoted context omitted.

Are generics really considered as "esoteric comp sci topics"?

I needed to use C# for some project. Used generics without actually being aware what they were. Helps that C# implements generics without type erasure.

> Helps that C# implements generics without type erasure.

For about 95% of "using generics" that makes no difference, and you'd have had no more issue in Java.

That aside, Go is implementing reified generics (there is no real backwards compatibility concern as the "core" collections are already ad-hoc parametric types, and the rest is not a great loss).

Java had a lot more legacy code using a much higher number of standard but not-generic-at-all collections, I'd bet there were also concerns around the forward compatibility of legacy reflection code, and they'd probably considered a lot of collections-related goodwill spent with Java 1.2's Collections Framework and the deprecation of the limited set of original collections.

Re: Generics enabled by default in Go tip

#278

Post by SideburnsOfDoom » Sat, Aug 21, 2021, 2:39 PM UTC

masklinn wrote: post #274

SideburnsOfDoom wrote: post #219

Earlier quoted context omitted.

> Go adds generics. HN thread: I don't want this If generics are a good idea for a language, then it's better to add them in version 0.01 of the language and build up from there with generics as an intrinsic part of the language and standard libraries. No, I don't want _tacked on_ generics. Generics are not in 2021 a "bleeding edge" feature, that _might_ be useful later. They are established and proven in ways that t…

> Generics are not in 2021 a "bleeding edge" feature, that _might_ be useful later. They are established and proven in ways that they were not when Java v1 or C# v1 shipped - both added generics in later releases, with associated compromises. Generics were hardly bleeding edge by 2002. Doesn't mean the average developer understood the point, but that's hardly a benchmark, and really most people have a hard time under…

> Generics were hardly bleeding edge by 2002.

yes and no. It's clear from the history at the time that they were not a proven, obvious win.

> Generics for .NET and C# in their current form almost didn't happen

> being told by product team members that "generics is for academics only"

https://docs.microsoft.com/en-gb/archive/blogs/dsyme/netc-ge...

My argument is that this particular question has, since then, been settled in favour of generics, outside of academia, and in mainstream languages such as c#. Generics are now "established and proven" in ways that they were not then.

Hindsight: https://twitter.com/matthewwarren/status/920667986108846080

C# is IMHO mainstream, deliberately so. Features in it typically come from other languages. It is a "populariser" of promising programming language ideas for mainstream productivity, not a testbed.

> Doesn't mean the average developer understood the point

at the time as a junior dev, I got the point inside a minute: I was already in the habit of when declaring Customer class adding a strongly typed CustomerList class, for their address, an Addess class, followed by the AddressList, and Orders needs OrderList and OrderItemList. Reducing this repetitive "plug in the type" code to List etc was such a clear win.

Re: Generics enabled by default in Go tip

#279

Post by masklinn » Sat, Aug 21, 2021, 2:44 PM UTC

4ad wrote: post #259

continuational wrote: post #202

Earlier quoted context omitted.

This seems somewhat strange to me (and I don't just mean hard on the eyes): func (o Option[T]) Unwrap() T How does Go know that T is a type parameter here, and not a concrete type named T?

Because it can only be a type parameter. There is no specialization. (TBH I think that's a mistake because if prevents a solution to the Expression Problem.)

I don't think that's an issue, specialisation is a real edge case (e.g. Rust still doesn't have userland specialisation despite having always had generics) and it's easy to make mistakes with it (e.g. C++'s `vector` though it's probably less of an issue if you can only specialise functions).

That methods can't be parametric is still annoying though because it means utility methods can't have generic parameters unrelated to the subject e.g. can't define a map or fold method, because there's nowhere to put the output type, it has to be a free function instead.

But it's not like adding the generic spec thing between the subject and the method name would be a big issue so that can always be added later after the MVP has been exercised a bit.

A related "missing bit" which I'd guess they want more feedback before adding would be "conditional methods" aka methods which are only present if the generic types of the subject have a specific property (e.g. in Rust it's common for the generic container to be unbounded but for functions to be bounded on specific traits).

Re: Generics enabled by default in Go tip

#280

Post by masklinn » Sat, Aug 21, 2021, 2:55 PM UTC

4ad wrote: post #261

masklinn wrote: post #147

Earlier quoted context omitted.

> As for generics, Go’s lack of function overloading and arg default values is really interesting. It ensures that a function is always easily found as it’s the only thing in the module with that name. I’ll be curious to see if generics are easier to follow without function overloading. There are already a number of langages with generics and without overloading (or defaults). Haskell, ocaml, rust, …

True of OCaml and Rust (and many others), but Haskell certainly has overloaded functions through type classes. In fact, once OCaml gets implicit modules, this won't be true anymore of OCaml either.

> True of OCaml and Rust (and many others), but Haskell certainly has overloaded functions through type classes.

That's no more overloading than Rust has through traits.