Expectations for generics in Go 1.18 • Hacker News Board

Re: Expectations for generics in Go 1.18

#121

Post by Athas » Thu, Oct 28, 2021, 8:59 AM UTC

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)

This is probably less readable than it has to be due to the lack of whitespace. I don't know the language (Scala?), but I don't think it's too hard to work it out. First, the '[F[_], A, B]' part are type parameters, where I assume the 'F[_]' part is just a bad notation for a type of kind '* -> *' (i.e. a higher-ranked type). The next value parameter has type 'Option[A]', and after that we have 'A => F[B]'. This confirms my suspicion that 'F' is a higher-ranked type - and probably a functor or something. The 'f' parameter is a function for converting a value of type 'A' into a value of type 'F[b]', which looks like it's tranforming a value and putting it into a functor or something. The final '(implicit F: Applicative[F])' hints at deep problems in the language, but I think it basically just says something like 'the higher-rank type F must implement the trait/typeclass/whatever Applicative'.

That's the type. The expression makes little sense to me, but I suspect you removed a bunch of dots and maybe some parens, and it should actually look like this:

          fa.map (a => F.map(f(a))(Some(_): Option[B])).getOrElse(F.point(None))

So this function essentially just operates on an option value inside of some functorial context. This seems like a building block function that you might use often, but probably not write very frequently.

(If you didn't remove anything, then I suppose this language has infix 'map' and 'getOrElse' operators. I think that's bad, but it's not related to the type system.)

Re: Expectations for generics in Go 1.18

#122

Post by aitchnyu » Thu, Oct 28, 2021, 9:00 AM UTC

throwaway894345 wrote: post #39

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_...

I love the reply: “c++ allows zero width spaces in variable names. where’s your god now?”

I once read a comment like "Gives a new meaning to the term native code".

Re: Expectations for generics in Go 1.18

#123

Post by Traubenfuchs » Thu, Oct 28, 2021, 9:02 AM UTC

Cthulhu_ wrote: post #110

iamcreasy wrote: post #106

Earlier quoted context omitted.

I suppose there are many examples like this. Once I've copied a piece of code from SO but IntellijIDEA was warning me that the semicolon at the end of the line is not correct. Upon further investigation(I think IntelljIDEA reported Unicode value) I've found out that the 'semicolon' I copied is a Greek character that looks exactly like semicolon. I wonder how people on vim/emacs deal with situation like this.

It's similar when online editors try to be clever and replace a straight " with a fancy one (like in Word), really annoying.

I believe they prefer to be called „smart quotes“, honey.

Re: Expectations for generics in Go 1.18

#124

Post by gpderetta » Thu, Oct 28, 2021, 9:06 AM UTC

Cthulhu_ wrote: post #114

EdwardDiego wrote: post #105

Earlier quoted context omitted.

I understand and agree, I've run many a Java project that used codegen to emit Protobuf/Avro IDLs as types. But Go having actual generics, and accordingly removing some need for codegen, is not a bad thing at all.

No, I do believe Go will be improved if it allows library maintainers to implement some things like new collection types and utilities using generics. I for one won't be using more advanced functional coding though, it's a lot more difficult to read / parse and the language is not designed with functional programming in mind. I'm sure people are already working on a functional programming library so you can do map /…

Strongly agree. Some people like to be on this endless treadmill of cutting edge features, like in this case parametric polymorphism but I refuse to be dragged in. They just make the code more complex with no benefit.

Next thing you know they will try to force me into structured programming (I'm sure there are people already working on do...while). They can pry goto from my dead cold hands.

Re: Expectations for generics in Go 1.18

#125

Post by cerved » Thu, Oct 28, 2021, 9:11 AM UTC

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)

Transform fa using f, collecting the results as an option

Re: Expectations for generics in Go 1.18

#126

Post by dvdkon » Thu, Oct 28, 2021, 9:20 AM UTC

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)

This function is certainly hairy, but its use in the codebase might very well be intuitive and simplify code that would otherwise be way less expressive. I personally think it can be worth it.

Re: Expectations for generics in Go 1.18

#127

Post by Zababa » Thu, Oct 28, 2021, 9:25 AM UTC

mseepgood wrote: post #12

VHRanger wrote: post #9

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

GC Shape Stenciling, a hybrid of stenciling and dictionaries: https://go.googlesource.com/proposal/+/refs/heads/master/des...

How does that compare to other approaches for generics? I know that you can do monomorphisation, which usually increases the executable size and compilation time, and usually gives faster code, but I don't know about other approcahes.

Re: Expectations for generics in Go 1.18

#128

Post by Zababa » Thu, Oct 28, 2021, 9:31 AM UTC

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.

You can do that, but that's still not as good as direct experience with Go generics in Go code. Those wouldn't be best practices, they would be guidelines.

Re: Expectations for generics in Go 1.18

#129

Post by weego » Thu, Oct 28, 2021, 9:33 AM UTC

jandrese wrote: post #32

topspin wrote: post #20

Earlier quoted context omitted.

On the question of "what's this?": type ImmutableTreeListᐸElementTᐳ struct "If you look closely, those aren't angle brackets, they're characters from the Canadian Aboriginal Syllabics block, which are allowed in Go identifiers. From Go's perspective, that's just one long identifier." Simultaneously amusing and disturbing. Is there an award for which one might nominate this person?

That's the kind of thing you see in a comment and then back slowly out of the room, never breaking eye contact with the code until you are far enough away to turn tail and run. At the very least they could have used the cute Japanese 「quotation marks」 to avoid confusion.

This is the person you need. Be assured that they were the person willing to log into the live prod server to fix that script that was killing your startups app at 2am on a Friday night in 2007 when everyone else was too gun-shy.

Re: Expectations for generics in Go 1.18

#130

Post by _hzrk » Thu, Oct 28, 2021, 9:46 AM UTC

buzer wrote: post #103

sph wrote: post #92

Earlier quoted context omitted.

Niche in your niche perhaps, but there's a lot of code in the wild written in Go. Hell, all the modern devops tools are written in Go (Docker, k8s & co.) Meanwhile, as a non Java programmer, I've never seen a Scala app. I know about R, but nothing on my PC is written in it. Agreed that PHP is massive in comparison to all of them.

> 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 time picking it up.