Hacker News Reader

Comment by nu11ptr | Hacker News Reader

I'm not suggesting they rewrite. I'm questioning if Java was ever the best choice for this application in the first place. They are using Java as if it were C++. Perhaps it would have been better to write it in C++ in that case? I'm not drawing conclusion, as I'm not in their domain and have not given this a lot of thought, but it just strikes me as a particularly shaky foundation.

View on HN

Java brings some good things over C++. For example memory-safe VM, easier language with way less gotchas, better tooling, awesome IDEs.

I'd say, if C++ performance is not essential, Java might actually be a good choice. It's very fast and GC issues could be worked around.

How is it memory safe if they are using off heap memory with malloc/free? I think it would only qualify as memory safe if they were using the GC which they purposefully avoid.

I will agree on the other points, however, but I wonder how much of a gain that is against the pain of working against the language. Hard to say.

> How is it memory safe if they are using off heap memory with malloc/free? I think it would only qualify as memory safe if they were using the GC which they purposefully avoid.

You can still write a safe/minimal wrapper around that with just the actual API you need. (Instead of allowing everything to just peek/poke around in arbitrary off-heap memory.)

how do you prevent use-after-free with a wrapper?

They're not GCing/freeing memory at all, but if they were, you free memory by trashing all your references that could use-after-free so it's not an issue.

I think this is an argument for correct program architecture/design, not one for language. I suspect one could do the same thing in any memory unsafe language. Granted, Java might make this somewhat easier by not having the concept of modifiable pointers, but discipline and static analysis could likely achieve the same.

> I suspect one could do the same thing in any memory unsafe language. Granted, Java might make this somewhat easier by not having the concept of modifiable pointers, but discipline and static analysis could likely achieve the same.

You can theoretically, but nobody has shown persuasively how to do it. The problem is when anything can be unsafe, everything can. Small safe abstractions using unsafe primitives "under the hood" in a safe language are king.

Picking Java feels interesting given that it’s a database. I would love to know their justification for the choice.

Although - I have known a trading firm that wrote their platform in Java, offloading any disk and network access to some limited C++ and JNI. In their case I believe they simply allocated large buffers that C++ pushed and pulled data from. The benefit of this strategy was their Quants could build memory-safe strategies and in a much friendlier language. For them if eliminated the risk of bad code and lost time to debugging awful C++ errors.

To my knowledge it all worked for them quite well, they made good money and any minor differences of speed in Java were negligible to them.

Java tooling was excellent back when QuestDB was started and still is excellent today compared to C++.

Reply on news.ycombinator.com