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

Expectations for generics in Go 1.18

groups.google.com

Post reply on HN
Print view View original

161–170 of 209 posts

Re: Expectations for generics in Go 1.18

#161

Post by adwn »

skybrian wrote: post #71
hota_mazi wrote: post #58

> Because we will not know what the best practices are for using generics, Well, you could... take a look at languages created these past twenty years that support generics, learn lessons from that, and see how these lessons could apply to Go. But well, the Go team is not exactly known for paying much attention to the state of programming language theory, so I guess that's out.

Given that every language is different, this is basically reasoning by analogy. Sometimes analogies are useful for explaining things, but they're not a reliable way of determining what will definitely work. Reasoning by analogy in a sneering way doesn't make it work better.

Programming languages differ, yes, but not so much that they face completely different design decisions. Also, it's not "reasoning by analogy", it's learning from others.

In fact, why stop at generics? Why not go back and question structured programming? Or strong typing? Because structured programming and strong typing has proven to be extremely useful. Same as generics in statically typed languages.

Re: Expectations for generics in Go 1.18

#162

Post by Joker_vD »

Kranar wrote: post #14
VHRanger wrote: post #9

How are they implemented? Compile time? With template expansion like D and C++?

Yes, which I find unfortunate but I can respect that approach as it's likely the simplest way of implementing it and Go does want to avoid heavy abstraction in its type system. The downside is you can't do something like have a function pointer to the generic itself or specify generic members of a dyn trait/interface or otherwise treat the generic as a first class value (although you can treat specific instantiations…

C# mostly gets away with it because it has JIT support for it; in the end you still need to generate code for every data-size it's used with. Obviously, if all data are passed by reference you'd only need to generate code for the size of the pointer.

Even in C#, generics are sort-of second class:

    interface IMyLovelyADT { R Accept(IMyLovelyADTVisitor visitor); }
is not isomorphic to

    Func, R>
The interface is strictly more flexible because it's non-generic, see my comment at [0] for an actual code example (it's quite long) if you're interested, but the gist is "you need a non-generic wrapper interface IMyLovelyADT: it essentially does the same job as Haskell's forall, since generic types are not quite proper types in C#'s type system. Interestingly enough, upcoming Go 2's generics will not support this scenario: a method inside an interface will be able to use only the generic parameters that the interface itself declares."

[0] https://blog.ploeh.dk/2021/08/03/the-tennis-kata-revisited/

Re: Expectations for generics in Go 1.18

#163

Post by throwaway894345 »

hota_mazi wrote: post #58

> Because we will not know what the best practices are for using generics, Well, you could... take a look at languages created these past twenty years that support generics, learn lessons from that, and see how these lessons could apply to Go. But well, the Go team is not exactly known for paying much attention to the state of programming language theory, so I guess that's out.

I think Go is all the better for not rashly copying every idea from every programming language. The delay on generics is a small price to pay (if indeed a “price” at all) to have such a simple, ruggedly utilitarian language which also happens to be an absolute joy to use.

Re: Expectations for generics in Go 1.18

#164

Post by geodel »

kubb wrote: post #117

I'm glad that all the blog posts written by the apologetes and zealots, claiming that Go doesn't need generics and how they will actually be a detriment to the language, are archived somewhere in the wayback machines, so that they can't gaslight us into believing that they weren't just being silly for all this time.

You seem like those who remain obsessed with technology used in software than technology produced by software and can't see anything beyond it.

Re: Expectations for generics in Go 1.18

#165

Post by geodel »

EdwardDiego wrote: post #78
Benjammer wrote: post #17

Thank god, this guy[0] can finally cut over to native generics in his code. [0]: https://www.reddit.com/r/rust/comments/5penft/parallelizing_...

It's funny how codegen has become widespread in Golang to work around its deficiency.

What is funny about it? People have worked around deficiency of systems since forever in almost every field. Is it something you have never seen in real life?

Re: Expectations for generics in Go 1.18

#166

Post by eweise »

Cthulhu_ wrote: post #112
EdwardDiego wrote: post #78

Earlier quoted context omitted.

It's funny how codegen has become widespread in Golang to work around its deficiency.

I've come to prefer code quantity over code complexity. I mean, what the fuck is def traverseImpl[F[_], A, B](fa: Option[A])(f: A => F[B])(implicit F: Applicative[F]) = fa map (a => F.map(f(a))(Some(_): Option[B])) getOrElse F.point(None)

Its only hard to read because you don't know the language, otherwise, its fairly straightforward. Although the Applicative type would require some research. I would much rather use a language like this, that can create enough abstraction to enforce consistency throughout the codebase, rather than relying on boilerplate conventions. Just had a bug this week in Go where a previously defined "err" variable was re-used instead of creating yet another "err" variable, which caused the actual error never to get checked.

Re: Expectations for generics in Go 1.18

#167

Post by mseepgood »

mohanmcgeek wrote: post #149
mseepgood wrote: post #44

Earlier quoted context omitted.

But that will make error handling more verbose.

It'll make it unmanageable by hiding complexity. But more verbose? I'm not so sure.

Passing a single anonymous function is already more characters to type than if err != nil {}.

Re: Expectations for generics in Go 1.18

#168

Post by eweise »

_hzrk wrote: post #130
buzer wrote: post #103

Earlier quoted context omitted.

> Meanwhile, as a non Java programmer, I've never seen a Scala app. One widely known Scala application is Kafka. Some parts of it are in Java, but actual core is still mainly Scala afaik.

Yep, Kafka is probably the most popular one. I've heard that the team is looking forward to replace the remaining Scala code in the project with Java once pattern matching and co. land. Spark is another beast that was written in Scala. Many are reporting a high cost for compatibility. Nowadays, Scala community is all about Typelevel and ZIO, if you are not a category theory minded person, then you will have a hard ti…

Zio's library is not based on category theory. In fact, its trying to be the opposite.

Re: Expectations for generics in Go 1.18

#169

Post by masklinn »

Zababa wrote: post #148
masklinn wrote: post #140

Earlier quoted context omitted.

> That's a peculiar observation, it's like saying Rust's borrow checker is magical because it needs language-level support. I mean, that's the point. You can’t do borrow checking without language support (I think, at least not without a significantly more expressive type system) whereas Result is pretty much just a type, the features it uses are mostly non-exclusive, and those which are, are very much intended not to…

Don't you need sum types/sufficiently powerful enums for Result though? Which, in a way, makes it a language feature.

You’re confusing the chicken for the egg.

Sum types are a powerful language feature, but they’re also a general language feature, they don’t exist for the sole purpose of creating a Result type (and indeed a number of languages have had the former and lacked the latter).

Post reply on HN