[cogman10]

This sort of post really makes me appreciate what's gone into the JVM. A lot of these optimizations are things that the JVM has long implemented. That's not a knock on C# either. Besides the JVM the only other place you'll see these sorts of optimizations are the likes of V8.

It makes me happy to see MS investing in C# like this. I love the notion of having competing VMed languages.

[markjgx]

I was wondering how the JVM and V8 stack up. Do you have a source for that claim? Genuinely curious.

Coming from the game dev world, I’ve grown more and more convinced that managed languages are the right move for most code. My reasoning is simple: most game developers don’t have the time or patience to deeply understand allocation strategy, span usage, and memory access patterns, even though those are some of the most performance-critical and time-consuming parts of programming to get right.

Managed languages hide a lot of that complexity. Instead of explaining to someone, “you were supposed to use this specialized allocator for your array and make sure your functions were array-view compatible”—something that’s notoriously tedious to guarantee in game engines given how few developers even think about array views—you just let developers write code and most of those problems go away.

I’m not saying everything should be managed. Core engine code should still live in the predictable, statically compiled world. But history shows it can work: projects like Jak and Daxter were written primarily in a custom LISPy scripting language, and even Ryujinx (RIP), the excellent Nintendo Switch emulator, is written entirely in C#.

Another strong technical reason is that managed JIT languages can profile at runtime and keep optimizing call sites based on actual usage patterns. Normally, developers would have to do this by hand or rely on PGO, which works but is painful to set up.

Industry standards make this harder to adopt since platforms like Sony still block JIT, but I think this is the direction we should be moving.

[cogman10]

> Do you have a source for that claim? Genuinely curious.

Hmm, no real source for the claim, just a general interest in the two VMs. JVM for work and V8 partially for work. AFAIK, those are two of the VMs that are getting the highest amount of research in due to how they are positioned.

If you want more general information on V8, I suggest reading about the turbofan design docs [1].

The JVM first started doing a lot of these optimizations with Hotspot. Google poached the engineers that did Hotspot and put them to work on V8. That's why the two VMs tend to share similar optimizations.

> I’ve grown more and more convinced that managed languages are the right move for most code.

I tend to agree, to an extent.

The JVM is very fast, but it's also memory hungry and doesn't give up the memory it claims easily. That's due to the nature of the GC algorithms it employs and some historical constraints which bloat object size. One thing you get out of non-gced languages is much lower memory usage and much better live memory density (when done correctly).

[1] https://docs.google.com/presentation/d/1sOEF4MlF7LeO7uq-uThJ...