3 ms·

No, you really can. You can use GC crates and the performance will be like Java, or you can use Rc and the performance will be like Swift. The only reason Rust

No, you really can. You can use GC crates and the performance will be like Java, or you can use Rc and the performance will be like Swift. The only reason Rust people use unsafe for data structures (and they do not always do) is that for them, Java/Swift-level performance is just not enough.

pron 3mo ago
> No, you really can. You can use GC crates and the performance will be like Java It won't be anywhere near Java's. Those GCs are mark-and-sweep collectors. Java uses moving collectors. Moving collectors are used to avoid the high overheads of malloc/free in the C runtime (or of any free-list-based mechanism). They're a performance optimisation. Heap allocations in Java behave more like arenas than like heap allocations in languages with non-moving memory management, whether it's C, Rust, Python, or Go. Other runtimes that use moving collectors are Google's V8 and Microsoft's .NET, except that Java's ZGC has no GC pauses.
- afdbcreid 3mo ago
  I'm well aware. I don't know a moving GC crate for Rust, but I do know that building a safe moving GC crate for Rust is possible, using the same principles as existing GC crates. It will not be exactly as performant as Java, because you don't have compiler support for updating pointers, but it will almost be - pointers inside the data structures can be updated via derive, the only pointer that cannot is the pointer to the data structure itself, so you will need to heap-allocate the data structure (the GC root). Given that in Java everything is under indirection anyway, this will have the same efficiency or even better.
  - pron 3mo ago
    > I don't know a moving GC crate for Rust, but I do know that building a safe moving GC crate for Rust is possible, using the same principles as existing GC crates. But those pointers would not interoperate easily with code that does not expect them. Of course you could effectively "host" a moving GC world inside Rust (or C++, or C), just as you could host the entire JVM in a Rust program (or vice-versa, host a Rust program in a Java program), but the effectiveness and attractiveness of that depends on interoperability with existing libraries. Java's FFM also lets you bring your own memory management strategies, but the interop with existing types is not transparent (i.e. while you can put a manually-managed object that implements a Map or a List interface in the manually-managed portion, you cannot let that Map or List store arbitrary Java objects). So there can be interfaces that connect a world of moving pointers and a world of non-moving ones (that's what FFM is), but then the interop between them is pretty much the same as FFM, i.e. the interface between Java and C. That's not really "in the same language". > Given that in Java everything is under indirection anyway, I don't know what that means. References in Java are implemented as pointers (some GCs use free bits for some stuff). Maybe you mean that Java doesn't yet have types that are flattened into their container, but it will soon: https://openjdk.org/jeps/401 https://openjdk.org/jeps/401 (this is only the first step). Indeed, that was the last gap that could still allow me to match or beat Java's performance even in some large programs (provided they matched a domain where this was important, and there are certainly some). With that gap closing, the number of large programs where I, an experienced C++ programmer, could even match Java's performance without extraordinary effort is getting very, very, very small.

pron 3mo ago

> No, you really can. You can use GC crates and the performance will be like Java It won't be anywhere near Java's. Those GCs are mark-and-sweep collectors. Java uses moving collectors. Moving collectors are used to avoid the high overheads of malloc/free in the C runtime (or of any free-list-based mechanism). They're a performance optimisation. Heap allocations in Java behave more like arenas than like heap allocations in languages with non-moving memory management, whether it's C, Rust, Python, or Go. Other runtimes that use moving collectors are Google's V8 and Microsoft's .NET, except that Java's ZGC has no GC pauses.

afdbcreid 3mo ago
I'm well aware. I don't know a moving GC crate for Rust, but I do know that building a safe moving GC crate for Rust is possible, using the same principles as existing GC crates. It will not be exactly as performant as Java, because you don't have compiler support for updating pointers, but it will almost be - pointers inside the data structures can be updated via derive, the only pointer that cannot is the pointer to the data structure itself, so you will need to heap-allocate the data structure (the GC root). Given that in Java everything is under indirection anyway, this will have the same efficiency or even better.
- pron 3mo ago
  > I don't know a moving GC crate for Rust, but I do know that building a safe moving GC crate for Rust is possible, using the same principles as existing GC crates. But those pointers would not interoperate easily with code that does not expect them. Of course you could effectively "host" a moving GC world inside Rust (or C++, or C), just as you could host the entire JVM in a Rust program (or vice-versa, host a Rust program in a Java program), but the effectiveness and attractiveness of that depends on interoperability with existing libraries. Java's FFM also lets you bring your own memory management strategies, but the interop with existing types is not transparent (i.e. while you can put a manually-managed object that implements a Map or a List interface in the manually-managed portion, you cannot let that Map or List store arbitrary Java objects). So there can be interfaces that connect a world of moving pointers and a world of non-moving ones (that's what FFM is), but then the interop between them is pretty much the same as FFM, i.e. the interface between Java and C. That's not really "in the same language". > Given that in Java everything is under indirection anyway, I don't know what that means. References in Java are implemented as pointers (some GCs use free bits for some stuff). Maybe you mean that Java doesn't yet have types that are flattened into their container, but it will soon: https://openjdk.org/jeps/401 https://openjdk.org/jeps/401 (this is only the first step). Indeed, that was the last gap that could still allow me to match or beat Java's performance even in some large programs (provided they matched a domain where this was important, and there are certainly some). With that gap closing, the number of large programs where I, an experienced C++ programmer, could even match Java's performance without extraordinary effort is getting very, very, very small.