Comment by mike_hearn | Hacker News Reader

Comment by mike_hearn | Hacker News Reader

Parent Full thread

Nope. For a more realistic example of such a JVM, look at SubstrateVM (written in "SystemJava" and compiled to native code ahead of time along with the app it runs), and "Java on Truffle" (a.k.a. Espresso), which is a JVM written in Java designed to be compiled to run on top of SubstrateVM. Both projects are a part of Graal.

The reason to do this, beyond the inherently neat Inception factor, is that JVMs are a PITA to work on because they're normally written in languages like C++ or Rust which optimize for performance and manual control over productivity. That makes it hard to experiment with new JVM features or changed semantics. If you could write a JVM in a high level very productive language like Java (or Kotlin or Scala) then the productivity of people writing and experimenting with JVMs would go up. It would also make it feasible for "ordinary" Java devs to actually fork the JVM and modify it to better suit their app, at least in some cases.

There's also something conceptually cleaner about having a language and its runtime implemented purely in itself. As long as you don't mind the circularity, that is.

Espresso for example has hot-swap features HotSpot doesn't have, so you can modify your program as it's running in more flexible ways than what regular Java allows.

I find that Rust is like maybe 1.5-2x more productive to code in than say C or C++. Part of that is the tooling has so much less arcane baggage, part of that is that I need to reach less for external tools for metaprogramming, part of that is fewer crazy macro/template compiler errors, and part of that is less time spent debugging.

It all adds up.

I've heard very inconsistent things about this, which is interesting. Often people say Rust is less productive, as there's often "makework" involved with satisfying the borrow checker. I suspect a lot of it revolves around how you perceive that sort of thing: it can be cast as both productivity (satisfying it can potentially rule out bugs) or a loss of productivity (you were already satisfied the code was correct).

But I don't have enough experience with Rust to really have formed an opinion on that yet.

There is definitely a hump to get over (maybe you are never fully as "productive" as languages that just let you shoot yourself in the foot, I say as a full-time Go developer for a few years now). Simple, straightforward code is often harder to write. Don't even get me started on stuff that uses async.

But IMO it's very worth it. What do you get out of wrestling with the unholy, fractured C/C++ ecosystem? The privilege of being able to _use other people's code_. You get that without much hassle in Rust.

I'm about 2 years into primarily writing Rust (after a long time in the .NET world).

The borrow checker slowed me down a lot at the start but these days it's not a big deal. Eventually you internalize the easiest ways to make it happy (clone and pass references as needed) and can reserve tricky optimizations for hot paths where they actually matter.

I would say that today, most of the times I sit down to write some Rust I'm nearly as productive as in higher-level languages... but then ~20% of the time I get bogged down in complicated type signature stuff (especially with async code, ugh) and it's a time suck.

Right, its maybe just a little less productive than something like Java because you do have to work out types a bit more and think about memory a bit more. The end benefit tends to be though that... your code compiles, and it just works. So maybe a little more time up front, for, potentially, less time down the road debugging.

And Jikes RVM as well.

Jikes is extremely popular in academia for being the basis of VM research because it is so easy to modify.

https://github.com/JikesRVM/JikesRVM

Reply on news.ycombinator.com