Earlier quoted context omitted.
Except entirely irrelevant as WASM is not Javascript.
Sure, though it’s still a web technology taking over an otherwise unrelated space ¯\_(ツ)_/¯
[deleted]
Standardizing WASI: A system interface to run WebAssembly outside the web
131–140 of 238 posts
Re: Standardizing WASI: A system interface to run WebAssembly outside the web
#132Earlier quoted context omitted.
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.
I was careful to say "unmodified." C++/CLI is hardly that. It's also not at all sandboxed the way wasm is.
Why the chip on the shoulder?
Re: Standardizing WASI: A system interface to run WebAssembly outside the web
#133Earlier 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…
Python, Ruby and Common Lisp were designed for the JVM?
To the extent that their object and memory models match the JVM's, you might say they were. To the extent that they don't, their JVM implementations wind up with warts and inconsistencies.
(But this is pedantry, you clearly know what I meant.)
Re: Standardizing WASI: A system interface to run WebAssembly outside the web
#134Earlier quoted context omitted.
Yeah, Managed C++ and C++/CLI don't exist.
I was careful to say "unmodified." C++/CLI is hardly that. It's also not at all sandboxed the way wasm is. Why the chip on the shoulder?
C++/CLI is just ISO C++ plus a couple of language extensions, you know like the Linux kernel is ISO C plus GCC extensions.
I hardly see the difference.
No chip on the shoulder, just an old guy that has seen dozens of VMs since the mid-80s, delved into others from earlier decades, which doesn't buy into WASM marketing.
Re: Standardizing WASI: A system interface to run WebAssembly outside the web
#135Earlier 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…
Nah, just bytecode verifiers, security managers and access capabilities, but whatever.
Re: Standardizing WASI: A system interface to run WebAssembly outside the web
#136What does this mean for host bindings?
Re: Standardizing WASI: A system interface to run WebAssembly outside the web
#137Earlier quoted context omitted.
For embedded devices you'd always be better just compiling C/C++/Rust directly to the native code. You don't have any portability possibility there in the first place anyway, so why ship inferior code gen with arbitrary restrictions?
Because you want to be able to dynamically load semi-trusted code on a microcontroller without MMU and run it without having to worry it could crash the whole thing?
Do you have an actual example of such a thing? I'm struggling to come up with a case of multiple independent mini-programs in such a microcontroller that needs, or even benefits, from that level of fault isolation.
Re: Standardizing WASI: A system interface to run WebAssembly outside the web
#138Earlier 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?
Using Oracle's Java Programming Language is an immeasurable legal liability.
I am pretty sure IBM has a couple of patents regarding VM implementations.
Re: Standardizing WASI: A system interface to run WebAssembly outside the web
#139Earlier quoted context omitted.
There are open source and non-Oracle Java virtual machines you can buy support from if Oracle isn't your cup of tea. It's not really a legal liability either. Lawyers for companies who use Java go over those agreements with a fine tooth comb and approve them before they're signed. There are no surprises (if your attorneys aren't frauds.)
Google's was not using Oracle's virtual machine, and their attorneys were not frauds, but they've been tied up in litigation for most of a decade and are facing potentially ten billion dollars in penalties. https://en.wikipedia.org/wiki/Oracle_America,_Inc._v._Google... . Java is not a responsible or ethical choice for anybody to use for any purpose.
They just screwed Sun, created Android J++ with applause from wannabe be Google employees, and turned down the opportunity to buy Sun and own Java.
They deserve what they get.
Re: Standardizing WASI: A system interface to run WebAssembly outside the web
#140Wait 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?
you can use html/css/js with it, I guess :/ Or, more accurately, its easy to make UIs for it? I'm personally bearish on the whole idea from a community / technical standpoint (in that I'd like us to return to more native stuff than follow JS into the browser), but I can't argue that WASM and co won't enable some really cool uses.
I can't shake the niggling idea that this, just like node before it, is more or less a way for JS web devs to not have to leave the ecosystem they're comfortable with and learn a new language. We already have hundreds of ways to write native UI applications, but web devs can't bother to use them.