4 ms·
Repeating what I wrote here [1], Fabrice Bellard wrote JSLinux in 2011, which is a CPU emulator written in JavaScript that runs the Linux kernel (using typed ar
by chubot 7y ago
Repeating what I wrote here [1], Fabrice Bellard wrote JSLinux in 2011, which is a CPU emulator written in JavaScript that runs the Linux kernel (using typed arrays and relying on fast JITs).
That's just a way of saying that "the best way to predict the future is to invent it" (and do so before people who were "predicting" it).
If you knew about asm.js and Google's (now abandoned) Nacl and PNacl, there's nothing surprising about the development of wasm. It's been 10+ years in the making.
And 20+ years ago Microsoft's browser had ActiveX plugins (which didn't use a VM and were really unsafe and unportable). Making a portable, sandboxed bytecode solves an obvious problem with that.
Also the JVM ran in the browser, etc.
[1] https://news.ycombinator.com/item?id=21618323 https://news.ycombinator.com/item?id=21618323
- vanderZwan 7y ago> If you knew about [x], there's nothing surprising about [y] You are technically correct, but at the same time I do think this way of framing it is selling Gary Bernhardt a little bit short. There is still an uncanny part in knowing all the right things at the right time to predict the future.
- thaumasiotes 7y ago"The future will be just like the past, but with a different name". I guess it's just as accurate when Gary Bernhardt says it as when everyone else says it. It's not exactly a theme that's gone overlooked before. But still... executing bytecode in the browser goes way, way, way, way back.
- jchw 7y agoIt’s not just executing code in the browser. It’s been a while since I’ve watched the video but its more about JavaScript becoming the universal assembly language. I think at least that aspect is wrong because Wasm came into existence. But ignoring that detail and subbing in Wasm for JS, it’s uncanny.
- dwohnitmok 7y agoIt's even more uncanny than that. The talk hypothesized that JavaScript will not be the universal assembly language but rather a lower level language (or more accurately an OS-like system I suppose as the talk presents it), "Metal," would be. In that respect it predicted WebAssembly on the nose.
- sp332 7y agoIn December that same year, the Internet Archive started letting people boot and run MS-DOS emulators in the browser. And this was well after binfmt_misc has been (ab)used with JS engines to execute JS like a native program. A couple years earlier, NetBSD device drivers were running in the browser, and JS-engine-as-hypervisor was an explicit, if distant, goal. https://news.ycombinator.com/item?id=4757581 https://news.ycombinator.com/item?id=4757581
- Ajedi32 7y agoI personally see WASM as a natural descendant of ASM.js, so in that sense I'd say its not really wrong, just missing a step. I don't know that it's necessarily uncanny though either; ASM.js was already a thing back when that presentation was given, so the existence of WASM isn't really surprising. The real central "prediction" of that talk wasn't WASM, it was METAL, which hasn't quite taken off yet. (The idea is out there[0], but so far mostly just as a self-fulfilling prophecy). [0]: https://github.com/lastmjs/wasm-metal https://github.com/lastmjs/wasm-metal
- dwohnitmok 7y agoI think that's underselling the talk. Apart from the very enjoyable presentation, it makes valuable insights. The talk isn't trying to sell itself as 100% original. It makes reference to asm.js and a game demo that already existed at the time of the talk as well as repl.it. Despite that, I do think it makes a unique insight that even though JavaScript is ubiquitous, it will NOT be the language that future languages compile to, but rather a bytecode perhaps inspired by JavaScript that will be the language of the future. Also, importantly this bytecode will win; that is most languages will the ability to directly compile to or have a VM in this bytecode. Moreover this bytecode has the potential to entirely supplant native code and can do so with equal or better performance. At least to me, neither of those were obvious insights even though I knew of these plugins and JSLinux. First off, those plugins died. Silverlight, ActiveX, Java on the web, Flash, all of these died out and were replaced by JavaScript before wasm really took off. It might've looked like the end state would be a version of JavaScript "winning." Second, things like PNacl, Emscripten, etc. still seemed like curiosities (as the talk refers to when showing Repl.it). It wasn't clear that they or the ideas they championed would get widespread adoption. These days it is looking more and more likely that wasm is going to become a target for all sorts of different compilers. The fact that it's a major compilation target of Rust, a language that's about as far away from what I would've thought of as a language for the web as possible, is striking. And though we're still a long ways away from running everything on WebAssembly, it no longer seems as exotic an idea as it once did to me. And because of that, as well as the fantastic presentation, I still return to this talk every so often awed at how much closer we are to realizing Metal. There's still a lot of room for the talk to go very wrong, but it's not as far-fetched as when I first watched it. EDIT: Put another way; the talk is interesting to me because it emphasizes the birth and death of JavaScript. It talks about a world where the same forces that propelled JavaScript to towering heights of popularity ultimately cast it aside and create a world not possible without JavaScript, but in which JavaScript itself essentially no longer exists.
- cbhl 7y ago> Moreover this bytecode has the potential to entirely supplant native code and can do so with equal or better performance. I interpreted that part of the talk as hyperbole and sarcasm. It was saying that programmers will be so far removed from how computers work that they'll happily program against a model that has five layers of abstraction that simply serve to provide the original interface of the bottom layer. Bytecode, by its nature, has to be translated into native code -- the way for it to be 'faster' than native code is to be native code. In software, you can do this with static or JIT compilation. The hardware people do this by changing their CPUs to make the things that people do in the bytecode faster. (Apple introduced new floating point CPU instructions in their iPhones just to make JavaScript faster.)
- saagarjha 7y agoJSLinux was largely a toy, AFAIK. I don’t think it was meant as an exhortation to write all software that way.