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

101–110 of 418 posts

Re: Generics can make your Go code slower

#101

Post by svnpenn »

averagedev wrote: post #72
svnpenn wrote: post #62

Earlier quoted context omitted.

Typical gatekeeping. I like Go, because it lets me get stuff done. You could say the same about JavaScript, but I think Go is better because of the type system. C, C++ and Rust are faster in many cases, but man are they awful to work with. C and C++ dont really have package management to speak of, its basically "figure it out yourself". I tried Rust a couple of times, but the Result/Option paradigm basically forces y…

I've found Go to be much simpler than Rust, especially syntax wise. However, in Rust you can use the ? operator which propagates errors. In Go you have to check err != nil.

> Rust you can use the ? operator

That doesnt work with all types:

https://stackoverflow.com/a/65085003

Re: Generics can make your Go code slower

#102

Post by chakkepolja »

Thaxll wrote: post #69
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…

There are very fast DB written in Go so this comment is irrelevant, what is the equivalent of https://github.com/VictoriaMetrics/VictoriaMetrics in an other language?

There's highly tuned java software too, like Lucene, do you call java a systems language?

All in all I think the semantics debate is irrelevant. No one is going to use go for an OS only because someone on internet calls it a systems language.

Re: Generics can make your Go code slower

#103

Post by ramesh31 »

wtetzner wrote: post #53
mrweasel wrote: post #17

Earlier quoted context omitted.

I might have worded it differently, but yeah, of cause generics can make your code slower, what did people expect.

From the article: > Monomorphization is a total win for systems programming languages: it is, essentially, the only form of polymorphism that has zero runtime overhead, and often it has negative performance overhead. It makes generic code faster. The point is that the way Go implements generics is in such a way that it can make your code slower, even though there is a well-known way that will not make your code slowe…

>even though there is a well-known way that will not make your code slower (at the cost of compile times).

That's the point though. The Golang team was surely aware of both approaches, and chose what they did as a conscious design decision to prefer faster compile times. People love Go because of the iteration speed compared to C++. And these little things start to add up if you don't have a clear product vision about what your language is meant for.

Re: Generics can make your Go code slower

#104

Post by pjmlp »

pornel wrote: post #76
svnpenn wrote: post #62

Earlier quoted context omitted.

Typical gatekeeping. I like Go, because it lets me get stuff done. You could say the same about JavaScript, but I think Go is better because of the type system. C, C++ and Rust are faster in many cases, but man are they awful to work with. C and C++ dont really have package management to speak of, its basically "figure it out yourself". I tried Rust a couple of times, but the Result/Option paradigm basically forces y…

Nobody's saying you can't use Go or must use C/C++/Rust. If Go works for you, that's great. The issue is about positioning of Go as a language. It's confusing due to being (formerly) marketed as a "systems programming language" that is typically a domain of C/C++/Rust, but technically Go fits closer to capabilities of Java or TypeScript.

Is writing a compiler, linker, kernel emulation layer, TCP/IP stack or a GPU debugger, systems programming?

Re: Generics can make your Go code slower

#105

Post by svnpenn »

mcronce wrote: post #87
svnpenn wrote: post #62

Earlier quoted context omitted.

Typical gatekeeping. I like Go, because it lets me get stuff done. You could say the same about JavaScript, but I think Go is better because of the type system. C, C++ and Rust are faster in many cases, but man are they awful to work with. C and C++ dont really have package management to speak of, its basically "figure it out yourself". I tried Rust a couple of times, but the Result/Option paradigm basically forces y…

What, specifically, do you mean when you say Rust is "awful to work with"? With C and C++ I agree, but I've had a drastically better development experience in Rust than Go.

You should probably read the rest of the comment...

Re: Generics can make your Go code slower

#106

Post by pjmlp »

dahfizz wrote: post #71
svnpenn wrote: post #62

Earlier quoted context omitted.

Typical gatekeeping. I like Go, because it lets me get stuff done. You could say the same about JavaScript, but I think Go is better because of the type system. C, C++ and Rust are faster in many cases, but man are they awful to work with. C and C++ dont really have package management to speak of, its basically "figure it out yourself". I tried Rust a couple of times, but the Result/Option paradigm basically forces y…

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

Ah, that is why all major OSes end up having some form of POSIX support to keep those C applications going.

Re: Generics can make your Go code slower

#107

Post by pjmlp »

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.

Depends if LTO is used.

Re: Generics can make your Go code slower

#108

Post by Karrot_Kream »

titzer wrote: post #81
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…

You really haven't given any supporting information for your argument other than a vague feeling that GC is somehow bad. In fact you just pointed out many counterexamples to your own argument, so I'm not sure what to take away. I've seen this sentiment a lot, and I never see specifics. "GC is bad for systems language" is an unsupported, tribalist, firmly-held belief that is unsupported by hard data. On the other hand…

Right. In my experience just taking a few steps (like pre-allocating buffers or arrays) decrease GC pressure enough where GC runs don't actually affect performance enough to matter (as long as you're looking at ~0.5-1 ms P99 response times). But there's always the strident group who says GCs are bad and never offer any circumstance where that could be true.

Re: Generics can make your Go code slower

#109

Post by chakkepolja »

SomeCallMeTim wrote: post #51
trey-jones wrote: post #2

This is a really long and informative article, but I would propose a change to the title here, since "Generics can make your Go code slower" seems like the expected outcome, where the conclusion of the article leans more towards "Generics don't always make your code slower", as well as enumerating some good ways to use generics, as well as some anti-patterns.

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

We don't know of a way to implement generic types without (vtable dispatch + boxing) cost AND without monomorphization cost. Some languages do former, some latter, some combination of 2.

Monomorphization: * code bloat * slow compiles * debug builds may be slow (esp c++)

Dynamic dispatch & boxing (Usually both are needed): * not zero cost

Pick your poison

Post reply on HN