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

91–100 of 113 posts

Re: Hacking Go's runtime with generics

#91

Post by clumsysmurf »

fsdjkflsjfsoij wrote: post #83
flagsrule wrote: post #60

Earlier quoted context omitted.

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

I was just reading that Spring 6 introduces Ahead-Of-Time compilation, enabling first-class support for GraalVM native images with Spring Boot 3. So hopefully the situation is improving.

Re: Hacking Go's runtime with generics

#92

Post by mattpallissard »

naasking wrote: post #52
maxmcd wrote: post #50

Earlier quoted context omitted.

I believe you usually want as much control of memory management as possible as it can be a great place for finding performance improvements and also help in delivering very consistent performance. Automatic memory management is a great aid in reduction of the complexity you have to deal with, but you presumably want to deal with that completely in the context of a database. Seems like this: https://www.cockroachlabs.…

> I believe you usually want as much control of memory management as possible as it can be a great place for finding performance improvements and also help in delivering very consistent performance. Sure, but premature optimization is the root of all evil right? Get something functional, then make it performant by handling the problematic cases. GC doesn't prevent this progression, it's just a significant help to get…

> premature optimization is the root of all evil right?

Making sure they're aren't a bunch of alloc's or GC spent in the hot path of a high performance library is hardly a premature optimization.

If you're tackling problems in DB land changes are you already have a fairly clear picture of what needs to happen and have a list of shortcomings you're trying to avoid. Memory layout, buffers, wals, etc are all things that should be accounted for upfront.

Re: Hacking Go's runtime with generics

#93

Post by kelipso »

dm319 wrote: post #48
lordgroff wrote: post #46

Earlier quoted context omitted.

It's like a hackernews meme at this point, complete with "I used Go before and my life was a meaningless void and then Rust came into my life and now I see the light." It's all so predictable and boring and derails nearly every Go thread.

The hackernews meme a few years ago was about how Go could do no wrong, and any perceived deficiencies was it due to being opinionated. Maybe this is a backlash?

The concept of "opinionated" itself is a meme.

Re: Hacking Go's runtime with generics

#94

Post by zachmu »

nine_k wrote: post #53
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…

The appeal of Go: - A pretty simple, if not very expressive, language (it's anti-Perl, and seems simpler than JS); you can learn it down to a reasonably productive level in a weekend. (I did.) - A memory-safe language (like Java) with good performance (like Java) without the need to install any runtime, and the ability to ship as a single binary (unlike Java). - A reasonably good and ergonomic concurrency approach (l…

I actually find go a joy to use, I dunno.

I like statically typed languages, and go makes defining and using types so simple and straightforward that it feels like you get a lot of the benefits of dynamic typing without the headaches.

Re: Hacking Go's runtime with generics

#95

Post by naasking »

mattpallissard wrote: post #92
naasking wrote: post #52

Earlier quoted context omitted.

> I believe you usually want as much control of memory management as possible as it can be a great place for finding performance improvements and also help in delivering very consistent performance. Sure, but premature optimization is the root of all evil right? Get something functional, then make it performant by handling the problematic cases. GC doesn't prevent this progression, it's just a significant help to get…

> premature optimization is the root of all evil right? Making sure they're aren't a bunch of alloc's or GC spent in the hot path of a high performance library is hardly a premature optimization. If you're tackling problems in DB land changes are you already have a fairly clear picture of what needs to happen and have a list of shortcomings you're trying to avoid. Memory layout, buffers, wals, etc are all things that…

> Making sure they're aren't a bunch of alloc's or GC spent in the hot path of a high performance library is hardly a premature optimization.

You often don't know the what the hot paths are.

Re: Hacking Go's runtime with generics

#96

Post by masklinn »

randomdata wrote: post #90
masklinn wrote: post #24

Earlier quoted context omitted.

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

> To be fair, a lot of those concepts were invented, at very least popularized, by the members of the Go team 30+ years ago.

Er... no? Not even remotely?

Re: Hacking Go's runtime with generics

#97

Post by masklinn »

ilyt wrote: post #87
masklinn wrote: post #24

Earlier quoted context omitted.

[flagged]

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

We're not talking bleeding edge CS topics here mate, we're talking "hashability is a useful property because hashmaps", that was standard >25 years ago.

Java had hashCode in 1.0, GvR added __hash__ to Python in March 1993 and shipped it in 0.9.9.

Hash maps are 69 years old (nice). Bespoke key types (and thus the requirement for user-defined hash functions) is probably the more recent of the two.

Re: Hacking Go's runtime with generics

#98

Post by pjmlp »

fsdjkflsjfsoij wrote: post #83
flagsrule wrote: post #60

Earlier quoted context omitted.

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

No we aren't, because there have been commercial compilers since around 2000, with Excelsior JET being one of the first ones, sadly out of business.

However, PTC and Aicas are still in business,

https://www.ptc.com/en/products/developer-tools/perc

https://www.aicas.com/wp/products-services/jamaicavm/

IBM's commercial one is now freely available on OpenJ9,

https://www.eclipse.org/openj9/docs/xaot/

Finally, if you are using a modern Android phone, an AOT compiler is in the box since Android 5, and it was modified into a mixed JIT with AOT compilation on rest since Android 7.

GraalVM happens to be the evolution of MaximeVM, and certainly not the only game in town.

Re: Hacking Go's runtime with generics

#99

Post by shakow »

konart wrote: post #89
shakow wrote: post #75

Earlier quoted context omitted.

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

> Just put a .netrc file in your homefolder with your username + token

Lol yes, let's just put sensitive information in plain text in my home folder and change the machine-wide configuration, because Go guys decided that if it worked in 1970, it is good enough for today.

> the 'private repo packages' was the only issue.

That's quite a big one for a language targeting companies.

> I'm pretty sure that there are millions of js projects out there

Sure, if your gauge is the JS ecosystem...

> At the same time Go provides enough stdlib to forget about dependencies completely

Go stdlib is decent, that's it. It does not even has basic data types such as sets (no, map keys are not a decent replacement for a set), queues or stacks.

Re: Hacking Go's runtime with generics

#100

Post by masklinn »

skybrian wrote: post #68
Traubenfuchs wrote: post #7

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

Sort of, except the way Java did it is awkward because they put a method on Object instead of making it an interface. It's not clear from the API what's really usable as a map key. I'm not sure making all comparable objects in Go usable as map keys is a good idea either.

> I'm not sure making all comparable objects in Go usable as map keys is a good idea either.

Was a good idea since, it's part of the spec-definition of Go:

> A map is an unordered group of elements of one type, called the element type, indexed by a set of unique keys of another type, called the key type. [...] The comparison operators == and != must be fully defined for operands of the key type

TFA is merely reusing that.

Post reply on HN