4 ms·

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

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.

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.