I've developed a few VMs and each was always tied to a specific language or one of its close relatives. The advantages of having a VM is that it's a lot easier to compile to than native code, you can run it on any hardware for which an interpreter has been written, and its object code is a lot smaller. The disadvantage is that the compiled code runs slower.

The exception is when someone wants their language to run on an existing VM, e.g. for Java or to run in a web browser, so they compile it to the VM's instruction set. Various languages are compiled onto the JVM, and the same WebAssembly code has to run on any hardware onto which the containing web page has been downloaded, and will run faster than the equivalent JavaScript.

Yes, that is how most mainframes used to work, having a kind of common language environment.

Then the applications are either JITed at installation time, or the CPUs are micro-coded, JITing the applications during execution.

Burroughs (now Unisys), Xerox PARC machines, ETHZ systems, IBM mainframes.

> If you manage to fit two languages, then you're essentially writing the same language in two different syntaxes.

Counterexample: the JVM, which runs quite a few languages, including some that were created without any consideration thereof (python, ruby, lisp, perl).

Yeah I think the JVM is a special because of Hotspot -- a state-of-the-art JIT compiler.

I'm pretty sure that without a JIT you will not get decent performance on compiling one language to a VM designed for another language.

Also, I think the JVM "required" at least one modification for dynamic languages? I recall something about JRuby and invokedynamic bytecode, but I don't know the details:

https://www.infoq.com/articles/Invokedynamic-Javas-secret-we...

As another counterexample, I've heard that VB.NET is just C# in a different syntax, more than it is VB6. That is, when it moved to the CLR, the language changed.

VB.NET is more like VB6 than C#. The problems with the vocal minority in the VB6 community not moving to VB.NET had mostly nothing directly to do with the CLR.

(The break in backwards compatibility, and inability to just "upgrade" old code, in a language that hadn't a major break since VB3 was more impactful, I think. That was more due to the VB team trying to clean house and remove anti-patterns than the CLR's fault.)

The CLR has just as many languages, including dynamic languages, supported as the JVM.

VB.NET is shaped like the CLR, just like C#. (Similarly, Java is shaped like the JVM.) It is possible to mechanically transform VB.NET code into C# code. Heck, I'd bet they both parse to the same AST. They are very, very similar languages, with the exception of syntax.

The upshot is that writing VB.NET involves understanding everything you need to understand to write C#. All the syntax is VB6-flavoured, sure, but it still involves making people learn about classes, this year's flavour of Windows UI components, and so on.

What's more, you have to do it all in an industrial-strength IDE, with all the complexity that brings. (Don't get me wrong - Visual Studio is more or less my gold standard for a usable industrial-strength IDE. But if you stand it next to VB6, you'll see how much more you need to understand just to get to editing code is noticeably larger. It can be invisible to people like you or me, who have already absorbed these concepts, but it's real.)

VB1-6 encouraged classes. The fact that OO was not more popular in VB was a failure to communicate. VB.NET didn't add classes, it removed the anti-pattern that was grab-bag modules. Again, that's much more of a backwards compatibility problem than a CLR problem. The VB team could have kept modules and still targeted the CLR, they just chose not to in the hopes of cleaning up some of the worst patterns in VB.

Just because you can "mechanically transform" code between two languages doesn't make them the same language. Compilation is a mechanical transformation to machine code, but you don't see anyone arguing C++ is the same language as Assembly.

(Did you ever look at the output of such mechanical transformations? The results were always weird, lacking proper idioms in the target language. Just like machine translations of spoken languages, I wouldn't rely on them without a lot of work to clean them up and verify them.)

Yes, VB.NET and C# share many (but not all!) components of the same AST, but so too now does F# as it is being brought over to the Roslyn compiler platform. Shared AST components also do not make a language "the same", because of that fun word "abstract" in AST. Just as most languages can be described in a BNF variant, fall into some variation of the category Context-Free Grammar, represent similar Pushdown Automata, etc. The underlying tools are very much the same across the vast spectrum of languages, but that doesn't mean all languages are the same/interchangeable.

Also, Visual Studio is a direct successor to the VB6 IDE. Visual Studio .NET shared a lot of code with that IDE. I'd be surprised if VS today didn't have at least some code inherited down the many years from that predecessor (certainly plenty of ghosts of it in source control). The VB6 IDE was considered "industrial-strength" in its time, too.

Given there's a free Community Edition of Visual Studio, and VB6 was never cheap, arguably the barriers to new developers to "just get to editing code" are at the lowest they've ever been, complexity or not. (Nostalgia is a weird fuzzy thing.)

> If you manage to fit two languages, then you're essentially writing the same language in two different syntaxes.

Example: Elixir and Erlang on BEAM VM

Hi, Viua VM's developer here.

Sure, compiling a language to a VM with mismatched semantics is not a pleasant experience. Viua's execution model of many processes communicating via messages is best suited to Erlang, or other actor model languages.