Hacker News Reader

Comment by xmcqdpt2 | Hacker News Reader

Also https://github.com/lihaoyi/Metascala for a JVM implemented in Scala running on the JVM.

Seems… redundant, no?

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.

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.

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.

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

"The goal of Metascala is to create a platform to experiment with the JVM: a 3000 line JVM written in Scala is probably much more approachable than the 1,000,000 lines of C/C++ "

Seems like a reasonable goal.

I seriously doubt the ratio of Scala vs C++ for implementing the JVM is 1:300.

He's not saying that. What he is saying is that are simple, non-production quality implementation in Scala is much more amenable to experimentation than a sophisticated, production-quality implementation in C++ that weighs in at 300x the LOC.

But a simple non-production quality implementation in C++ would also be amenable to experimentation and not have the bootstrapping issues as well as provide an easier starting point to incorporate more of the existing optimizations as desired.

Probably not, because JVM users are much more likely to be more proficient in Scala/Java than in C++.

That is true, but the author of Metascala wanted to write it in Scala. Other people are free to write a simple C++ implementation of the JVM themselves.

I'm sure it's not complete, but I also wouldn't be surprised if 99% of what's in HotSpot is optimization tweaks and performance boosts which aren't essential to the JLS.

It's also unclear to me if the architectural assumptions made in GC & VM engineering 20 years ago still apply today. I'm not an expert in this field, so take with a grain of salt... but I do wonder if a VM engineered from the ground-up today targeting recent ISAs would look substantially different.

It's mostly GC and JIT and a huge amount of corner case interactions between them. And also the many supported instruction sets.

apply eval

Reply on news.ycombinator.com