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

Hacking Go's runtime with generics

dolthub.com

Post reply on HN
Print view View original

81–90 of 113 posts

Re: Hacking Go's runtime with generics

#81

Post by randomdata »

valenterry wrote: post #77
silisili wrote: post #17

Earlier quoted context omitted.

I've been writing software for 20 years. About half that in Go. Whenever I see someone say it's a bad language because X, I seriously wonder if the asker just writes terrible code, or if there's whole swaths of domains I've not encountered. Or maybe a little of both. I've never once been stumped by a lack of generics, for example, despite how many people claim it's unusable without them.

No it's mostly just the blub paradox. You don't feel the pain because you didn't use some features/techniques of other languages that don't exist in Go. It's the same everyone. I, for example, never felt I was missing something until I learned about type providers. Now that I don't work in a language that supports them, I hate it. If I had never learned about them, I would probably never miss em.

He didn't express a lack of pain, just that he was never in a situation where he was stumped by not having them. Generics aren't exactly magic. They can improve code, but you can live without them if you really have to.

Although I think you are on to something per the original question about the appeal of Go. For all its faults, Go also gets a lot of things very right that aren't obvious until you have gained the necessary level of familiarity.

Once you rise above 'blub', it is indeed hard to go back. While I spend most of my days in other languages full of all kinds of fanciful features, I did a short stint on a Go project and now especially hate not having blocking functions everywhere (async/await is one of those fanciful features I have to deal with) and sensible error handling.

Re: Hacking Go's runtime with generics

#82

Post by awmarthur »

aatd86 wrote: post #59
voz_ wrote: post #5

I do not understand the appeal of go. > The proposal argues that Golang developers are forced to work around language when writing hash-based data structures like Tries or concurrent hash maps. Developers who want an efficient hash-based data structure have only the builtin map to choose from. When this issue was originally created in 2017, Golang didn't have generics And then the author goes to tell us about how thi…

I think he didn't mean tries which don't generally need hashing but was trying to implement a lock-free map based on Concurrent Hash-Array Mapped Tries. I had done that myself as an exercise a few years back and had to extract the hash function from the runtime that is used for maps. In any case, the performance was terrible and code brittle. (lack of sumtypes). Since then, I've learnt to not bother too much and just…

(OP) I'm mostly interesting in a fast hash for writing a generic, concurrent hash map.

The reference to Tries came from the original issue in the Golang repo about possible uses for a standard library hash function: https://github.com/golang/go/issues/21195

And you're right, the Trie implementation linked there was indeed a Hash-Array Mapped Tried: https://pkg.go.dev/github.com/lleo/go-hamt-key#Key

Re: Hacking Go's runtime with generics

#83

Post by fsdjkflsjfsoij »

flagsrule wrote: post #60
pjmlp wrote: post #28

Earlier quoted context omitted.

Then use an AOT compiler, plenty of those for JVM since 2000. While one can excuse themselves that they were commercial, GraalVM native image, and OpenJ9 offer free beer alternatives.

I looked into using Graal one time. Many of the dependencies I used were not compatible. I also encounter weird bugs with any of the OpenJ* alternatives. In Go, everything just works.

The JVM proponents are usually being dishonest when they compare Java/Kotlin AOT compilation to Go. They know very well that a large number of popular libraries either outright don't work or have severe restrictions when using AOT. It's also common to run into bugs since Graal is relatively new and only a miniscule percentage of the Java community uses it. It's not even remotely close to Go where everything can be assumed to work.

Re: Hacking Go's runtime with generics

#84

Post by masklinn »

the_gipsy wrote: post #79
shakow wrote: post #76

Earlier quoted context omitted.

> I just think that shoehorning Kotlin into "the go niche" is absurd That's what you say, but you don't really tell us why.

It's not my burden of proof. If you think something like compiling kotlin instead of running a JVM is akin to compiling with go tooling, then at this point anything that somehow compiles to native (and beyond) is in the "go niche".

> It's not my burden of proof.

You're the one asserting that it's unsuitable. So it very much is.

> If you think something like compiling kotlin instead of running a JVM is akin to compiling with go tooling, then at this point anything that somehow compiles to native (and beyond) is in the "go niche".

I don't know about the other commenters, but that's literally the only criteria you've deigned offer so far, aside from some sort of conspiratorial implications.

Re: Hacking Go's runtime with generics

#85

Post by shp0ngle »

barsonme wrote: post #3
shp0ngle wrote: post #2

ELI5. How is maphash different from just using map? I am surely missing something. I thought the builtin map used hashing too?

The maphash package from the blog post provides routines that call into Go's runtime to hash arbitrary types. The maphash package in the standard library (hash/maphash) provides routines that hash string and []byte. The builtin map type is a hash table.

Ahh I somehow misread the post and thought it’s a generic map that uses hash table.

I should get some sleep, thanks

Re: Hacking Go's runtime with generics

#86

Post by the_gipsy »

masklinn wrote: post #84
the_gipsy wrote: post #79

Earlier quoted context omitted.

It's not my burden of proof. If you think something like compiling kotlin instead of running a JVM is akin to compiling with go tooling, then at this point anything that somehow compiles to native (and beyond) is in the "go niche".

> It's not my burden of proof. You're the one asserting that it's unsuitable. So it very much is. > If you think something like compiling kotlin instead of running a JVM is akin to compiling with go tooling, then at this point anything that somehow compiles to native (and beyond) is in the "go niche". I don't know about the other commenters, but that's literally the only criteria you've deigned offer so far, aside fr…

So if I say is in go's niche, it's your burden to disprove it?

Look, this is getting ridiculous. Go offers easy+fast tooling out of the box. Any JVM language, compiled or not, will never be anywhere NEAR go's tooling in those terms. The extra compilation layer just makes it actually much worse.

And I don't even find go particularly appealing.

Re: Hacking Go's runtime with generics

#87

Post by ilyt »

masklinn wrote: post #24
Traubenfuchs wrote: post #7

So the reinvented wheel (golang) is now starting to miss / reinvent Java's .hashCode() or an alternative to it?

[flagged]

You'd be hard pressed to name anything in IT that wasn't "discovered" in the 60s-80s but implemented/re-implemented recently

Re: Hacking Go's runtime with generics

#88

Post by ilyt »

shakow wrote: post #61
silisili wrote: post #17

Earlier quoted context omitted.

I've been writing software for 20 years. About half that in Go. Whenever I see someone say it's a bad language because X, I seriously wonder if the asker just writes terrible code, or if there's whole swaths of domains I've not encountered. Or maybe a little of both. I've never once been stumped by a lack of generics, for example, despite how many people claim it's unusable without them.

> I've never once been stumped by a lack of generics Heve you never written a stack structure (since Go doesn't include one)? Never used a min/max function between numbers (go doesn't either)?

Those are not show-stoppers, just annoyances.

Generics make it oh so much nicer to do some stuff but lack of them wasn't exactly something that I missed, just that I wished some libraries had for the cases you mentioned (generic map/reduce/math/etc.)

Re: Hacking Go's runtime with generics

#89

Post by konart »

shakow wrote: post #75
konart wrote: post #69

Earlier quoted context omitted.

>If we preferred a higher-level language with a Gc, Java/Kotlin/C# would be, IMHO, much better. Writing code in Java\Kotlin requires quite some investment into the language and tooling (at least that's my Java impression). With Go - you can start getting the job done from day one most of the time. Some parts of Go may be harder than the others, even challenging maybe, but not as hard as Java. Lack of OOP (at least in…

To be honest, I think that go packaging is ghastly (just accessing dependencies in private repos requires changing global git settings, which is an abomination), but I can see how Java can be very heavy on that. However, I would not weight too much the time-to-first-makefile of a language if a project is supposed to live for years.

>just accessing dependencies in private repos requires changing global git settings, which is an abomination

Just put a .netrc file in your homefolder with your username + token and use GOPRIVATE env variable. No need to change any git settings.

After go modules became mainsream most go packaging issues where out of question, imo. At least for me the 'private repo packages' was the only issue.

I'm pretty sure that there are millions of js projects out there, many of them been there for years and will be there for many years to come, all despite npm and js packaging issues in general...

At the same time Go provides enough stdlib to forget about dependencies completely if you are afraid that use of some of them (or packaging system in general) may result in some negative scenario.

This is where Go shines: it can offer enough to be powerfull without becoming java. But without a doubt Go has many things to improve too.

Re: Hacking Go's runtime with generics

#90

Post by randomdata »

masklinn wrote: post #24
Traubenfuchs wrote: post #7

So the reinvented wheel (golang) is now starting to miss / reinvent Java's .hashCode() or an alternative to it?

[flagged]

To be fair, a lot of those concepts were invented, at very least popularized, by the members of the Go team 30+ years ago. Go is their chance to carefully bundle those ideas together, not just throw every random idea they can think of into a language and end up with a big ball of mud like so many others want to do. There are already plenty of ball of mud languages, if that's what you're looking for.
Post reply on HN