Hacker News Reader

Comment by fauigerzigerk | Hacker News Reader

Go is nice but it's a replacement for Java or Python not for C++. I'm working on an in-memory analytics engine, something that has only become affordable in recent years because memory prices have fallen so much.

In-memory computing is a very important trend and garbage collected languages just don't work. You can't have the system stall for seconds or even tens of seconds unless it's purely a batch workload.

I have to admit that I haven't really researched what can be done in Go to keep in-memory data off-heap so the garbage collector doesn't see it. I have done that research for Java and it's unworkable. It's either slow or extremely unproductive to work with or both.

View on HN

Are garbage collection pauses really a concern? You're still running atop a multitasking operating system with all kinds of pauses.

Garbage collection pauses are a huge concern with larger heap sizes. Depending on the application it may be OK to make a user wait for a second or two, but not for 30 seconds. Multitasking doesn't cause that kind of lag usually.

It's even more problematic for some types of trading systems or stream processing of sensor data, etc.

All the trends are working against garbage collection right now. Memory sizes are growing and we're moving away from batch processing for many workloads.

Most definitely - on a modern multitasking operating system your "all types of pauses" is generally only synchronous IO issues to disk or network - as long as you've got spare CPU available to your process/threads and you're sensible with your memory allocation.

> garbage collected languages just don't work. You can't have the system stall for seconds or even tens of seconds unless it's purely a batch workload.

What about languages like Erlang and Rust where each actor/object/process has its own heap, GCed individually?

I have zero experience with Erlang, but judging by the benchmarks it is a very slow language for algorithmic stuff.

Rust should work. It's the right approach I think. I haven't used it yet, but I really hope it gains popularity and becomes a real alternative to C++.

> In-memory computing is a very important trend and garbage collected languages just don't work. You can't have the system stall for seconds or even tens of seconds unless it's purely a batch workload.

Nice omission of pauseless GC algorithms there.

Can you point me to a reasonably mature and efficient implementation of such an algorithm for Go or Java? I only know the Azul one which costs thousands of dollars per server per year.

You just mentioned one for Java, the fact that it is commercial is irrelevant.

Irrelevant for what? This was a debate about whether or not Go can replace C++, remember? So the fact that there is no such implementation for Go has to be relevant.

It is also very relevant for me that there is no Java implementation of a pauseless garbage collector that is even remotely viable for my business model or the business model of 99% of all startups out there.

If all you want to say is that it is possible to solve this problem for garbage collected languages, then we can agree. Unfortunately there is no viable solution available right now.

> Irrelevant for what? This was a debate about whether or not Go can replace C++, remember? So the fact that there is no such implementation for Go has to be relevant.

Well, surely with so many top notch brains Google can come up with a way to improve Go's runtime if they care about the issue.

> It is also very relevant for me that there is no Java implementation of a pauseless garbage collector that is even remotely viable for my business model or the business model of 99% of all startups out there.

Do you mean viable, as free of charge?

> If all you want to say is that it is possible to solve this problem for garbage collected languages, then we can agree. Unfortunately there is no viable solution available right now.

Yes, that is my main point.

"Do you mean viable, as free of charge?"

No, but it would have to be a fraction not a multiple of my per server profit margin. Azul's target market is clearly hedge funds and the like. They don't even quote a price on their website.

To be not only viable but also beneficial, the Azul license plus the additional DRAM cost of Java itself would have to be less than it costs me to use C++ instead of Java.

Faire enough.

As someone who had tried to work with available GCs in Java, GP is spot on; it doesn't matter that algorithms exist - production JVMs still pause (or at least did 2 years ago when I looked into it)

Reply on news.ycombinator.com