Skip to main content
Post Closed as "Needs details or clarity" by Alexis King
Question Protected by Michael Homer
edited tags
Link
Seggan
  • 3.4k
  • 12
  • 47
Post Reopened by The Thonnu, чистов_n, SK-logic, FireTheLost, Bbrk24
Left closed in review as "Original close reason(s) were not resolved" by mousetail, Isaiah, lyxal
Post Closed as "Needs details or clarity" by Alexis King
Became Hot Network Question
added 12 characters in body
Source Link
Seggan
  • 3.4k
  • 12
  • 47

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 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 of this, with the most notable languages targeting it being Kotlin, Scala, Groovy, and Clojure. JVM is not the only one, with several 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 it wasthey were designed for use with multiple languages

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 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 of this, with the most notable languages targeting it being Kotlin, Scala, Groovy, and Clojure. JVM is not the only one, with several 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 could fit here too, but it was designed for use with multiple languages

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 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 of this, with the most notable languages targeting it being Kotlin, Scala, Groovy, and Clojure. JVM is not the only one, with several 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

Source Link
Seggan
  • 3.4k
  • 12
  • 47

Why target an existing VM?

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 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 of this, with the most notable languages targeting it being Kotlin, Scala, Groovy, and Clojure. JVM is not the only one, with several 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 could fit here too, but it was designed for use with multiple languages