<p>Most interpreted languages use a virtual machine internally, to speed up performance. This is achieved by having an internal compiler compile the code (usually with minimal optimization and maximum speed) and send it over to a VM to be executed. Usually the bytecode goes directly from the compiler to the VM to be executed, but some languages like Python <a href="https://stackoverflow.com/questions/16869024/what-is-pycache">cache</a> the bytecode for repeated runs. Most famously, Java distinctly separates the compilation and execution phases, requiring you to compile and run separately.</p>
<p>Some languages, instead of using their own internal virtual machine, compile to target another virtual machine instead. Again, the Java Virtual Machine is the most famous <a href="https://en.wikipedia.org/wiki/List_of_JVM_languages" rel="nofollow noreferrer">example</a> of this, with the most notable languages targeting it being Kotlin, Scala, Groovy, and Clojure. JVM is not the only one, with <a href="https://github.com/hengestone/lua-languages#compile-to-bytecode" rel="nofollow noreferrer">several</a> languages compiling to Lua bytecode, and I've heard of a few compiling to Python bytecode.<sup>1</sup></p>
<p>Languages targeting other language's VMs have to deal with ABI instability, lack of documentation (with the previous two points again not holding true for the JVM), and the fact that VMs are typically tailored to the source language. Given all that, why would you want to target another language's VM?</p>
<p><sup>1</sup><sub>Technically, the CLR and LLVM could fit here too, but they were <em>designed</em> for use with multiple languages</sub></p>

<virtual-machine>
Why target an existing VM?
CC BY-SA 4.0
2023-07-21T14:23:43.010Z
I feel like a lot of the same reasons apply for using an existing backend (e.g. LLVM) for a compiled language.
Bbrk24
CC BY-SA 4.0
2023-07-21T14:24:26.193Z
@Bbrk24 but those don't have to deal with ABI instability, lack of documentation, and the fact that VMs are typically tailored to the source language
Seggan
CC BY-SA 4.0
2023-07-21T20:36:05.990Z
This is tagged "history", but nothing in the body or title of the question suggests anything related to history. What are you intending this to be?
Michael Homer
CC BY-SA 4.0
2023-07-21T22:37:28.950Z
I think this question is too broad. The reasons to compile to a VM specifically designed to supports lots of different languages (like the JVM/CLR) are totally different from the reasons to target a VM that is essentially just a runtime for a specific language.
Alexis King
CC BY-SA 4.0
2023-07-22T02:29:00.757Z
@AlexisKing the JVM was *not* designed for multiple languages, and I explicitly excluded the CLR
Seggan
CC BY-SA 4.0
2023-07-22T02:33:18.213Z
@MichaelHomer as in decisions made by prior languages concerning this
Seggan
CC BY-SA 4.0
2023-07-22T02:37:01.450Z
@Seggan-OnStrike Ok, but it doesn't. actually... *ask* that anywhere, and as you can see none of the answers have read that into it either. I see the tag is there, but it doesn't currently describe the question itself.
Michael Homer
CC BY-SA 4.0
2023-07-22T06:24:53.547Z
"Given all that, why would you want to target another language's VM?" - *what alternative are we contrasting this with*? Compiling to native code? Creating a new VM specific to the language? Something else?
Karl Knechtel
CC BY-SA 4.0
2023-07-22T12:56:30.580Z
@KarlKnechtel when I wrote this, I had the latter in mind
Seggan
CC BY-SA 4.0
2023-07-22T16:17:21.533Z
@Seggan-OnStrike It is true the JVM was not originally designed to support multiple languages, but that’s not really true anymore.
Alexis King
CC BY-SA 4.0
2023-07-26T13:12:29.850Z
@MichaelHomer I have removed it
Seggan
CC BY-SA 4.0
2023-07-26T18:40:07.747Z
Rustlang has, IIRC, ~[176 different](https://doc.rust-lang.org/nightly/rustc/platform-support.html) supported [target triples](https://wiki.osdev.org/Target_Triplet). A language targeting a VM has **one** (or at most a few).
Jared Smith
CC BY-SA 4.0
2023-07-29T11:21:18.710Z
Java is old and the first versions of the VM and the compiler were very slow.  It was a natural step - especially for a Unix company - to optimize this into two stages.  These days, you can execute a single source file directly.
Thorbjørn Ravn Andersen
CC BY-SA 4.0
2023-07-31T20:51:47.617Z
Despite being closed and reopened, I believe so strongly that this question ought to be closed (and have reached some consensus about this with several fellow users in chat) that I am going to close it again. [For the sake of transparency, I have posted my reasoning on meta.](https://langdev.meta.stackexchange.com/a/574) Please feel free to weigh in there if you disagree.
Alexis King
CC BY-SA 4.0
2023-12-02T18:17:09.683Z
Because then anyone who has their VM can also run your code.
CPlus
<h2>Interoperability</h2>
<p>When targeting an existing VM, your language can now be mixed with all the existing languages that target that VM.</p>
<h2>Libraries</h2>
<p>All the existing libraries for these languages can also be reused.</p>
<p>Maybe you also get to reuse package managers for these libraries.</p>
<h2>Tooling</h2>
<p>You get to reuse any existing tooling that works at the VM bytecode level. For example, profilers, decompilers, debugggers, code injectors, analyzers...</p>

CC BY-SA 4.0
2023-07-21T22:19:48.693Z
2023-07-21T22:19:48.693Z
Eldritch Conundrum
<p>One big one is that people are more likely to have that VM installed already. The thing with languages that compile to bytecodes is the user has to install the VM/runtime; if you piggyback off Java with its [googles] 5.5 billion devices, not only do you save the work of having to implement and optimize your own VM, you save the work of having to host and package it, and your users save the work of having to install it (or the disk space/time of having it installed automatically).</p>

CC BY-SA 4.0
2023-07-21T14:50:16.327Z
2023-07-21T15:02:24.217Z
2023-07-21T15:02:24.217Z
rydwolf
<h2>Why re-invent the wheel?</h2>
<p>To summarize many good points already addressed in detail in the other answers:</p>
<ol>
<li><p>A virtual machine (such as Java VM) exists, is often well-understood, and (possibly) well-documented.</p>
</li>
<li><p>Compiling to a virtual machine is often simpler than compiling to a particular hardware architecture (most VMs are stack machines), and...</p>
</li>
<li><p>The virtual machine will run on a large variety of actual processor architectures, operating systems, etc.</p>
</li>
<li><p>The virtual machine will likely be a well-developed and well-tested piece of software, with good run-time (JIT) optimization, a built-in garbage collector, exception handling, and many other useful features.</p>
</li>
<li><p>Interoperability with libraries written for the same VM is obviously a very welcome feature!</p>
</li>
</ol>
<p>In short, VMs exist, they work well, they have many useful and well-developed features – so why not make good use of them? Why reinvent the wheel?</p>

CC BY-SA 4.0
2023-07-25T02:58:20.780Z
2023-07-25T02:58:20.780Z
printf
CC BY-SA 4.0
2023-07-25T06:58:05.020Z
IMO this is *the biggest* reason
Criticize SE actions means ban
<p>Other people have already said things like this, but I wanted to give some specific examples.</p>
<p><a href="https://kotlinlang.org/" rel="nofollow noreferrer">Kotlin</a> targets the JVM, which means Kotlin can load Java jars (and vice versa).  Apparently it's even easy to convert a Java codebase into Kotlin piecemeal because you can have both languages in the same project.</p>
<p>Powershell can load .NET DLLs, which makes it easy to write cmdlets in C# and use them in Powershell.</p>
<p><a href="https://www.jython.org/" rel="nofollow noreferrer">Jython</a> is interesting.  It's Python that runs in the JVM, which, again, enables interoperability between the two languages.</p>
<p>Because you get this increased interoperability, it also makes it easier for people to adopt your language.  A Java shop is going to be a lot more willing to try Kotlin than a completely unrelated language.  There are other ways to support transitioning from one language to another, but targeting the same VM can make a big difference.</p>

CC BY-SA 4.0
2023-07-27T05:03:05.817Z
2023-07-27T05:03:05.817Z
Blarghedy
<p>Well, <a href="https://aecforwebassembly.sourceforge.io/" rel="nofollow noreferrer">the compiler for my programming language</a> targets WebAssembly because WebAssembly is designed to be an extremely easy compilation target. And lack of documentation and ABI instability are not a problem for the WebAssembly virtual machine.</p>

CC BY-SA 4.0
2023-07-24T12:08:12.507Z
2023-07-24T12:08:12.507Z
FlatAssembler
<p>It is often easier to compile to a vm's bytecode than it is to compile to native machine code. And the VM is likely to have good JIT optimization. This means that you don't have to deal with optimization in the compiler.</p>
<p>Targeting a VM also means that you have a compile once, run everywhere option assuming there is a VM implemented for each platform you intend to run it on. In other words the ABI tends to be consistent across different platforms but not necessarily across time.</p>

CC BY-SA 4.0
2023-07-21T14:25:18.287Z
2023-07-21T14:25:18.287Z
ratchet freak
# Why target an existing VM?
Posted by: username_0 on 2023-07-21
Most interpreted languages use a virtual machine internally, to speed up performance. This is achieved by having an internal compiler compile the code (usually with minimal optimization and maximum speed) and send it over to a VM to be executed. Usually the bytecode goes directly from the compiler to the VM to be executed, but some languages like Python [cache](https://stackoverflow.com/questions/16869024/what-is-pycache) the bytecode for repeated runs. Most famously, Java distinctly separates the compilation and execution phases, requiring you to compile and run separately.

Some languages, instead of using their own internal virtual machine, compile to target another virtual machine instead. Again, the Java Virtual Machine is the most famous [example](https://en.wikipedia.org/wiki/List_of_JVM_languages) of this, with the most notable languages targeting it being Kotlin, Scala, Groovy, and Clojure. JVM is not the only one, with [several](https://github.com/hengestone/lua-languages#compile-to-bytecode) languages compiling to Lua bytecode, and I've heard of a few compiling to Python bytecode.1

Languages targeting other language's VMs have to deal with ABI instability, lack of documentation (with the previous two points again not holding true for the JVM), and the fact that VMs are typically tailored to the source language. Given all that, why would you want to target another language's VM?

1Technically, the CLR and LLVM could fit here too, but they were *designed* for use with multiple languages
**Tags:** virtual-machine
> **Comments:**
> **username_1**: I feel like a lot of the same reasons apply for using an existing backend (e.g. LLVM) for a compiled language.  
> **username_0**: @Bbrk24 but those don't have to deal with ABI instability, lack of documentation, and the fact that VMs are typically tailored to the source language  
> **username_2**: This is tagged "history", but nothing in the body or title of the question suggests anything related to history. What are you intending this to be?  
> **username_3**: I think this question is too broad. The reasons to compile to a VM specifically designed to supports lots of different languages (like the JVM/CLR) are totally different from the reasons to target a VM that is essentially just a runtime for a specific language.  
> **username_0**: @AlexisKing the JVM was *not* designed for multiple languages, and I explicitly excluded the CLR  
> **username_0**: @MichaelHomer as in decisions made by prior languages concerning this  
> **username_2**: @Seggan-OnStrike Ok, but it doesn't. actually... *ask* that anywhere, and as you can see none of the answers have read that into it either. I see the tag is there, but it doesn't currently describe the question itself.  
> **username_4**: "Given all that, why would you want to target another language's VM?" - *what alternative are we contrasting this with*? Compiling to native code? Creating a new VM specific to the language? Something else?  
> **username_0**: @KarlKnechtel when I wrote this, I had the latter in mind  
> **username_3**: @Seggan-OnStrike It is true the JVM was not originally designed to support multiple languages, but that’s not really true anymore.  
> **username_0**: @MichaelHomer I have removed it  
> **username_5**: Rustlang has, IIRC, ~[176 different](https://doc.rust-lang.org/nightly/rustc/platform-support.html) supported [target triples](https://wiki.osdev.org/Target_Triplet). A language targeting a VM has **one** (or at most a few).  
> **username_6**: Java is old and the first versions of the VM and the compiler were very slow.  It was a natural step - especially for a Unix company - to optimize this into two stages.  These days, you can execute a single source file directly.  
> **username_3**: Despite being closed and reopened, I believe so strongly that this question ought to be closed (and have reached some consensus about this with several fellow users in chat) that I am going to close it again. [For the sake of transparency, I have posted my reasoning on meta.](https://langdev.meta.stackexchange.com/a/574) Please feel free to weigh in there if you disagree.  
> **username_7**: Because then anyone who has their VM can also run your code.  
---
## 6 answers
### Answer by username_14 on 2023-07-21. Score: 11
It is often easier to compile to a vm's bytecode than it is to compile to native machine code. And the VM is likely to have good JIT optimization. This means that you don't have to deal with optimization in the compiler.

Targeting a VM also means that you have a compile once, run everywhere option assuming there is a VM implemented for each platform you intend to run it on. In other words the ABI tends to be consistent across different platforms but not necessarily across time.
---
### Answer by username_8 on 2023-07-21. Score: 8
## Interoperability

When targeting an existing VM, your language can now be mixed with all the existing languages that target that VM.

## Libraries

All the existing libraries for these languages can also be reused.

Maybe you also get to reuse package managers for these libraries.

## Tooling

You get to reuse any existing tooling that works at the VM bytecode level. For example, profilers, decompilers, debugggers, code injectors, analyzers...
---
### Answer by username_9 on 2023-07-21. Score: 8
One big one is that people are more likely to have that VM installed already. The thing with languages that compile to bytecodes is the user has to install the VM/runtime; if you piggyback off Java with its [googles] 5.5 billion devices, not only do you save the work of having to implement and optimize your own VM, you save the work of having to host and package it, and your users save the work of having to install it (or the disk space/time of having it installed automatically).
---
### Answer by username_10 on 2023-07-25. Score: 8
## Why re-invent the wheel?

To summarize many good points already addressed in detail in the other answers:

1. A virtual machine (such as Java VM) exists, is often well-understood, and (possibly) well-documented.
2. Compiling to a virtual machine is often simpler than compiling to a particular hardware architecture (most VMs are stack machines), and...
3. The virtual machine will run on a large variety of actual processor architectures, operating systems, etc.
4. The virtual machine will likely be a well-developed and well-tested piece of software, with good run-time (JIT) optimization, a built-in garbage collector, exception handling, and many other useful features.
5. Interoperability with libraries written for the same VM is obviously a very welcome feature!

In short, VMs exist, they work well, they have many useful and well-developed features – so why not make good use of them? Why reinvent the wheel?
> **Comments:**
> **username_11** (2023-07-25): IMO this is *the biggest* reason  
---
### Answer by username_12 on 2023-07-27. Score: 3
Other people have already said things like this, but I wanted to give some specific examples.

[Kotlin](https://kotlinlang.org/) targets the JVM, which means Kotlin can load Java jars (and vice versa). Apparently it's even easy to convert a Java codebase into Kotlin piecemeal because you can have both languages in the same project.

Powershell can load .NET DLLs, which makes it easy to write cmdlets in C# and use them in Powershell.

[Jython](https://www.jython.org/) is interesting. It's Python that runs in the JVM, which, again, enables interoperability between the two languages.

Because you get this increased interoperability, it also makes it easier for people to adopt your language. A Java shop is going to be a lot more willing to try Kotlin than a completely unrelated language. There are other ways to support transitioning from one language to another, but targeting the same VM can make a big difference.
---
### Answer by username_13 on 2023-07-24. Score: -1
Well, [the compiler for my programming language](https://aecforwebassembly.sourceforge.io/) targets WebAssembly because WebAssembly is designed to be an extremely easy compilation target. And lack of documentation and ABI instability are not a problem for the WebAssembly virtual machine.
---
