Hacker News Reader

Comment by tachyonbeam | Hacker News Reader

Why managed memory? The consensus seems to be that this gets in the way of predictable performance. GC is also non-trivial to parallelize.

View on HN

Developer convenience. If the language gives you an out to manage it yourself for performance: that's cool too.

I agree with the claim in the essay that there will always be a need for full throttle performance, which rules out a GC or ARC.

Where is this consensus stated? The JVM seems to do quite well.

People typically don't use Java for performance-sensitive real-time-ish applications. Most modern games are written in C++ still. Operating system kernels are written in C. When I think Java, what comes to my mind is something like LibreOffice.

>People typically don't use Java for performance-sensitive real-time-ish applications. Most modern games are written in C++ still. Operating system kernels are written in C.

Those are 1/100th or less of the type of code people write everyday, in startups, enterprise, cloud apps, even regular desktop and mobile apps...

>When I think Java, what comes to my mind is something like LibreOffice.

That's written in C++

Ouch! Rich Hickey, inventor of clojure came to same conclusion using lisps. He rewrote a system in lisp that was written in c++ before by him. He claimed that system written in lisp had far less concurrency issues, and was faster! He was a c++ advocate before that.

C & C++ are #2 and #4 on the Tiobe index fwiw. It’s not like real-time is a niche.

Real time is indeed a niche (though a big one), but also it's hardly the reason C and C++ are #2 and #4 on Tiobe.

Video games are like a 43 billion dollar industry, and that's just a small slice of software that has real time requirements. Real time is very much a mainstream need. Hacker news just tends to be a bit of a bubble because people focus so much on web development and business logic here.

>Video games are like a 43 billion dollar industry, and that's just a small slice of software that has real time requirements.

But still a tiny slither on what most programmers do. Most programmers (the overwhelming majority) do neither video games nor real time.

You put "real time" in there but that's an extreme edge case. Modern GC in the JVM is now able to guarantee around 10 millisecond maximum pauses.

> When I think Java, what comes to my mind is something like LibreOffice.

You should probably revise that thinking, since it is not written (at least in substantial ways) in Java. Moreover, desktop applications are probably not really the main use case for it (or any language other than web technologies) these days.

Java running on server processes or any long-lived computation sits in the top tier of performance. Not as fast as C/C++ but in the same ball-park.

10 ms is huge for a lot of things. Games, music software, video software, 10ms is a very visible hitch.

Note, new gc's in the most recent JDK's guarantee 10ms pauses on multi-terabyte heaps. For most cases it is far far far far far far less.

Even for webapps. V8's garbage collector was a huge problem when trying to get smooth animations on mobile phones.

"real time" has nothing to do with raw speed, and even with C/C++ requires custom allocators to get around normal memory code being unpredictable.

Real time requires predictability, something that was solved in GCs by mid-1990s and had workarounds (which are required in C/C++ as well, and widely used by games etc.) by 1980s - when real-time GC'ed programs started to be used. Including hard-realtime in telephone switches.

On smaller real time systems, we simply dont do dynamic memory allocation at all. Everything is global/static, or on the stack. Malloc can never fail if it's not called.

I think real-time does not mean what you think it means. It doesn't have to do with speed per se.

The runtime of all webthings in written in C++ (and Rust, which is kind of its spiritual successor).

Did you forget Tomcat?

One advantage of managed memory is that it can be moved, which makes allocation extremely fast.

I'm playing the devil's advocate a bit. I come from a compiler background. If your language has strong memory guarantees, a good compiler might even be able to eliminate temporary allocations completely in some cases, which is pretty neat (ie: make you think you're heap allocating something, when in reality it's on the stack, or in registers).

But that also requires managed memory. If your model is to call an opaque function `malloc` then the compiler can't reason about it to scalar replace it.

Reply on news.ycombinator.com