2 ms·
A lot of languages have different implementations targeting different runtimes. For example both Python and Ruby had JVM versions, CLR versions, multiple separa
by jsnell 11y ago
A lot of languages have different implementations targeting different runtimes. For example both Python and Ruby had JVM versions, CLR versions, multiple separate runtimes specifically designed for the language, etc.
What's more rare is a single implementation of a language targeting multiple runtimes. There's Haxe, which has like 10 different targets (and those different targets seem to be the main selling point). Unity uses C# as it's programming language, but also has HTML5 + Javascript export.
The general downside with either of these is that the runtime should actually inform the language design, and vice versa. When you target multiple runtimes, you either have to design the language conservatively such that it only takes advantage of the smalles common subset of features in the runtimes. Or you have to accept that some operations the language nominally supports will be uncomfortable on some of the target runtimes.
As a classic example of the last one, a lot of scripting languages start off with memory management based on reference counting (possibly with some kind of facility for breaking loops automatically). This means that it's very natural for the language to provide deterministic object destruction as soon as the object goes out of scope, and for the library ecosystem to take advantage of that. (Like closing file descriptors when the matching file object goes out of scope). Move to a runtime with a garbage collector, and the finalization becomes non-deterministic. And you either accept the loss of this very convenient feature, you completely cripple the GC based implementation by adding this very expensive extra constraint on top of it, or you allow the two implementations to diverge.