Java approach: create the JVM to support one language, so it has rich high-level concepts that are unfortunately skewed toward certain assumptions about language design, and it can be reused only for other languages that are similar enough.

WASM approach: start very low-level so C is definitely supported. Thus everything is supported, although every language has to roll its own high-level constructs. But over time more patterns can be standardised so languages can be interoperable within a polyglot WASM app.

In TS this is controllable. If noEmitOnError is true, then any error (including type errors) will stop it emitting JS output.

I think of probability as a summary of the structure/symmetries in a model. A model of a jar of red and blue beads is characterised by the ratio of red to blue, and that beads are only distinguished by colour.

It ought to be possible for the page to disable JavaScript with a meta tag:

  <meta name="noscript">

The browser could put an extra icon next to the https padlock so the user would know they were viewing a document rather than an application.

There seem to be a HTTP header[1] you could use. No icon though. And I'm not sure how much the restriction could be evaded by interactive Turing-complete CSS or similar features.

[1] https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Co...

This must be the most unnecessarily awkward way of doing it (have to do it from the console after navigating to the site, so the request is allowed).

    fetch("https://heydonworks.com").then(x => x.text()).then(x => { 
      var f = document.createElement("iframe"); 
      document.body.append(f); 
      f.style.left = "0px";
      f.style.top = "0px";
      f.style.width = "100%";
      f.style.height = "100%";
      f.style.position = "absolute"; 
      f.style.border = 0;
      x = x.replace(/\<\/?noscript\>/gi, ""); 
      x = x.replace(/\<script\>.*\<\/script\>/gi, ""); 
      f.contentDocument.write(x); 
    });

That future possibiilty reminds me of https://en.wikipedia.org/wiki/Singularity_(operating_system) - where process/address-space isolation was replaced with fine-grained static verification of high-level code (presumably not the first experiment in this area).

Indeed: that and many other things are prior art in this space. And there is a lot of prior art for what we're working on—this is not meant as an academic research project! :)

Yes, one of the answers I want to give any time someone asks "why will WASM succeed when the JVM didn't" is that there is 25 years more experience and research to draw upon.

And yet bounds checking access validation was left out of the design, something that most of previous research projects took care to taint as unsafe packages when present.

I developed a kind of meta programming pattern and supporting library, based on Redux, called Immuto, to get absolute and complete static typing (via TypeScript) and minimal boilerplate, also referentiality and modularity (cursors that accepted actions). It was fun, but ultimately pointless, as it was never as straightforward as using the automatic observable approach that I'd learned from Knockout.js. Then I heard about MobX (which is the same ideas from KO but better implemented and without any quirky UI templating thrown in) and so now I used that.

Also I use my json-mobx library to get serialisation and undo/redo. Example: https://github.com/danielearwicker/baltar

Odd. Erlang uses GC.

Yes, but many small heaps means small GC pauses. It's not as deterministically/fast as reference counting (KDB) but it's close.

It's very likely that JS will adopt some things tried initially in TS. Both TS and Babel have implemented extensions to the class syntax, for example, which are being considered for JS-future.

Interesting last line in that presentation:

"Flow written in OCaml, Typescript in Typescript"