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

111–120 of 305 posts

Re: Go generics are not bad

#111

Post by [deleted] »

throwaway894345 wrote: post #109
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?

[deleted]

Re: Go generics are not bad

#112

Post by throwaway894345 »

zamalek wrote: post #77
germandiago wrote: post #67

Earlier quoted context omitted.

really? Is Go that bad? Write a server that does communication or emulate select in Go in other languages. Go is really effective at writing things fast at the same time that it has value types and can scale not only in I/O but also in multi-core in a way that is easier than anything I saw before. I am a mainly C++ person but I must admit that the cost/investment ratio in Go is really good for writing server-side stu…

> Is Go that bad? I'm personally no fan of Go (mostly due to the ergonomics of the standard library), but all this about generics is throwing the baby out with the bathwater. Go has a fantastic generics design. > cost/investment ratio in Go is really good for writing server-side stuff. And this 100%.

I’m a big fan of Go, and I’ve never been bullish on generics, but I really don’t see what is good about this design. I’m really not interested in generics with a runtime penalty even if it makes binaries smaller. I also think the constraint system needs work, and there needs to be a mechanism for generic methods. It’s possible for Go to get all of these things, but the current form leaves a lot to be desired. Rust’s trait system is best in class as far as I can tell, and I’ve criticized Rust often in the past.

Re: Go generics are not bad

#113

Post by naikrovek »

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…

> start making a language from a sound theoretical foundation and then implement it

ADA may be up your alley. it was fully designed and specified before a single line was written.

Re: Go generics are not bad

#114

Post by Gibbon1 »

Quekid5 wrote: post #25
Thaxll wrote: post #15

Earlier quoted context omitted.

How can Go does it even worse that Java where generics implementation is the worse of all modern language with type erasure. Java is way worse than Go on that aspect.

Type erasure is interesting. It turns out that not doing type erasure (combined with instanceOf-like things, like pattern matches on type parameters) breaks parametricity. Parametricity is a very powerful reasoning tool. Of course, type erasure isn't the actual culprit in that case, but once you don't do it, it gets very tempting to allow pattern matching on type parameters...

I read an essay by a CS post doc taking about type erasure. He said getting to the point where you can do type erasure is golden. And then everyone makes the mistake of actually implementing type erasure. He said you consign yourself to no tooling and terrible debugging.

Re: Go generics are not bad

#115

Post by kaba0 »

Thaxll wrote: post #15
saagarjha wrote: post #11

This is like the most cherry-picked example that could've been chosen. Java can't do this because the primitive types are not objects. Mentioning the performance of this is hilarious because 1. it's Daniel Lemire, he should know better and 2. the performance of pretty much every other thing that uses generics is terrible because of gcshapes being passed everywhere and 3. Java literally has a JIT to make generics fast…

How can Go does it even worse that Java where generics implementation is the worse of all modern language with type erasure. Java is way worse than Go on that aspect.

You do realize that type erasure is the common way of dealing with (generic) types? Haskell also does type erasure, as well as basically every language outside C#.

Re: Go generics are not bad

#116

Post by yawaramin »

sangnoir wrote: post #107
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.

Well, let's look at the case of Facebook Messenger's webapp, which is written in BuckleScript (now ReScript), a language based on OCaml. That's about as solid as you can get academically. Here's what they said:[1]

> Full rebuild of the Reason part of the codebase is ~2s (a few hundreds of files), incremental build (the norm) is > Messenger used to receive bugs reports on a daily basis; since the introduction of Reason, there have been a total of 10 bugs (that's during the whole year, not per week)! *

> Most of the messenger core team's new features are now developed in Reason. Dozens of massive refactors while iterating on ReasonReact. Refactoring speed went from days to hours to dozens of minutes. I don't think we've caused more than a few bugs during the process (counted toward the total number of bugs).

In a high-velocity codebase, modularity is the name of the game. And you will be hard-pressed to find languages outside the ML family which are that good at modularity. OCaml is just about the only industrial-ready language in this space.

[1] https://reasonml.github.io/blog/2017/09/08/messenger-50-reas...

Re: Go generics are not bad

#117

Post by kaba0 »

zamalek wrote: post #24
saagarjha wrote: post #11

This is like the most cherry-picked example that could've been chosen. Java can't do this because the primitive types are not objects. Mentioning the performance of this is hilarious because 1. it's Daniel Lemire, he should know better and 2. the performance of pretty much every other thing that uses generics is terrible because of gcshapes being passed everywhere and 3. Java literally has a JIT to make generics fast…

> Java can't do this because the primitive types are not objects. So this excuses the awful Java genetic how? "It smells like sewage in the basement because the basement is full of sewage." In addition, generics over primitive/stack/value types (including mathematical operators) is working just fine in the latest iteration of C#.

Some more context would be appreciated on why you think that Java generics are awful?

Re: Go generics are not bad

#118

Post by 0xmarcin »

throwaway234232 wrote: post #49

I think in Java, you would need to do a type-class approach. interface Numeric { T zero(); T add(T a, T b); } static T sum(Numeric n, T[] v) { T summer = n.zero(); for (int k = 0; k

This will work, but will have poor performance due to the way Java generics are implemented. You could use your function with `Integer[]` or `Long[]` arrays but not with `int[]` or `long[]`. `Integer` being a wrapper class around `int` is a regular Java object accessible via reference, hence slow and memory-inefficient.

On the other hand C# offers "real" generics and you can use almost exactly the code that you wrote (generic syntax is slightly different).

Re: Go generics are not bad

#119

Post by munificent »

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…

Both industry and academia are making languages according to their own incentives and criteria.

Industry language designers are trying to make their users more productive enough to justify the cost to design and build the language. An industry language that doesn't have enough users and doesn't make those users' lives better enough to offset the salaries of the language team is a losing proposition and a bad language.

Academics are trying to publish papers on novel ideas. A language that cured cancer would be considered a bad language if someone had already designed a language that cured cancer the prior year.

These incentive structures a somewhat opposed: the easiest way to make a language easier to adopt is to make it more familiar and less novel. But they are somewhat aligned as well. A language with no new ideas can't be any better than the languages before it.

So there is a natural diffusion process where academia explores the frontier of weird language ideas. Many don't pan out. All of them are weird and unapproachable when they first appear. The ideas worth keeping stick around. Eventually an industry language will add a dollop of those novel ideas and surround them with a familiar framework so that users can actually absorb and use the thing.

Re: Go generics are not bad

#120

Post by erik_seaberg »

Beltalowda wrote: post #72
google234123 wrote: post #59

Earlier quoted context omitted.

Not sure how 3.5 follows.

And 1. is demonstrably false as has been stated a million times already.

If they had launched without supporting odd numbers, nobody would be saying “they always intended to add that later” in their defense.
Post reply on HN