[lowbloodsugar]

Recently ran a benchmark against Rust and Java for a particular aspect of our code. The Rust completed in less time, using one thread. Java required twice the time, twice the memory, and thirty five threads. Even if your GC isn't pausing, it's still using as many CPUs as it can to trash your d-cache looking for objects to GC.

[Johanx64]

Rust takes an absolute eternity to compile code.

On that count alone I would never-ever consider it in hobby/games project of any sort.

It doesn't matter what features a programming language has, if it takes seconds if not minutes to compile even relatively small projects (less than 50-100k LoC).

[lowbloodsugar]

That is genuinely one of our dilemmas. The product makes enough to spend an extra 20x on machines (and it scales horizontally). So does the impact to developer productivity of Rust offset the 20x cost savings? New features mean new $$$, and more than enough to offset the extra runtime cost of Java.

Personally, I'm now doing hobby projects in Rust because it just feels right. But I've done entire systems in assembly, so I am a bit of a control freak. YMMV.

[3836293648]

Why are you doing a clean build? You can't complain about the difference against binary dependencies if you're manually flushing the cache of built dependencies.

And if you're not doing that, you're either wrong, or have a terrible project structure (comparable to including literally every header in every source file in C++)

[akavel]

Isn't compilation time in a roughly similar ballpark for C++? Which is kinda... "quite often" used in games projects? Not sure how much in hobby ones though, if that's what is being discussed here, but I'm somewhat confused (hobby/games sounds like speaking about an either-or alternative?)

[pjmlp]

Kind of, C++ profits that the ecosystem embraces binary libraries, so usually you only have to care about your own code.

Then if you are using modern C++ tooling like Visual Studio, you can make use of hot code reload.

Here are examples in Visual Studio, and Unreal.

https://www.youtube.com/watch?v=x_gr6DNrJuM

https://www.youtube.com/watch?v=XN1c1V9wtCk

[bzzzt]

The only thing your benchmark proves is your Java could was not as optimized as well as your Rust code. Java has overhead, but certainly not two orders of magnitude.

[lowbloodsugar]

Our use case is definitely a pathologically bad problem for Java's GC. Nevertheless, it is a real use case, and CPU and GC are the primary impacts to our service.

[bzzzt]

You mean you're actually seeing 90% GC overhead and are not looking to improve on that? (like by tuning the GC or changing your implementation). GC impact on normal behaving applications should be less than a few percent, so you're not comparing Rust and Java, but Rust and badly written/tuned Java - which doesn't say anything about the maximum attainable performance.

[pjmlp]

Because you were comparing Apples to Oranges.

Now try that against D, any .NET language, Nim, Swift, Go, or any other GC language that supports value types and unsafe programming.

[wsc981]

Swift is technically not a language with GC I believe. It's probably using reference counting like Objective-C before.

[pjmlp]

Reference counting is a GC algorithm, despite urban knowledge that describes it as otherwise.

Chapter 5 on the "The Garbage Collection Handbook",

https://gchandbook.org/contents.html

Or if you prefer chapter 2 on "Uniprocessor Garbage Collection Techniques" https://www.cs.cmu.edu/~fp/courses/15411-f08/misc/wilson94-g...

Plenty of SIGPLAN papers about the subject.

Despite all marketing talk, the real reason why Swift went with ARC was easier interoperability with Objective-C, otherwise Apple would need to build something like .NET's RCW/CCW for COM interop on Windows, which follows the same concept as Cocoa's retain/release calls.