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

Go generics are not bad

lemire.me

Post reply on HN
Print view View original

101–110 of 305 posts

Re: Go generics are not bad

#101

Post by cookiengineer »

What I still don't understand is why golang has exceptions for "language constructs" like make() and append()... while those are unimplementable in golang.

It's pretty annoying that golang embraces static and functional patterns in its core, but it doesn't even have map/filter/reduce/forEach as generic implementations for all data types.

The lack of a "new" keyword and default values for struct's property syntax is also pretty annoying. Let alone the "hack" with annotations for decoding/encoding everywhere, just so that you can use reflect API in the encoder implementations.

For loop fatigue in golang makes it so unreadable in practice, and leads everybody to offloading manipulation of arrays/slices to helper methods, just to have the for loop there.

The library that fixes this as good as possible with generics is the "lo" library (inspired by lodash) [1]. It's worth taking a look at it if you're curious how to implement it for your structs.

[1] https://github.com/samber/lo

Re: Go generics are not bad

#102

Post by Cobord »

VirusNewbie wrote: post #89
rachitnigam wrote: post #38

Earlier quoted context omitted.

Not quite. This also has the type ‘a -> ‘a: def nitpick(x): throw “foo”

that's not a function (in the pedantic sense). technically a partial function, or you could say that every function is really of the type A -> Exception \/ A

But you should not be writing functions that make you think about the fact that Hask is not really a category.

Re: Go generics are not bad

#103

Post by Cobord »

levoea wrote: post #81
lma21 wrote: post #8

It's been a while since i've went through any Java code. Why wouldn't the Java code sample compile?

you can't do `T summer = 0`, nor `summer += v[k]` as there is no arbitrary sum operation for Number (e.g a method `Number add(Number);` or ` T add(T t);`). though this can be solved either with types, as mentioned in another comment ( https://news.ycombinator.com/item?id=32029871 ), or simply by providing the sum operation: static T sum(T[] v, BinaryOperator adder) { T summer = v[0]; for (int i = 1; i x + y);

{}

Re: Go generics are not bad

#104

Post by orangecat »

danielscrubs wrote: post #87

Either you start making a language from a sound theoretical foundation and then implement it (Koka springs to mind) or you implement a language from some syntactic gripes and then try to find the theoretical foundation later… Go was impressive in the practical sense (compiler speed, channels in std and good tooling) but a shit show otherwise. I’ve completely lost any confidence that FANG will be able to make some gre…

I’ve completely lost any confidence that FANG will be able to make some great language because they always take the easy way (makes more business sense, see Dart).

I've found Dart to be perfectly adequate. Like Go it doesn't try to be overly clever; unlike Go it doesn't consider verbosity to be a feature, and believes you're capable of using advanced techniques like ternary expressions responsibly.

Re: Go generics are not bad

#105

Post by throwaway894345 »

danielscrubs wrote: post #87

Either you start making a language from a sound theoretical foundation and then implement it (Koka springs to mind) or you implement a language from some syntactic gripes and then try to find the theoretical foundation later… Go was impressive in the practical sense (compiler speed, channels in std and good tooling) but a shit show otherwise. I’ve completely lost any confidence that FANG will be able to make some gre…

I’m pretty sure Go’s maintainers were aiming for “mere” practical success, as opposed to some theoretical success that only academic languages succeed at.

Re: Go generics are not bad

#106

Post by EdwardDiego »

levoea wrote: post #81
lma21 wrote: post #8

It's been a while since i've went through any Java code. Why wouldn't the Java code sample compile?

you can't do `T summer = 0`, nor `summer += v[k]` as there is no arbitrary sum operation for Number (e.g a method `Number add(Number);` or ` T add(T t);`). though this can be solved either with types, as mentioned in another comment ( https://news.ycombinator.com/item?id=32029871 ), or simply by providing the sum operation: static T sum(T[] v, BinaryOperator adder) { T summer = v[0]; for (int i = 1; i x + y);

Bingo. You could use the longValue() or doubleValue() on Number to do math on if you insisted.

Re: Go generics are not bad

#107

Post by sangnoir »

danielscrubs wrote: post #87

Either you start making a language from a sound theoretical foundation and then implement it (Koka springs to mind) or you implement a language from some syntactic gripes and then try to find the theoretical foundation later… Go was impressive in the practical sense (compiler speed, channels in std and good tooling) but a shit show otherwise. I’ve completely lost any confidence that FANG will be able to make some gre…

> Academia on the other hand will make great languages that never reaches critical mass

Interesting choice of words: my guess is that the great languages Academia cook-up scale poorly on code bases which receive tens of updates per day (let alone hundreds or thousands). There's usually a huge difference between industrial tools and artisanal ones.

Re: Go generics are not bad

#108

Post by truffdog »

danielscrubs wrote: post #87

Either you start making a language from a sound theoretical foundation and then implement it (Koka springs to mind) or you implement a language from some syntactic gripes and then try to find the theoretical foundation later… Go was impressive in the practical sense (compiler speed, channels in std and good tooling) but a shit show otherwise. I’ve completely lost any confidence that FANG will be able to make some gre…

Ian Lance Taylor worked on generics for like a decade, and the final design was heavily based on the Featherweight Go paper, which had formal proofs of the design given a simplified version of the go language. This is a very odd complaint around this feature.

Re: Go generics are not bad

#109

Post by throwaway894345 »

cookiengineer wrote: post #101

What I still don't understand is why golang has exceptions for "language constructs" like make() and append()... while those are unimplementable in golang. It's pretty annoying that golang embraces static and functional patterns in its core, but it doesn't even have map/filter/reduce/forEach as generic implementations for all data types. The lack of a "new" keyword and default values for struct's property syntax is a…

There’s a whole lot wrong about this comment, but the most obvious is the claim that Go lacks a new keyword. Firstly, Go has a new keyword and secondly who makes a big deal about whether or not a language has a new keyword?

Re: Go generics are not bad

#110

Post by tester756 »

danielscrubs wrote: post #87

Either you start making a language from a sound theoretical foundation and then implement it (Koka springs to mind) or you implement a language from some syntactic gripes and then try to find the theoretical foundation later… Go was impressive in the practical sense (compiler speed, channels in std and good tooling) but a shit show otherwise. I’ve completely lost any confidence that FANG will be able to make some gre…

It sounds like: one of those is constrained by reality, the other ain't
Post reply on HN