> I'm also doing Scala.js for the quick startup time btw. The JVM isn't usable with AWS Lambda last I tried. Heh, I was using Scala.js when AWS lambda was firs

> I'm also doing Scala.js for the quick startup time btw. The JVM isn't usable with AWS Lambda last I tried. Heh, I was using Scala.js when AWS lambda was first announced I enthusiastically posted to the mailing list at the time that Scala.js would be great with this new paradigm of programming. I think the JVM is going to just be dead in the water on that front. So much of the design of v8 is around beign tossed a bunch of code and being told to start running it at full performance ASAP, whereas the JVM has been optimized under a very different set of constraints (e.g. long running server processes which it pivoted to 15 years ago after the failure of applets). --- > I think WebAssembly is going to be great, but it's effectively a sandbox for native code, so it targets languages like C++ and Rust, or in other words languages that have a very light runtime and no garbage collector. I think the end goal for wasm is to provide all the hooks that javascript has.[1] And, In the meantime, Two stories I came across recently, indicate enhancements and polyfills and moving rapidly to bridge the gap: https://news.ycombinator.com/item?id=16585315 https://news.ycombinator.com/item?id=16585315 (Making WebAssembly better for Rust and for all languages) https://github.com/alexcrichton/wasm-bindgen https://github.com/alexcrichton/wasm-bindgen (A project for facilitating high-level interactions between wasm modules and JS.) > I don't know what hooks WebAssembly will be able to provide, but consider that at this point most high level languages would also have to ship at least a garbage collector with the compiled binary, because WebAssembly does not give you one, see open issue: https://github.com/WebAssembly/design/issues/1079 https://github.com/WebAssembly/design/issues/1079 > So you won't be able to run languages like Java, Scala, C#, Go, Clojure, etc any time soon. These languages are better off targeting JavaScript for now. I could see there being some sort of jvm bytecode interpreter written in wasm happening some handy wavy time in the "future". My hunch is that wasm going to become the universal low level bytecode, so I think there will be more and more projects emitting wasm as compilation target in addition to then eventually surpassing x86 / arm etc (obviously this won't happen overnight). That does still leave the area of server processes with long uptimes that benefit from JIT performance optimizations and which are ok with garbage collection overheads. > That said the thought of targeting browsers and Node with binaries built out of Rust fills me with joy. With all great power ... And a bit of fear of having articles & guis rendered to canvas removing the ability for users to control their interaction with the web. Maybe once that happens you'll start seeing your node servers stop falling over. 1: e.g. https://github.com/WebAssembly/host-bindings https://github.com/WebAssembly/host-bindings (Host Bindings Proposal for WebAssembly: This repository is a clone of github.com/WebAssembly/spec/. It is meant for discussion, prototype specification and implementation of a proposal to add host object bindings (including JS + DOM) support to WebAssembly.)