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

151–160 of 305 posts

Re: Go generics are not bad

#151

Post by saagarjha »

yarg wrote: post #80
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 literally has a JIT to make generics fast ??? By the time it gets to the JIT, java generics have long since been erased. Java's generic classes run at the same speed as everything else, because there's no actual generics there. (Although I'd be very surprised if this doesn't change in the near future: https://openjdk.org/jeps/8261529 .)

I mean, they’re definitely not specialized and optimized before they hit the VM.

Re: Go generics are not bad

#152

Post by PhilippGille »

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…

> but it doesn't even have map/filter/reduce/forEach as generic implementations for all data types.

Generics landed in the latest stable version, 4 months ago. Before doing too many too early additions in the stdlib they want to observe how generics are used in the wild. I don't have the link handy, but it was mentioned in one of the generics discussions (issue on GitHub).

In these cases (another case was error wrapping prior Go 1.13) they start with experimental libraries in `golang.org/x/exp/...`, which they did here as well:

https://pkg.go.dev/golang.org/x/exp/slices

https://pkg.go.dev/golang.org/x/exp/maps

So while the stdlib doesn't have the functions you're looking for yet, this might change over time.

Re: Go generics are not bad

#153

Post by cyberpunk »

throwawaymaths wrote: post #98
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…

For the working programmer do you really want theoretical soundness? Though I have background in formal mathematics, when it comes to day to day, and what pays the bills, what I might need to operate in anger, I much much more care about legibility, debuggability, inspectability, easy to implement X (without a stdlib if need be), easy to test, no footguns, PL respects programmers (btw go fails most of these)

In my experience go is great at all of these, but then again I’m coming from c and then erlang…

Re: Go generics are not bad

#154

Post by fauigerzigerk »

maxbond wrote: post #88
nine_k wrote: post #71

Earlier quoted context omitted.

AFAICT this is basically how numbers work in Haskell, and I see no particular problems with them. You usually don't need too many number types of different nature.

Generics are great when you need them, but they will cut you badly if you misuse them. Generics are viral. When you make something generic, you often have to make the things that touch or contain it generic, too. Generics also create tight coupling. When you change the definition of a generic interface/class, you'll need to update your usage across the codebase. As opposed to, say, adding a new field to a class, that…

>Generics are viral. When you make something generic, you often have to make the things that touch or contain it generic, too

Do you have an example of that? Can't you always "typedef" any particular generic type as a concrete type and work with that going forward?

>Generics also create tight coupling. When you change the definition of a generic interface/class, you'll need to update your usage across the codebase. As opposed to, say, adding a new field to a class, that can be safely ignored anywhere it isn't used.

I don't see how this is different from concrete types or interfaces. If you change a public API you may have to update callers. If you change internals you don't have to update callers. Perhaps you can show an example to clarify what you mean.

I'm not a huge fan of generics myself, but I think your claim is that generics force you to introduce unnecessary dependencies. I don't see how this is true on a logical level. Dependencies between compiled artifacts are a different matter, but that's an implementation issue and I don't think it's what you're talking about.

Re: Go generics are not bad

#155

Post by tialaramex »

mcronce wrote: post #135
throwaway894345 wrote: post #105

Earlier quoted context omitted.

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.

What's the definition of "success" here? Popularity?

As I understand it, Google's rationale for Go is to enable them to hire a lot of say, good-but-not-great fresh CS graduates with little or no practical experience and produce software at their scale without putting those new hires through a multi-year training programme.

So the definition of success is that Go makes those people productive. If you give these fresh hires C++, now everything is on fire and even experienced people sent in to extinguish the flames end up just saying evacuate the entire site and let it burn itself out because that will be cheaper than diagnosing what's wrong.

This goal means some choices Go makes which I don't like seem more respectable. For example Go specifically warns you not to get clever. This is sound advice for a 22 year old new programmer who still probably thinks "Romeo and Juliet" is about true love, but it'd be very frustrating if you were trying to squeeze the last drops of performance juice out of a system. The answer from Google's point of view is that Go is the wrong language in that case and it's time to rewrite.

Re: Go generics are not bad

#156

Post by laerus »

philosopher1234 wrote: post #141
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…

Can’t hate on generics, so we need to find something else. Go takes away type system fidget spinners and leave devs with nothing to do but the actual job, which they hate, and thus they hate Go.

No it's simpler than that, they hate Go cause it's a half-assed language. The creators didn't respect developers enough to make it consistent and complete cause "devs are not smart enough". The argument about "getting things done" is like saying the language is Turing complete.

Re: Go generics are not bad

#157

Post by dmitriid »

yawaramin wrote: post #116
sangnoir wrote: post #107

Earlier quoted context omitted.

> 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 Reaso…

Don't buy that propaganda, however well-intentioned it is.

At the time when that post was written (including the "no bugs") the web version would continuously fail in the simplest of tasks while having a fraction of the features of the app version.

Re: Go generics are not bad

#158

Post by pjmlp »

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…

Go 's compilation speed is only impressive for newer generations that never used compilers for Pascal dialects, Modula languages, BASIC,....

Re: Go generics are not bad

#159

Post by pjmlp »

tialaramex wrote: post #155
mcronce wrote: post #135

Earlier quoted context omitted.

What's the definition of "success" here? Popularity?

As I understand it, Google's rationale for Go is to enable them to hire a lot of say, good-but-not-great fresh CS graduates with little or no practical experience and produce software at their scale without putting those new hires through a multi-year training programme. So the definition of success is that Go makes those people productive. If you give these fresh hires C++, now everything is on fire and even experie…

Which is ironic given the whole plethora of hiring practices at Google.

Also Go is mostly used externally, Google's key projects are all based on Java and C++, even Kubernetes would have stayed in Java if it wasn't for some Go folks joining the project and pushing for a rewrite.

Re: Go generics are not bad

#160

Post by seabrookmx »

kaba0 wrote: post #115
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.

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

You can have it both ways in C++ depending on your compiler flags!

And people wonder why we complain about C++..

Post reply on HN