Go’s march to low-latency GC

Re:Go’s march to low-latency GC by unscaled on Wednesday July 06, 2016 @09:20PM (#12046943)

I completely agree that explicit memory management (I wouldn't call it manual) in the C++/Rust way is a cognitive overhead you don't want for a great deal of the software work - perhaps most of it.

But there are definitely projects that require explicit memory management, and it's not just games and realtime software. Often high-performance backend code in Java and Go just end up using object pools instead of reallocating objects, just as the OP described.

With Go specifically we've seen the rise of fasthttp, which just adds completely manual memory management in the 90's C++ fashion. Want to create a new request object?

req := AcquireRequest() req.DoSomething() ReleaseRequest(req)

Compare to C++98:

Request* req = new Request(); req->DoSomething(); delete req;

And now you're back at the same manual memory management problem modern C++ and Rust are striving to solve.

[ Parent | on HN ]

Re:Go’s march to low-latency GC by kasey_junk on Wednesday July 06, 2016 @09:43PM (#12047009)

I'd argue that one of the biggest differences between golang and java is not technical but cultural. That is, the golang idioms and thus the std libs are quicker to reach for things like object pools and other performance "hacks". Even the std http library uses an arena in golang.

Similarly, high performance Java libraries like the Disruptor, SBE or Chronicle look very much like C code.

Personally, that doesn't bother me, as it allows you to write your hot path and your non-optimized path in the same language with the same tooling.

says the guy who has split JVMs across processes for performance and contemplated doing it per core

[ Parent | on HN ]

Re:Go’s march to low-latency GC by Skinney on Wednesday July 06, 2016 @11:55PM (#12047397)

For what, I would assume, is a minor portion of your total lines of code.

[ Parent | on HN ]