Hacker News Reader

Comment by nu11ptr | Hacker News Reader

I mean no disrespect to the authors, but this seems like an extremely painful way to write an application. How common is it to write Java apps this way? It seems like there must have been a better language choice than trying to work against the GC and rewriting parts of the standard lib? And now adding in Rust via JNI? It just feels very painful to me.

View on HN

QuestDB engineer here:

It's true that our non-idiomatic Java usage denies us some of the benefits typically associated with Java programming. Automatic memory management and the old "Write Once, Run Anywhere" paradigm are difficult to maintain due to our reliance on native libraries and manual memory management.

I see two classes of reasons for choosing Java:

1. Historical: The QuestDB codebase predates Rust. According to Wikipedia, the initial Rust release was in 2015. The oldest commit in the QuestDB repo is from 2014: https://github.com/questdb/questdb/commit/95b8095427c4e2c781... What were the options back in 2014? C++? Too complicated. C? Too low-level. Pretty much anything else? Either too slow or too exotic.

2. Technical: Java, even without GC or WORA, still offers some advantage. 2a: The tooling is robust, especially when compared to C++. This starts with build systems (don't get me started on CMake!), and extends to aspects like observability. Stacktraces in Java are taken for granted. What's the state of stacktrace walking/printing in C++? I think it boils down to either Boost, C++23, or some other form of black magic. (I might be wrong here tho) 2b: It's a simpler language, especially when compared to C++ or even Rust. This makes it easier to hire people and also attracts external contributors: https://github.com/questdb/questdb/graphs/contributors 2c: The HotSpot JIT still provides us with solid peak performance without having to mess with PGO, etc. 2d: Concurrency is easier with Java's managed memory, eliminating the need for hazard pointers and the like.

What do you use as a build system for Java? We use ant (old, ugly, reliable) and gradle (new, nice looking and absolutely horrible to maintain)

Maven, see the rust-maven-plugin we wrote for this. It's opensource.

Looks like they have an interesting range of customers[0] so my take on "why even add the Rust" is because their customers are already using Java, a total rewrite might be considered irresponsible as it would be incompatible with their existing customer base. I do have to wonder though, if some serious Java refactoring in any way, would have helped at all. How many code smells do they have going on in their codebase? Or is it to the best of their knowledge a really clean Java codebase?

Note Discord themselves has used Rust for bottlenecks with Erlang/Elixir/Beam[1].

[0]: https://questdb.io/customers/

[1]: https://discord.com/blog/using-rust-to-scale-elixir-for-11-m...

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.

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.

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

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.

While they do present a reasonable explanation for needing to use a different language I do agree it seem painful and the type of decision that will lead to a follow-up article in a few year: "Why we're ripping out Rust".

In some sense it reads a lot like they just needed an excuse to use Rust. Not that Rust is a bad choice for the areas they list as possible candidates for non-java code, it's just a really odd choice for Java shop, but then again, so is fighting the GC.

It is incredible fascinating work though.

Reply on news.ycombinator.com