4 ms·

See also https://jacobin.org/ https://jacobin.org/ for JVM 17 written in Go.

xmcqdpt2 3y ago
Also https://github.com/lihaoyi/Metascala https://github.com/lihaoyi/Metascala for a JVM implemented in Scala running on the JVM.
- dimgl 3y ago
  Seems… redundant, no?
  - cmrdporcupine 3y ago
    "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.
    - RcouF1uZ4gsC 3y ago
      I seriously doubt the ratio of Scala vs C++ for implementing the JVM is 1:300.
      - patrec 3y ago
        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.
        RcouF1uZ4gsC 3y ago
        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.
        eindiran 3y ago
        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.
        valenterry 3y ago
        Probably not, because JVM users are much more likely to be more proficient in Scala/Java than in C++.
      - cempaka 3y ago
        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.
        cmrdporcupine 3y ago
        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.
        xmcqdpt2 3y ago
        It's mostly GC and JIT and a huge amount of corner case interactions between them. And also the many supported instruction sets.
  - dgb23 3y ago
    apply eval
  - mike_hearn 3y ago
    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.
    - bfrog 3y ago
      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.
      - mike_hearn 3y ago
        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.
leshow 3y ago
That is a very interesting name for a programming project lol. The Jacobins were a revolutionary political club during the French Revolution in the 1790's. It's also the name of a magazine at https://jacobin.com https://jacobin.com
- snordgren 3y ago
  It's starts with the letters "ja", that's all that matters for a Java-related project.

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

dimgl 3y ago
Seems… redundant, no?
- cmrdporcupine 3y ago
  "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.
  - RcouF1uZ4gsC 3y ago
    I seriously doubt the ratio of Scala vs C++ for implementing the JVM is 1:300.
    - patrec 3y ago
      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.
      - RcouF1uZ4gsC 3y ago
        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.
        eindiran 3y ago
        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.
        valenterry 3y ago
        Probably not, because JVM users are much more likely to be more proficient in Scala/Java than in C++.
    - cempaka 3y ago
      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.
      - cmrdporcupine 3y ago
        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.
      - xmcqdpt2 3y ago
        It's mostly GC and JIT and a huge amount of corner case interactions between them. And also the many supported instruction sets.
- dgb23 3y ago
  apply eval
- mike_hearn 3y ago
  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.
  - bfrog 3y ago
    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.
    - mike_hearn 3y ago
      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.

leshow 3y ago

That is a very interesting name for a programming project lol. The Jacobins were a revolutionary political club during the French Revolution in the 1790's. It's also the name of a magazine at https://jacobin.com https://jacobin.com

snordgren 3y ago
It's starts with the letters "ja", that's all that matters for a Java-related project.