41–50 of 313 posts
So, 'write once, run everywhere'... I think we've been here before.
JavaScript mostly solved it. WebAssembly is just the next iteration. Also good that it's open source right from the start.
Earlier quoted context omitted.
JNI? The JVM doesn't sandbox native code, nor can you target the JVM with (for example) GCC. So what are you referring to?
Why do you need JNI? You could just compile C-like code to run on the JVM using a byte[] array as the equivalent of memory. This is similar to how high-performance Java code is written already, to ensure that GC is completely out of the way. In fact GCC used to have a JVM target, called GCJ. It was removed due to lack of maintenance.
Which also involves rewriting literally everything to Java.
> In fact GCC used to have a JVM target, called GCJ
Which again, had a Java frontend. So, nothing like targeting WASM with C/C++/Rust.
So, 'write once, run everywhere'... I think we've been here before.
The VM part of WASM is not per se the interesting part. The really interesting part is having a VM that is not able to access the system besides what it's being explicitly allowed to by the host. This is an extremely useful security tool.
Earlier quoted context omitted.
If this statement is true, there is no need for Docker, because JVM+JAR existed in 2008! Docker can do more than WASM or JVM+JAR: it can run non-WASM and non-JVM apps like PostgreSQL, etc...
You can compile any C / C++ app down to wasm. In fact that’s the raison d’être of the technology: to provide a portable safe way to run binaries. Here is a link to Postgres in wasm for instance: https://supabase.com/blog/postgres-wasm . The way it works is that instead of outputting assembly for a given architecture in the backend compiler, it outputs wasm instructions that are designed to map all architectures, not…
To get an impression of the performance penalty, just run the following query:
SELECT SUM(i) FROM generate_series(0, 1000000, 1) tbl(i);
Now that is not WASM's fault - when running the same query in duckdb-wasm [1] on my laptop the query takes 10ms using WASM, and 5ms when run locally, with a slow-down of only a factor of 2. But in order to achieve those results we did have to adapt the DuckDB codebase to compile natively to WASM. That is absolutely possible but it does take engineering effort - particularly when it comes to larger older projects that are not designed from the ground up with this in mind.
Earlier quoted context omitted.
Why do you need JNI? You could just compile C-like code to run on the JVM using a byte[] array as the equivalent of memory. This is similar to how high-performance Java code is written already, to ensure that GC is completely out of the way. In fact GCC used to have a JVM target, called GCJ. It was removed due to lack of maintenance.
That doesn't work. Java web apps have failed. Nobody uses Java in the browser anymore. So even if we use JVM bytecode as the intermediary language you would need to translate that into ASM.js and then you basically introduced arbitrary complexity for literally no reason and you won't have the performance benefit of webassembly. The browser engine developers effectively paid a huge up front fixed cost and now anyone c…
A generic compilation target to the JVM would have worked, but it wasn't available 15 years ago, and GraalVM is mature about now, but so is WASM.
When will we reach a point when articles and talks no longer start with "let me explain to you what webassembly is". After all, you don't see the same introductions in articles about javascript, or python, or even rust. When seeing an article starting with such introduction - after hundreds of other articles did the same - I never know how deep to expect it to go, and whether to continue reading.
I often see a lot of technical articles posted to HN that are probably very interesting, but they assume the reader is living in the author's head and jump right into the details with little to no context.
So, 'write once, run everywhere'... I think we've been here before.
The VM part of WASM is not per se the interesting part. The really interesting part is having a VM that is not able to access the system besides what it's being explicitly allowed to by the host. This is an extremely useful security tool.
So it's kind of like GraalVM with cgroups? How about Kubernetes, in other words, how does this scale (I understand the single process proposition, but can't see how it replaces multiple containers, which might be deployed on multiple VMs / hardware)? In other words, what is the WASM runtime running on? In the article they show a WASI layer, but that does not replace a VM / container (AFAIK), so you still need an OS t…
WebAssembly also allows for powerful constructs like the component model, where components written in even different languages can interact between them.
Earlier quoted context omitted.
Well, those that act like WebAssembly is reinvinting the world kind of do. And applications get tied to the WebAssembly ecosystem, it is also a single one.
One way of looking at it that helped me wrap my head of why “this time is different”, is that Wasm is not so much as a language but a compilation target (as say x86) so it can really run anything