4 ms·

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

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.

vbezhenar 3y ago
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.
- nu11ptr 3y ago
  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.
  - Quekid5 3y ago
    > 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.)
    - gpderetta 3y ago
      how do you prevent use-after-free with a wrapper?
      - ElectricalUnion 3y ago
        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.
    - nu11ptr 3y ago
      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.
      - Quekid5 3y ago
        > 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.
bluestreak 3y ago
Java tooling was excellent back when QuestDB was started and still is excellent today compared to C++.
wizerdrobe 3y ago
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.

vbezhenar 3y ago

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.

nu11ptr 3y ago
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.
- Quekid5 3y ago
  > 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.)
  - gpderetta 3y ago
    how do you prevent use-after-free with a wrapper?
    - ElectricalUnion 3y ago
      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.
  - nu11ptr 3y ago
    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.
    - Quekid5 3y ago
      > 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.

bluestreak 3y ago

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

wizerdrobe 3y ago

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.