I've heard people predict that the future of the web is to replace userland, to make every program cross-platform and sandboxed close to the metal, and for JavaScript to fade into a family of "web"-targeted languages. Looks like it's happening.
Standardizing WASI: A system interface to run WebAssembly outside the web
161–170 of 238 posts
Re: Standardizing WASI: A system interface to run WebAssembly outside the web
#162Earlier quoted context omitted.
OK, that's all correct and valid. Java still exists and is a valid deployment platform. Why is WebAssembly outside of the browser needed?
Signed types and a proper cross language target. There is very little technical difference between the two, esp now that GraalVM has shipped. WASM is now the portable executable standard. https://www.graalvm.org/
I'm sure this was meant to say unsigned types - Java only uses signed types.
Re: Standardizing WASI: A system interface to run WebAssembly outside the web
#163I've heard people predict that the future of the web is to replace userland, to make every program cross-platform and sandboxed close to the metal, and for JavaScript to fade into a family of "web"-targeted languages. Looks like it's happening.
In this scenario, what's the point of having more than one OS?
Re: Standardizing WASI: A system interface to run WebAssembly outside the web
#164I've heard people predict that the future of the web is to replace userland, to make every program cross-platform and sandboxed close to the metal, and for JavaScript to fade into a family of "web"-targeted languages. Looks like it's happening.
In this scenario, what's the point of having more than one OS?
For end-users, I'm not convinced that there is one.
Well, besides keeping competition/innovation alive.
Re: Standardizing WASI: A system interface to run WebAssembly outside the web
#165Earlier quoted context omitted.
We could re-implement C as well, but is it sensible if we already have C? If someone could explain the difference between WASI and JVM the way you can explain the difference between C, C++ or Rust, it would help a lot. If there is no such explanation, I think we should really question what is being accomplished here. As it stands currently, WebAssembly seems to integrate nicely with browsers, whereas JVM works nicely…
> If someone could explain the difference between WASI and JVM the way you can explain the difference between C, C++ or Rust, it would help a lot. I'll take a stab at it. While both WASM and the JVM aim to be portable virtual machines, WASM prioritizes sandboxing / security and a smaller runtime. A host should be able to easily set up WASM with restricted access and expect that the WASM program is secure. As far as I…
It really very much has :)
On the other hand, I seem to remember that the security model was (somewhat) adapted to the threat at hand when it was designed (~25 years ago). I haven't kept tabs on it, so I don't know how well it has aged, but there's a chance it doesn't work anymore.
Re: Standardizing WASI: A system interface to run WebAssembly outside the web
#166I've heard people predict that the future of the web is to replace userland, to make every program cross-platform and sandboxed close to the metal, and for JavaScript to fade into a family of "web"-targeted languages. Looks like it's happening.
In this scenario, what's the point of having more than one OS?
Differences of opinion in what/how to run code outside of whatever browser people decide the sandbox boundaries are.
Re: Standardizing WASI: A system interface to run WebAssembly outside the web
#167Earlier quoted context omitted.
We could re-implement C as well, but is it sensible if we already have C? If someone could explain the difference between WASI and JVM the way you can explain the difference between C, C++ or Rust, it would help a lot. If there is no such explanation, I think we should really question what is being accomplished here. As it stands currently, WebAssembly seems to integrate nicely with browsers, whereas JVM works nicely…
Someone correct me if I'm wrong, but don't the JVM and CLR assume they're working with GC'd languages and a number of other things? Making them poor targets for many languages, and AFAIK a WASM runtime is a lot more lightweight than both of them The JVM and CLR seem like they're language platforms first and VMs second
"The JVM and CLR seem like they're language platforms first and VMs second"
Ding ding ding ding ding.
There are lots of extant application VMs out there, but effectively all of them were implemented specifically to be able to run a specific language (Java → JVM, C# → CLR, Perl 6 → Parrot/NQP/whatever, Erlang → EVM/BEAM, etc.). Other languages have been implemented on top of those VMs, but they have to adopt the semantics of the actually-targeted language; you'd have a hard time taking a pure C codebase and compiling/running it on the JVM or CLR or BEAM.
WebAssembly is not that much different, technically; its actually-targeted languages are C, C++, and Rust, and you can reasonably think of it as a VM for those languages. However, it seems to be making an effort to not get caught up in the semantics of any specific language, much like how machine code tends to not really care about whether the instructions it's executing were compiled from C or Rust or Java or Ruby or COBOL or Brainfuck.
Re: Standardizing WASI: A system interface to run WebAssembly outside the web
#168Earlier quoted context omitted.
For sure, but it would be nice if there were alternative ways to run "no-need-to-install" apps without bringing all the weight of a browser with it. There's a large class of apps that don't need to link out to other URLs, don't need CSS engines (if they just need opengl/vulkan for example), and might not need as strict of security as a web page.
> There's a large class of apps that don't need to link out to other URLs, don't need CSS engines (if they just need opengl/vulkan for example), and might not need as strict of security as a web page. Yes, there are, and those uses are already solved with Steam, the Windows Store, Play Store, App Store, etc....
"Steam, the Windows Store, Play Store, App Store, etc...."
And there's also your answer. All those are fragmented, proprietary plattforms.
WASI is not.
Re: Standardizing WASI: A system interface to run WebAssembly outside the web
#169Solomon Hykes, co-founder of Docker, believes WASM+WASI could take the place of Docker. https://twitter.com/solomonstre/status/1111004913222324225
This. I don't have a clear enough mental model for either docker or wasm+wasi, but I immediately thought of docker. What is docker except a bunch of purpose build operating system instances? And why do we need Linux installations (as much as I am a fan of Linux) when we could just run on WASI? And Electron, where each instance runs on an individual instance of a browser?
This is the same reason that things like unikernels have been built for. They haven't taken off because of how difficult it is to rebuild your application to also contain it's kernel, but this kind of sandboxing with WASM and WASI doesn't require that and could likely make things a lot simpler to deal with.
Re: Standardizing WASI: A system interface to run WebAssembly outside the web
#170Earlier quoted context omitted.
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…
> The JVM doesn't run languages that weren't designed for it, like C or C++ or Rust. You can run all those languages on top of the JVM! The JVM also runs many other languages which weren't designed for it, like Ruby and Python.
> You can run all those languages on top of the JVM!
Do you have a source for this? I'm sure it's theoretically possible in a Turing-completeness sense, but considering Java lacks any concept whatsoever of a pointer, and considering that most (if not effectively all) C code uses pointers pretty extensively, I find it unlikely that this statement is meaningfully true without some severe efficiency penalties.