[pjmlp]

> 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.

[beagle3]

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)

[fauigerzigerk]

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.

[pjmlp]

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

[fauigerzigerk]

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.

[pjmlp]

> 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.

[fauigerzigerk]

"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.

[pjmlp]

Faire enough.