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

Generics can make your Go code slower

planetscale.com

Post reply on HN
Print view View original

91–100 of 418 posts

Re: Generics can make your Go code slower

#91

Post by DoctorOW »

nvarsj wrote: post #46

I'd argue that golang is inherently not a systems language, with its mandatory GC managed memory. I think it's a poor choice for anything performance or memory sensitive, especially a database. I know people would disagree (hence all the DBs written in golang these days, and Java before it), but I think C/C++/Rust/D are all superior for that kind of application. All of which is to say, I don't think it matters. Use t…

I've said this before, and I'll say it again. People lump Go in with C/C++/Rust because they all (can) produce static binaries. I don't need to install Go's runtime like I install Java/NodeJS/Python runtimes. Honestly, I think it speaks so much to Go's accomplishments that it performs so well people intuitively categorize it with the systems languages rather than other managed languages.

Re: Generics can make your Go code slower

#92

Post by mcronce »

gmfawcett wrote: post #63
SomeCallMeTim wrote: post #51

Earlier quoted context omitted.

In C++, generics (templates) are zero-cost abstractions. So no, generics do not de facto make code slower.

That's only 99% of the story. :) Having too many specializations of a C++ template can lead to code bloat, which can degrade cache locality, which can degrade performance.

You're definitely right. While it's not a particularly common problem, it does exist; one thing I'd really like to see enter the compiler world is an optimization step to use vtable dispatch (or something akin to Rust's enum_dispatch, since all concrete types should be knowable at compile time) in these cases.

I expect it would require a fair amount of tuning to become useful, but could be based on something analogous to the function inliner's cost model, along with number of calls per type. Could possibly be most useful as a PGO type step, where real-world call frequency with each concrete type is considered.

Re: Generics can make your Go code slower

#93

Post by dahfizz »

dcgudeman wrote: post #78
dahfizz wrote: post #71

Earlier quoted context omitted.

> C and C++ dont really have package management to speak of I hear this complaint often, but I consider it a feature of C. You end up with much less third party dependencies, and the libraries you do end up using have been battle tested for decades. I much prefer that to having to install hundreds of packages just to check if a number is even, like in JS.

Hmm yes, why stop there? Why have functions? Just reimplement business logic all over your codebase. That way each block of code has everything you need to know. Sure, functions have been adopted by every other language/ecosystem and are universally known to be useful despite a few downsides but you could say the same about package management and that hasn't deterred you yet.

You're arguing against a straw man. I could just as easily say "why not make every line of code it's own function?"

C has libraries, and my comment made it clear that they are useful.

Argue against my actual point:

By not having a bespoke package manager, and instead relying on the system package manager, you end up with higher quality dependencies and with dramatically less bloat in C than other language ecosystems. It is all the benefit and none of the drawbacks of npm-like ecosystems.

Re: Generics can make your Go code slower

#94

Post by phplovesong »

stingraycharles wrote: post #66
baq wrote: post #58

Earlier quoted context omitted.

this has been argued ad nauseum a decade ago and it boils down to your definition of 'systems'. at google scale, a system is a mesh of networked programs, not a kernel or low-level bit-banging tool.

By that definition, Java is a systems language as well. I think Go makes a better trade-off than Java, but I struggle to come up with decent examples of projects one could write in Go and not in Java. Most of the “systems” problems that Java is unsuitable for, also apply to Go.

Go compiles to static binaries. Java needs the JVM. That already is a HUGE difference in "picking the right tool".

Also, the JVM is way more heavy and resource intensive than a typical Go program. Go is great for cli tools, servers, and the usual "microservices" stuff, whatever it means to you.

Re: Generics can make your Go code slower

#95

Post by dse1982 »

This is a very interesting article. I was however a bit confused by the lingo, calling everything generics. As I understood it the main point of the article quite precisely matched the distinction between generics and templates as I learned it. Therefore what surprised me most was the fact that go monomorphizes generic code sometimes. Which however makes sense given the way go's module-system works – i.e. imported modules are included in the compilation – but doesn't fit my general understanding of generics.

Re: Generics can make your Go code slower

#96

Post by randomdata »

nvarsj wrote: post #46

I'd argue that golang is inherently not a systems language, with its mandatory GC managed memory. I think it's a poor choice for anything performance or memory sensitive, especially a database. I know people would disagree (hence all the DBs written in golang these days, and Java before it), but I think C/C++/Rust/D are all superior for that kind of application. All of which is to say, I don't think it matters. Use t…

> I'd argue that golang is inherently not a systems language

First you'd have to establish what "systems" means. That, you'll find, is all over the place. Some people see systems as low level components like the kernel, others the userland that allows the user to operate the computer (the set of Unix utilizes, for example), you're suggesting databases and things like that.

The middle one, the small command line utilities that allow you to perform focused functions, is a reasonably decent fit for Go. This is one of the places it has really found a niche.

What's certain is that the Go team comes from a very different world to a lot of us. The definitions they use, across the board, are not congruent with what you'll often find elsewhere. Systems is one example that has drawn attention, but it doesn't end there. For example, what Go calls casting is the opposite of what some other languages call casting.

Re: Generics can make your Go code slower

#97

Post by philosopher1234 »

jpgvm wrote: post #79
stingraycharles wrote: post #66

Earlier quoted context omitted.

By that definition, Java is a systems language as well. I think Go makes a better trade-off than Java, but I struggle to come up with decent examples of projects one could write in Go and not in Java. Most of the “systems” problems that Java is unsuitable for, also apply to Go.

Go is strictly less useful than Java because it has strictly less power. This is true for general purpose programming (though somewhat remediated through introduction of generics) it's doubly true for "systems" applications: No access to raw threads. No ability to allocate/utilize off-heap memory (without CGo and nonsense atleast). Low throughput compared to Java JIT (unsuitable for CPU intensive tasks). The only thi…

This is an argument from edge case capabilities that completely ignores maintenance costs + development time. Seems very naive to me.

Re: Generics can make your Go code slower

#98

Post by pjmlp »

DoctorOW wrote: post #91
nvarsj wrote: post #46

I'd argue that golang is inherently not a systems language, with its mandatory GC managed memory. I think it's a poor choice for anything performance or memory sensitive, especially a database. I know people would disagree (hence all the DBs written in golang these days, and Java before it), but I think C/C++/Rust/D are all superior for that kind of application. All of which is to say, I don't think it matters. Use t…

I've said this before, and I'll say it again. People lump Go in with C/C++/Rust because they all (can) produce static binaries. I don't need to install Go's runtime like I install Java/NodeJS/Python runtimes. Honestly, I think it speaks so much to Go's accomplishments that it performs so well people intuitively categorize it with the systems languages rather than other managed languages.

Managed languages like Oberon, D, Modula-3, System C#…

Re: Generics can make your Go code slower

#99

Post by coder543 »

stingraycharles wrote: post #66
baq wrote: post #58

Earlier quoted context omitted.

this has been argued ad nauseum a decade ago and it boils down to your definition of 'systems'. at google scale, a system is a mesh of networked programs, not a kernel or low-level bit-banging tool.

By that definition, Java is a systems language as well. I think Go makes a better trade-off than Java, but I struggle to come up with decent examples of projects one could write in Go and not in Java. Most of the “systems” problems that Java is unsuitable for, also apply to Go.

> By that definition, Java is a systems language as well.

I would fully agree that Java is a systems language.

However, the definition of "systems language" has been a contentious issue for a very long time, and that debate seems unlikely to be resolved in this thread. I don't think the term itself is very useful, so it's probably better if everyone focuses on discussing things that actually matter to the applications they're trying to develop instead of arguing about nebulous classifications.

Re: Generics can make your Go code slower

#100

Post by pjmlp »

phplovesong wrote: post #94
stingraycharles wrote: post #66

Earlier quoted context omitted.

By that definition, Java is a systems language as well. I think Go makes a better trade-off than Java, but I struggle to come up with decent examples of projects one could write in Go and not in Java. Most of the “systems” problems that Java is unsuitable for, also apply to Go.

Go compiles to static binaries. Java needs the JVM. That already is a HUGE difference in "picking the right tool". Also, the JVM is way more heavy and resource intensive than a typical Go program. Go is great for cli tools, servers, and the usual "microservices" stuff, whatever it means to you.

Java can just be AOT compiled as Go, the only difference is that until recently it wasn't a free beer option to do so.
Post reply on HN