Make a list of "must-have" language ecosystem features

[rrthomas]

• Floating point instructions
• Indexed/stack loads/stores?
• Automatic semver APIs (Elm)
• Automatic SIMD/multi-core distribution of matrix operations (TensorFlow)
• Lightweight packaging (go/npm) without mandatory centralisation
• Unicode, l18n
• a11y
• run-time code generation
• gradual typing
• containers, including immutable
• at least green threads
• runs in the browser and not in the browser

[apt1002]

In a recent email I wrote:

I've been Thinking about what properties a virtual machine should have in order to be usefully composable with other virtual machines. In The Future, it will be increasingly rare to run programs on bare metal. The default assumption, when optimizing, is that your virtual machine will be inside some other virtual machine. Therefore, there are features of the host that I think a virtual machine really ought to expose, because otherwise somewhere in the stack there will be a big efficiency penalty. My list is something like this:

• Some sort of memory management
• Concurrency, including timers and the concept of being idle
• Parallelism
• A way of  generating new host code (e.g. a JIT compiler)
• A way of generating new  virtual code at runtime (for nested VMs)
• Many "registers", i.e. unaliased storage locations
• Dense arrays of primitive types (e.g. byte, int and float arrays)
• A bunch of accelerators, e.g. memcpy, graphics, codecs, FFT, linpack
• Maybe mmap/mprotect and associated signal handlers?

Admittedly this is a pretty tall order. I don't know of even one VM which supports all of these features. The JVM and e.g. VMWare get close.

My email has a narrower focus than this issue; it is about making virtual machines efficiently composable. Nonetheless, @rrthomas pointed out that the lists are similar. Some of the differences can even be explained as random omissions. Let's run through the latter list.

• Floating point - this is another example of an accelerator, which should be in both lists
• Indexed/stack loads/stores? - I'm not sure what this means, sorry.
• Automatic semver APIs (Elm) - Difference
• Automatic SIMD/multi-core distribution of matrix operations (TensorFlow) - Python views this as an accelerator, which is therefore in both lists. However, perhaps you could argue that the JIT compiler should be using these techniques automatically. In that case I omitted "data parallelism" from my list.
• Lightweight packaging (go/npm) without mandatory centralisation - Difference
• Unicode, l18n - Difference
• a11y - Difference
• run-time code generation - in both lists
• gradual typing - Difference
• containers, including immutable - (I think you mean "collections", i.e. data structures?) Difference
• at least green threads - in both lists ("concurrency")
• runs in the browser and not in the browser - That's a special case of the whole premise of my list.

And now let's run through the former list. I can't speak for @rrthomas here so I'll keep my comments tentative.

• Memory management - An omission?
• Concurrency - in both lists ("green threads")
• Parallelism - An omission?
• A way of generating new host code - An omission? Or an implementation detail that is out of your scope?
• A way of generating new virtual code at runtime - in both lists ("run-time code generation")
• Many "registers", i.e. unaliased storage locations - Difference
• Dense arrays of primitive types (e.g. byte, int and float arrays) - Difference
• A bunch of accelerators, e.g. memcpy, graphics, codecs, FFT, linpack - Difference
• Maybe mmap/mprotect and associated signal handlers? - Difference

The differences mostly come down to a difference of focus. For example, "semver", "unicode" and "ally" have no effect on the composability of virtual machines, so do not belong on my list, whereas "registers", "dense arrays" and "JIT compiler" are implementation details that do not belong on a list of language features.