4 ms·
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
by Skinney 10y ago
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.
- BinaryIdiot 10y agoI'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.
- Skinney 10y agoI 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.
- unscaled 10y agoI 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.
- kasey_junk 10y agoI'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
- Skinney 10y agoFor what, I would assume, is a minor portion of your total lines of code.