Live data from Hacker News

Standardizing WASI: A system interface to run WebAssembly outside the web

hacks.mozilla.org

121–130 of 238 posts

Re: Standardizing WASI: A system interface to run WebAssembly outside the web

#121

These Mozilla blogs are some of the best edited, articulated and illustrated explanations I've seen on the web. I wish more people could put in the resources to help communicate their mission like this.

The author, Lin Clark[0], is the person behind Code Cartoons[1]. She does absolutely amazing work. Unfortunately, there isn't really a single place to find everything she has done. She has done quite a few conference talks[2] as well. [0] https://twitter.com/linclark [1] https://code-cartoons.com/ [1] https://hacks.mozilla.org/category/code-cartoons/ [1] https://twitter.com/codecartoons [2] https://www.youtube.com/pl…

Adding a podcast Lin was on, detailed just how much work goes into creating Code Cartoons. It's pretty amazing and highly appreciated.

https://changelog.com/podcast/294

Re: Standardizing WASI: A system interface to run WebAssembly outside the web

#122
post #22

Earlier quoted context omitted.

1. It's an open standard that the major browsers have agreed to, so it's not a plugin that you have to install. A WASM app will work seamlessly in your browser without any additional software. 2. WASM is designed from the ground up as a compile target, not a language. We already see many languages with support for building to WASM. C, C++, Rust, and eventually when WASM supports garbage collection we'll probably see…

(1) could be resolved by shipping Java, let's say hypothetically. (2) the JVM was designed from the ground up as a compile target also, for Java, but is also used by Kotlin, Clojure, Ruby (JRuby), Python (Jython) and Scala, among others. Even JavaScript (Rhino, Nashorn and Graal).

But Oracle.

Re: Standardizing WASI: A system interface to run WebAssembly outside the web

#123
post #91

Wait a second... I thought Java was supposed to do this with the JVM... I thought .Net was supposed to do this with the CLR... What's different now?

The JVM and CLR suck balls. They put in huge amounts of effort into things that don't need solving, and the things that need to be solved they do in the most roundabout way possible. What we _really_ need is a sandboxed VM for running C code securely and efficiently. The JVM is pretty much the opposite of that; it's not sandboxed, not secure and certainly not efficient as a target for C code. We're hoping WASM starts…

... 20 years later

JVM, CLR, and WASM suck balls. People have been breaking the sandbox for the better part of a decade.

We're hoping Cool New Thing™ starts over from scratch and does things right this time around.

Re: Standardizing WASI: A system interface to run WebAssembly outside the web

#124
post #60

Earlier quoted context omitted.

Java is no longer a valid deployment platform for dynamically executing untrusted code. https://www.java.com/en/download/faq/chrome.xml The Java Plugin for web browsers relies on the cross-platform plugin architecture NPAPI, which had been supported by all major web browsers for over a decade. Google's Chrome version 45 and above have dropped support for NPAPI, and therefore Java Plugin do not work on these browsers…

Java inside the browser doesn't exist. That's fine. That's not what I'm talking about or making comparisons to. Java runs just fine outside of the browser. You don't even need a browser installed to run Java applications. Javascript and WASM run fine inside the browser, and that's not what I'm talking about or making comparisons to. I'm talking about running WASM binaries outside of the browser. Similar to how Java r…

The JVM doesn't run languages that weren't designed for it, like C or C++ or Rust. WebAssembly does.

This is important for a lot of reasons- huge amounts of existing code you can now use without JNI or whatever, a higher ceiling for optimization, more freedom to implement new kinds of languages.

The core WebAssembly standard is also much smaller than Java, as a consequence of this design. This makes it easier and/or more feasible to deploy in more scenarios, even without subsetting things the way mobile/embedded Java does.

Re: Standardizing WASI: A system interface to run WebAssembly outside the web

#126
post #22

Earlier quoted context omitted.

1. It's an open standard that the major browsers have agreed to, so it's not a plugin that you have to install. A WASM app will work seamlessly in your browser without any additional software. 2. WASM is designed from the ground up as a compile target, not a language. We already see many languages with support for building to WASM. C, C++, Rust, and eventually when WASM supports garbage collection we'll probably see…

(1) could be resolved by shipping Java, let's say hypothetically. (2) the JVM was designed from the ground up as a compile target also, for Java, but is also used by Kotlin, Clojure, Ruby (JRuby), Python (Jython) and Scala, among others. Even JavaScript (Rhino, Nashorn and Graal).

The JVM was designed as a compile target for a very particular kind of language. One with a Java-like object model, with some later concessions for more dynamic languages.

C, C++, Rust, etc. do not fit into that model at all. There's a lot of software written in C, and there's a lot of performance to be gained by dropping down to that level when necessary.

Re: Standardizing WASI: A system interface to run WebAssembly outside the web

#127
post #42
post #31

Earlier quoted context omitted.

Properly sandboxed VM that you can compile practically any language into?

AS/400 TIMI comes to mind, and CLR as well.

The CLR is not a great target for running unmodified C code. I suspect that was included in "practically any language."

Re: Standardizing WASI: A system interface to run WebAssembly outside the web

#128

Earlier quoted context omitted.

The JVM and CLR suck balls. They put in huge amounts of effort into things that don't need solving, and the things that need to be solved they do in the most roundabout way possible. What we _really_ need is a sandboxed VM for running C code securely and efficiently. The JVM is pretty much the opposite of that; it's not sandboxed, not secure and certainly not efficient as a target for C code. We're hoping WASM starts…

... 20 years later JVM, CLR, and WASM suck balls. People have been breaking the sandbox for the better part of a decade. We're hoping Cool New Thing™ starts over from scratch and does things right this time around.

But isn't that the point? We should be getting better at building software over time. Sometimes that means restarting.

Re: Standardizing WASI: A system interface to run WebAssembly outside the web

#129
post #124

Earlier quoted context omitted.

Java inside the browser doesn't exist. That's fine. That's not what I'm talking about or making comparisons to. Java runs just fine outside of the browser. You don't even need a browser installed to run Java applications. Javascript and WASM run fine inside the browser, and that's not what I'm talking about or making comparisons to. I'm talking about running WASM binaries outside of the browser. Similar to how Java r…

The JVM doesn't run languages that weren't designed for it, like C or C++ or Rust. WebAssembly does. This is important for a lot of reasons- huge amounts of existing code you can now use without JNI or whatever, a higher ceiling for optimization, more freedom to implement new kinds of languages. The core WebAssembly standard is also much smaller than Java, as a consequence of this design. This makes it easier and/or…

Python, Ruby and Common Lisp were designed for the JVM?

Re: Standardizing WASI: A system interface to run WebAssembly outside the web

#130
post #127
post #42

Earlier quoted context omitted.

AS/400 TIMI comes to mind, and CLR as well.

The CLR is not a great target for running unmodified C code. I suspect that was included in "practically any language."

Yeah, Managed C++ and C++/CLI don't exist.
Post reply on HN