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

311–320 of 418 posts

Re: Generics can make your Go code slower

#311

Post by azth »

coder543 wrote: post #59
azth wrote: post #43

Earlier quoted context omitted.

In practice, it's used as an alternative to python and ruby and nodejs. It can't fully do what Java or C# do.

Well, that is simply not true at all. Go is a perfectly capable replacement for Java and C#. Many huge projects that would likely never be written in Python have been written in Go when they would have otherwise been written in Java or C# in years past: Kubernetes, Prometheus, HashiCorp Vault and Terraform, etcd, CoreDNS, TiDB, Loki, InfluxDB, NATS, Docker, Caddy, Gitea, Drone CI, Faktory, etc. The list goes on and o…

golang doesn't have annotations, doesn't have enums, error handling is very error prone. No ability to choose from different GC implementations, nothing remotely close to JFR.

Re: Generics can make your Go code slower

#312

Post by erik_seaberg »

wtetzner wrote: post #275
ramesh31 wrote: post #103

Earlier quoted context omitted.

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

Of course, I understand that they made that decision. I was just replying to this: > of cause generics can make your code slower, what did people expect. It's not unreasonable that some people might have expected monomorphization.

In fact I sort of thought they had announced monomorphization, though I wasn’t following really carefully.

Re: Generics can make your Go code slower

#313

Post by steveklabnik »

unscaled wrote: post #306
svnpenn wrote: post #276

Earlier quoted context omitted.

Thats a good outlook. Dont worry about any problem, just import something an its fixed! More imports the better! Hopefully we can do away with all code, and just import everything.

Well, before Go 1.13 came out, every decent production codebase in Go had to import Dave Cheney's pkg/errors[1] unless you totally gave up the idea of having useful error traces. Go 1.13 has incorporated most of what this package does into the standard library. It really doesn't matter much whether the code is in a de-facto standard package or folded into the standard library IMHO, but Rust could do the same. [1]: ht…

Rust did partially do this; one of the previous generation of packages here, failure, had most of its ideas eventually rolled into std::errror::Error, which enabled this next generation of packages (anyhow, thiserror, miette, eyre... the only one I'm not sure about is snafu, which did exist before, but I'm not sure if it got more improvements due to these changes or not.)

Re: Generics can make your Go code slower

#314

Post by pjmlp »

dahfizz wrote: post #294
pjmlp wrote: post #184

Earlier quoted context omitted.

POSIX is UNIX rebranded as C runtime for OSes that aren't UNIX.

I don't even know how to parse that. POSIX is a standard which was based on the unix OS's of the time. POSIX is an API, not a runtime. Only Unix systems today implement posix (MacOs, Linux).

Yes it is a standard, just like ISO C one is, and traditionally they go go together, just like you never use IP on its own.

I suggest you to have a look around RTOS, mainframes, BeOS, and even NT history regarding POSIX support.

Re: Generics can make your Go code slower

#315

Post by pjmlp »

pornel wrote: post #284
pjmlp wrote: post #104

Earlier quoted context omitted.

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

If you dig deep enough into the Turing Tarpit, you can write these in JavaScript too (in fact, some of these have already been written). It's merely a disagreement about what the label "systems programming" should mean, rather than about capabilities and performance of the Go language. Objectively and undeniably Go relies on garbage collection, and C/C++/Rust don't. Google's implementation of Go prefers fast compilat…

A disagreement indeed,

https://people.inf.ethz.ch/wirth/ProjectOberon/Sources/Kerne...

Re: Generics can make your Go code slower

#316

Post by pjmlp »

fluoridation wrote: post #224
pjmlp wrote: post #212

Earlier quoted context omitted.

Good luck with inlining and devirtualization across DLLs with AOT. JIT caches with PGO get most of AOT benefits, that is why after the short stint with AOT on Android, Google decided to invest in JIT caches instead. The best toolchains can do both, so it is never a matter of either AOT or JIT. GCC and clang aren't investing in JIT features just for fun.

What's with the snappy tone? >Good luck with inlining and devirtualization across DLLs with AOT. An AOT compiler/linker is unable to inline calls across DLL boundaries because DLLs present a black-box interface. A JIT compiler would run into the exact same problem when presented with a DLL whose interface it doesn't understand or is incompatible with. If you really want a call inlined the solution is to link the call…

I am sarcastic by nature, that is why.

JIT compilers for Java and .NET do inline across shared libraries and devirtualization, including native calls.

When people discuss A vs B there is always a dichotomy.

Re: Generics can make your Go code slower

#317

Post by avinassh »

azth wrote: post #43
shadowgovt wrote: post #14

Earlier quoted context omitted.

This is good high-level advice as well as low-level advice. Go is positioned to be most useful as an alternative to Java, and to C++ where performance isn't the key factor (i.e. projects where C++ would be chosen because "Enh, it's a big desktop application and C++ is familiar to a lot of developers," not because the project actually calls for being able to break out into assembly language easily or where fine-tuning…

In practice, it's used as an alternative to python and ruby and nodejs. It can't fully do what Java or C# do.

> It can't fully do what Java or C# do.

I am curious, what all stuff it cannot do?

Re: Generics can make your Go code slower

#318

Post by morelisp »

linkdd wrote: post #258
morelisp wrote: post #202

Earlier quoted context omitted.

You're giving fine advice for well-scoped tasks with minimal design space (well, sort of - using std::list ever is laughable - but if you had said unordered_map vs. map, sure, so I take the broad point). But, some of us have been around the block a few times though, and now need to make sure those spaces are delineated for others in a way that won't force them into a performance corner. > until you have implemented y…

> using std::list ever is laughable https://baptiste-wicht.com/posts/2012/11/cpp-benchmark-vecto... > some of us have been around the block a few times though, and now need to make sure those spaces are delineated for others in a way that won't force them into a performance corner. This, just like the rest of your comment, is just patronizing and condescendant. > I don't mean to brag, but I guess I'm a lot better at…

> This, just like the rest of your comment, is just patronizing and condescendant.

I tried to be a bit self-effacing also, but platitudes like "make it right, then make it fast" are condescending to begin with. Sometimes "make it right" requires knowing the performance implications of your architecture decisions.

> Because Python is interpreted and Go is compiled.

This is not why the Go API beats the Python API, which you can tell from knowing the basic language semantics plus method signature.

Re: Generics can make your Go code slower

#319

Post by alephnan »

blindmute wrote: post #292
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…

Honest question, what is golang a good choice for? It seems to inhabit the nether realm between high level productivity and low level performance, not being good at either.

> It seems to inhabit the nether realm between high level productivity

This is where you're wrong.

What would you consider "high level productivity" then? Java? Ruby? Ruby on Rails?

Re: Generics can make your Go code slower

#320

Post by alephnan »

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…

> performance or memory sensitive

Depends on what you're measuring as performance.

Server request throughput? Being middleware API server to relay data between a frontend and a backend?

Post reply on HN