Go’s march to low-latency GC

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

Because the C++/Rust way of memory management is better for some things, but worse for others. I've worked with several different projects during my career, and not once did we require manual memory management. A GC based language was simpler for us to use, and the few times we had problems with GC, they were possible to overcome by writing better code, as is the case with any language.

This is not to say that no project benefits heavily form C++/Rust. But I would argue that for many, GC is the best trade off.

[ Parent | on HN ]

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 ]

Re:Go’s march to low-latency GC by BinaryIdiot on Wednesday July 06, 2016 @01:47PM (#12044700)

I'm not sure where you got manual memory management from. I was strictly referring to RAII. Manual memory management is such a pain but the C++ and Rust ways are very similar with RAII.

[ Parent | on HN ]

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

I usually refer to everything that isn't GC as 'manual'. RAII is an abstraction on top of manual management, you still need to decide what type of pointer/lifetime the allocated object should have, making it manually managed, IMHO.

RAII of course deals with more than just memory, but in a thread about GC I assumed it was memory management you referred to.

[ Parent | on HN ]