Hacker News Reader

Comment by ngrilly | Hacker News Reader

I'm a bit skeptical about this. This is significantly increasing WebAssembly's complexity.

Garbage collectors are a leaky abstraction: Some support interior pointers, others don't. Some support parallel tasks sharing memory, others don't. Some require compaction, making C FFI more difficult, others don't. Some require a deep integration with whatever mechanism is used for green processes/threads and growable stacks, others don't. Etc.

When looking at languages like Erlang, JavaScript, Python, or Go, the choices made at the language level are partly reflected in their garbage collectors.

That idea of a universal/generic VM supporting many languages has been tried many times, with limited success, for example with the JVM, CLR, or Parrot. What makes this different?

View on HN

>That idea of a universal/generic VM supporting many languages has been tried many times, with limited success, for example with the JVM, CLR, or Parrot. What makes this different?

What's different this time is that WASM flips the timeline backwards from how Sun JVM and Microsoft CLR tried to do it.

- JVM/CLR : create virtual machine & IL instruction codes specification & runtime first, then later try to distribute widely as possible and hope for universal client adoption. In other words, the "intermediate language vm" will be so compelling that it causes industry to spread it throughout the landscape. This hope was only partially true. JVM/CLR did spread on desktop & servers but fell short on web browsers with Java Applets and Microsoft Silverlight. JVM/CLR also never got widely adopted on mobile platforms.

- WASM has opposite timeline : take something (aka Javascript) that's already distributed and adopted industry-wide and work backwards from that to create a "virtual machine & IL instruction codes specification & runtime".

In that view, Javascript (the so-called "toy language") was the 20-year long "Trojan Horse" of getting wide distribution on all clients first. Now the industry says: "Hey, did anyone notice that we finally have a universal runtime (Javascript) on server+desktop+browser+mobile?!? Let's make it fast by creating an IL runtime!!!"

There were a few technical issues such as Sun JVM not having raw pointers which makes it not a good performing target for pointer-based languages like C/C++. And MS CLR wasn't available on macOS (except for Silverlight minimal-CLR). But those technical limitations don't have as much explanatory power as the Javascript-as-harmless-trojan-horse-distribution timeline.

> take something (aka Javascript) that's already distributed and adopted industry-wide and work backwards from that to create a "virtual machine & IL instruction codes specification & runtime".

I don't understand this. WASM is not JavaScript: it can't do things that JavaScript can do (such as directly access the DOM) and JS can't do things that WASM can do (such as pointer arithmetic). Their abstractions are totally different, which is why they complement each other. JS does not run in the WASM virtual machine. Other than the fact that they both run in a web browser, they have almost nothing in common.

So I think your analogy fails. WASM is not a JS IL, it's a separate IL that happens to be distributed by the same mechanism. As such, it can still fail and is still vulnerable to the hubris of the JVM, wherein a single memory model was selected for all platforms and all (higher-level) languages.

>I don't understand this. WASM is not JavaScript: [...] So I think your analogy fails. WASM is not a JS IL, it's a separate IL

Yes, that's what it looks like now. To explain the Javascript-to-WASM evolution, we use the concept of the "Overton Window" shifting the industry by almost imperceptible degrees : https://en.wikipedia.org/wiki/Overton_window

- phase 1: 1995 Javascript the "toy language" but no IL. The industry doesn't need to be "afraid" of a toy scripting language because it's just there to make the monkey dance.[1]

- phase 2: 2000s Javascript is being extended XMLHttpRequest() to create "serious" apps like drag & drop email and Google Maps

- phase 3: 2013 extensive use of Javascript everywhere motivates a performance hack by creating subset in "asm.js" : https://en.wikipedia.org/wiki/Asm.js

- phase 4: 2017 instead of "asm.js" (and also using some Google NaCl ideas), the industry finally collaborates to create WASM to further optimize away the inefficient "asm.js"

Since WASM today looks a lot like what JVM/CLR hoped to accomplish, why couldn't we have skipped the whole circuitous route of Javascript-then-WASM instead of just having "WASM in 1995" in the first place?!? Because of the Overton Window. If WASM was there from the beginning, it would have been too "threatening" in 1990s and corporate firewall admins would want to block all http/html that had it. ("Let's prevent WASM viruses") Javascript on the other hand is just for animating monkeys so there's no need to block it. That's how you eventually get universal distribution across clients including smartphones. With Javascript code already entrenched everywhere, it's easier to slide the Overton Window over to WASM.

WASM didn't get created in a vacuum. It's existence is directly tied back to Javascript's usage and growth.

[1] https://softwareengineering.stackexchange.com/questions/2216....

> Since WASM today looks a lot like what JVM/CLR hoped to accomplish

WASM is actually much lower-level than JVM or CLR, there's basically no comparison. The main feature in both CLR and JVM (accounting for the bulk of their complexity) is their object model which has no equivalent in WASM-GC, the closest thing (while quite different nonetheless) is probably the WASM components proposal which is still vaporware.

(Could WASM-GC have shipped in the mid-1990s? Quite unlikely, the FLOSS community was in its infancy back then and JVM applets were seen as state of the art. Even the Cyclone language was only created in the mid-2000s, and having full type- and memory-safety with C-like performance and no need for pervasive GC was unthinkable prior to that. The plan9 folks had Limbo and Dis which were somewhat simpler, but there was zero broader interest in using something like that over the JVM.)

Not to mention, JavaScript engines were essentially extended into supporting WebAssembly much like they were extended to optimize Asm.js. Browsers generally don't have entirely separate WebAssembly engines, parts of their existing JS engine are shared for WebAssembly. I think that makes the case pretty well!

That doesn't really make the case—JIT compiler backends are all pretty similar, so of course the browsers are going to reuse parts of their JavaScript JIT for WASM, but that doesn't make WASM "JavaScript, but fast". The only resemblance WASM has to JavaScript is it lives in the browser.

To be fair, as far as I can tell you are the first person to use the phrase "JavaScript, but fast" in this thread. Wasm's design isn't based on JS, obviously. It is, however, strongly inspired by ideas like asm.js and the existence of C -> JS compilers (among other things.) You can find more evidence of this than just HN commenters. Here's Google:

https://web.dev/articles/what-is-webassembly

Heck, the same toolchain (Emscripten) that targeted asm.js became one of the defacto Wasm toolchains. They're not the same thing, but the path from which things evolved is not really open for much debate.

This is what I'm replying to from OP:

> Now the industry says: "Hey, did anyone notice that we finally have a universal runtime (Javascript) on server+desktop+browser+mobile?!? Let's make it fast by creating an IL runtime!!!"

If they'd said that we have a universal platform in the browser, make it fast, that would be different. It's the idea that the JavaScript runtime is going to be made faster by WASM that I'm objecting to.

Interesting. I think we are interpreting that statement quite differently.

From my PoV, they designed an IL runtime based on how some people were using JavaScript, aka inspired by Asm.js, not an IL runtime for or based on JavaScript.

I did not read that statement as saying Wasm was or was intending to be faster JS, at least not generally. Of course you are correct in that Wasm has absolutely nothing to do with JS on a lower level.

>This is what I'm replying to from OP:

>>"Hey, did anyone notice that we finally have a universal runtime (Javascript) on server+desktop+browser+mobile?!? Let's make _it_ fast by creating an IL runtime!!!"

Ok, I see the misunderstanding. The "_it_" I'm referring to is the "desire to run serious apps in that runtime". I wasn't claiming that WASM makes Javascript syntax faster.

jchw intepreted my meaning as I intended: From my PoV, they designed an IL runtime based on how some people were using JavaScript, aka inspired by Asm.js, not an IL runtime for or based on JavaScript.

My point is that history has now shown us that it's easier for Google to extend V8 engine to also run WASM, and for Mozilla to extend SpiderMonkey to also run WASM... rather than for Sun JVM applets to spread into all browsers as a universal runtime -- or for a JVM-bytecode-compatible engine to be embedded inside Chrome/Firefox.

Even though Javascript itself was not purposefully designed to be a universal compilation target for C/C++, it nevertheless opened a door to a universal bytecode runtime that the JVM/CLR did not.

> 2013 extensive use of Javascript everywhere motivates a performance hack by creating subset in "asm.js" :

ASM.js was an attempt to make JavaScript a useable compilation target, not a performance hack for JavaScript programs. That effort did lead to people deciding that a new bytecode format was a better option, but the desire to compile to JavaScript was never about JavaScript itself, it was about trying to bring other languages to the frontend web. At the time the only way to do that was to compile to JavaScript.

I don't think you're wrong about the Overton window, but it's a lot more complicated than "JavaScript shifted the overton window". The actual history is one of people wanting to do more and more with web browsers in general until JavaScript became non-viable. WASM is far more a younger sibling of JavaScript than it is a descendant of it—both were born from the growth of the web.

There's a lot wrong here with these timelines.

Java applets came out at the same time as the original release of Java, and were definitely part of Sun's strategy for Java, but providing a platform for other languages wasn't in the plan. Others came because they specified the virtual machine so clearly that it was actually possible to target (unlike Python's), but if you look at the Java bytecode it's pretty clear that it exists to serve one language and all others must adapt. You calling the JVM not having raw pointers a "technical issue" makes it sound like it was a mistake on Java's part, but that's just a side effect of only intending to support a language that doesn't have raw pointers.

Meanwhile, WASM isn't just JavaScript-made-fast—JavaScript is already very fast through JIT compilation, and it's not obvious that compiling it ahead of time to WASM would make it faster. I'm not even aware of any efforts to do so. WASM is actually what you seem to think Java was—a new runtime built for the web and designed to allow many languages to target it flawlessly. To the extent WASM has an advantage over previous shared runtimes, it's that it was designed to be shared from the start and was spearheaded by the largest modern platforms—the browsers themselves are the true Trojan horse here.

> were definitely part of Sun’s strategy

Java is a desktop light client programming language which found a small niche on server side.

> That idea of a universal/generic VM supporting many languages has been tried many times, with limited success, for example with the JVM, CLR, or Parrot. What makes this different?

I would say that the JVM and CLR were not designed to support many languages. The JVM has one master, which is the Java language, and other languages that want to run on the JVM do so with a burden that increases as the distance from Java's type system increases.

Wasm is lower-level than most of the above bytecode formats. Even with Wasm GC, which adds statically-typed structs and arrays, and the function-references proposal which brings typed functions. With Wasm GC, there is also explicit support for tagged pointers (i31ref).

All of the above makes Wasm GC more general (by virtue of being lower-level) than the efforts you listed.

JVM wasn't originally intended to support multiple languages. IIRC, Sun wasn't welcoming to new languages on the JVM (Java Virtual Machine).

But CLR stands for Common Language Runtime and had three official languages shortly after release (VB.NET, C# and J#, offhand).

In fairness, both Sun and Microsoft advertised what they were shooting for in the name.

Microsoft planned to support all kinds of languages and the list of CLR languages is respectably long, but most of them can't really keep up with the co-evolution of .NET and C#.

The generics in .NET 2.0 were the first big compatibility break, and I think async/await was the second and even bigger one that killed off the bulk of alt-langs.

async/await was never a compatibility break at the CLR level. Most of async/await is "just" the TPL (Task Parallel Library), a subset of the .NET BCL (Base Class Library) and entirely handled as libraries, which any language can use/interact with even without async/await language support.

The async/await language support in C# is basically a Monad transformer, building a generator-like asynchronous state machine. (The output of an async/await function in C# is rather similar in concept/implementation to the output of a generator function using yield syntax.) This is also why F# has never had a tough time with async/await because it has even more generic Monad transformer support ("computation expressions").

Any "alt-lang" could make use of the TPL whether or not they could transform their own similar syntax, and there's nothing stopping them from building a similar syntax. As far as I saw that wasn't a killer of languages.

It wasn't a break at the CLR level, but it was a break at the BCL level. To consume the new async methods your language had to come up with a mechanism that was broadly similar to how C# worked or miss out on the vast majority of libraries and the BCL itself.

If a language didn't do anything at all like C# it dealt with a lot of task.ContinueWith(value => {}) callbacks (Action<T>), no different to JS promise.then(value => {}) chaining (truly, no different at all because Task/Promise are basically twins). At worst case you had callback "waterfalls" to deal with, but that was hardly "breaking" and shouldn't have "killed" languages. async/await is much nicer than callbacks/callback waterfalls, but that doesn't mean you can't write callbacks/callback waterfalls (a lot of JS projects certainly did; many still do even despite most browsers supporting async/await today).

The language would also need to have some support for anonymous delegates and closures, or its callback waterfalls would have to be broken up into multiple methods that would have to manage the call state themselves.

CLS really expected most languages to look a lot of like early C#, that is, Java with some Delphi/VB features grafted on.

> But CLR stands for Common Language Runtime and had three official languages shortly after release (VB.NET, C# and J#, offhand).

CLR is not really common -- the "tells" are VB.NET and PowerShell.

VB6 was a very popular and useful language, and VB.NET broke everything in that ecosystem, turning it into a variant of C# with different syntax.

Does that sound like a multi-language VM?

If so, why not compile VB6 to it?

PowerShell is likewise best described as C# with a horrible shell-like syntax.

It's not really a shell in the original sense, because it doesn't talk to the kernel directly -- it runs on a VM, which mediates all access to the kernel.

fork() is a syscall that shells rely on critically, which is problematic for almost all VMs.

Some notes on "interior" (VM-based) vs "exterior" (OS kernel-based) shells here:

https://www.oilshell.org/blog/2023/06/ysh-design.html

It was intended to be common whether or not it succeeded.

Those examples point to a differing design philosophy at Microsoft rather than some inability to write a language on the CLR. The design philosophy was clearly to do Java-ish typing across the board, supplanting VB6's loose typing and bash's text based mindset.

I don't really like the approach. I think shell scripting succeeds because it allows ad-hoc programming and I don't think Java-ish weak but static typing is some perfect ideal to be used everywhere, but you could certainly implement a more loosely typed language on the CLR.

> I would say that the JVM and CLR were not designed to support many languages.

Hm...CLR stands for Common Language Runtime. I think it was explicitly created to support many languages.

It still has C#'s object type system baked into it. It also has reified generics (IMHO a good thing from a performance perspective), which bakes in a particular way of doing parametric polymorphism. If your language's generics work differently than C#'s, you are probably going to have a bad time, and you might have to bring all your own libraries.

The CLR's support for functional programming is better than the JVM partly because of the reified generics and partly because Microsoft developed F# and thus had skin in that game and worked hard to make it better.

The JVM's support for functional programming has always been weak; invokedynamic and the additional MethodHandle framework reduces boilerplate but is not really the right feature for FP, but a very clunky and heavyweight OO view of FP.

> It also has reified generics (IMHO a good thing from a performance perspective), which bakes in a particular way of doing parametric polymorphism.

Reified generics need additional support, and if you're using type erasure you didn't need any support. What's missing then when it comes to supporting mainstream languages - HKT?

You can't use the .NET standard libraries that have type parameters if you simply erase (which is what I meant by bring your own libraries).

Funnily enough, the CLR barely runs F#, while the JVM’s (which is supposedly was designed as java-only) guest language ecosystem is blooming.

Maybe sticking to the one true universal bytecode format is already a fallacy — why not just stick to AST interpreters, when they can be made efficient? This is the premise of Graal’s Truffle, and I think they succeed at it quite well.

You'll find this[0] interesting then:

  The abstract syntax tree is then traversed and
  encoded into a stream of symbols from the evolving
  vocabulary. The encoder processes whole subtrees of
  the abstract syntax tree at a time; these roughly
  correspond to statements on the level of the source
  language

If I'm not wrong, this technique originated in Oberon and was polished by the paper authors (disciples of Wirth)

[0] https://dl.acm.org/doi/pdf/10.1145/265563.265576

GraalVM has multiple language implementations that can now run on both GraalVM and OpenJDK.

They are typically as fast and sometimes faster than their standard counterparts (e.g. can't find the announcement now but mastodon runs much faster on GraalRuby than on JRuby, and JRuby is pretty fast). I have personal experience with GraalJS being very fast.

So I _think_ that you could now say that the JVM can now properly support multiple languages. There are still limitations, mostly related to language libraries that have native bindings so it's not all flowers and chocolates. But still worth considering. But as a general purpose multi-language platform I think you could say it's viable now.

But I share the scepticism - is this really the point of WASM? Whether it is or not, it does seem to be the general direction

https://www.graalvm.org/latest/graalvm-as-a-platform/languag...

But then WASM GC immediately assumes it can be a moving, compacting GC, with no support for interior pointers.

There's a reason Go isn't mentioned in the blog post: the GC is a leaky abstraction.

Does Go leak observable pointers?

People have certainly written unsafe code which uses uintptr in naughty ways which only work without moving gc, but every piece of documentation for such features also tells you not to do it.

Intentionally so: that's the only way to cooperate with C and memory-mapped kernel and hardware ABIs. There is an explicit mechanism to pin memory.

https://pkg.go.dev/cmd/cgo#hdr-Passing_pointers

https://pkg.go.dev/runtime#Pinner

I think it's also worth pointing out that the main Go implementation has a non-moving GC (at this time), and all kinds of fecal matter may impact a rotary ventilation device if and when that changes. Like, are we supposed to pin byte arrays we pass to syscalls? Nobody does that, right now, for short-living calls.

The WASM-GC support is intentionally kept as simple as possible, see https://github.com/WebAssembly/gc/blob/main/proposals/gc/MVP... . Building a "universal" or "generic" VM supporting many languages on an equally seamless basis is explicitly not a goal of WASM-GC; it is expected that each implementation might require its own hacks and special semantics on top of the basic support WASM provides, but this is okay because FFI/cross-language interop is seen as an entirely separate issue.

I think what makes it different is the importance of the project.

JavaScript garbage collection is here to stay, and it seems like it's the most sticky one of all the examples you mentioned.

Other languages and applications/libraries have to adapt to it even if it's inferior in many cases.

Fair enough. I'd say the JVM and CLR are quite important and "sticky" as well on the server-side ;) But on the client-side, there is no contest, JavaScript (and thus WebAssembly) are the only option.

Just wanted to note that webassembly doesn't imply client, especially since docker's somewhat native support appeared

WASM also looks really good for native plugins and modifications (it's fast and secure by default).

That idea of a universal/generic VM supporting many languages has been tried many times, with limited success

What wasm is doing is something different than previous efforts. The gc facilities aren't provided for the sake of interop with other languages, or for the sake of sharing development resources across language runtime implementations. Wasm is providing gc facilities so that managed-memory runtime languages can target wasm environments without suffering on account of limitations imposed by the restrictive memory model, and secondarily to reduce bundle sizes.

Wasm can potentially support more tunable gc parameters to better suit the guest language's idiosyncrasies than can other general purpose language runtimes. And unlike the runtimes we're comparing it against, language implementers don't have to option of making something bespoke.

> I'm a bit skeptical about this. [...] Some support [X], others don't. [...]

I am super conflicted, but I err on the side of agreeing with you here. Gut feeling says it's too complex and fragmented to be "standardized".

Generally speaking, "abstracting out" something should be done when that "thing" is actually pretty clearly defined and always end up behaving the same way. My understanding is GC does not qualify - despite its popularity we still don't know where the cut points are, in all honesty. There's a reason why languages differ so much from one another, and afaik this is still an area of quite active research.

Adding to that, intricate understanding of GC internals of multiple languages is probably restricted to a very low amount of engineers, worldwide. This makes it very difficult for curious bystanders to understand, follow and critique the progress. Remember that this is a massive career project for the proponents, so they're also incentivized to push ahead and perhaps gloss over legitimate issues.

And what if the design ends up being flawed, yet wildly popular? Then languages may be forced to conform to the WASM GC model in order to stay "modern" and attractive, while constraining their normal design space.

That said, if everything goes dandy it can be a huge win, so I can relate to the excitement as well.

The correct question is “what makes WASM different”, not the other way around. And, mostly nothing, besides some “elegance” from being a new thing not yet full of legacy constructs. Oh, and that the browsers (or whatever is left from the browser scene with nigh everything being blink unfortunately) agreed on this one and not the others.

I personally think that GraalVM’s truffle infrastructure is much more impressive, and supporting the much wider managed language landscape may have been a better idea for wasm as well.

>“what makes WASM different”

As I understand it, it's just difficult to efficiently implement GC because of the stupid decision to abstract the call stack within WASM, making it painful to get at stack pointers during collection.

One would think that a generic VM assembly and the ability to make pages of memory as no longer in use so the VM and then OS can recollect them would be sufficient.

Rather than admitting to and fixing their mistake, they're doubling down and doing something of much greater complexity to work around it.

That “stupid decision” is pretty key to WASM sandboxing model. How do you propose to preserve call flow integrity without it?

Don't put return address on the data stack, and don't allow write access to the call stack via anything other than call/ret.

Okay, where does the VM spill registers to?

I don't understand why more languages don't just handle a separate data stack from the call stack. Then the call stack can remain harder to screw up and you can continue using stack frames for arguments or locals as desired.

When feeling productive (not much in the past year unfortunately) I've been trying to build a bytecode for i86/x64 that operates this way.

I see what you're getting at. I think something like code pointed integrity would be more interesting, and would even protect pointers in vtables and other heap allocated structures:

https://www.usenix.org/system/files/conference/osdi14/osdi14...

> the JVM, CLR, or Parrot. What makes this different?

I think primarily because the decision to run a certain language on WebAssembly comes first and now the question is how to make it fast. For the JVM or CLR there was usually no need: Just pick Java C# or run the other language natively.

The blog post goes into this topic. It's basically a question of trade-off between performance and exact semantics, in some cases you will need to sacrifice minor semantic differences for meaningful performance gains. I think this is rather common when porting languages to "foreign" VMs and doesn't seem to be a showstopper. The application developers targeting WASM and other platforms of course have to test on all platforms and will avoid those cases with semantic differences.

The main difference is that WASM started with unsafe languages that have all of those features, so the developers are aware of them, and now they're trying add safety.

Prior universal VMs started with a safe language and bytecode and then added unsafety. Maybe that will change the outcome, maybe not. At the very least you can still use conservative GC.

I can see value in running code on multiple browsers on multiple OSes via web pages. I’d hate to npm install 2k+ JS libraries I don’t know or understand to be able to compile a simple Hello World Kotlin program that runs on a webpage. There does seem to be some notion in the industry that everything should be in a browser/JS, sigh.

To run a wasm-compiled program in a webpage you need maybe 30 lines of JS total. Maybe a 10 more lines if your application wants to draw on the page through a canvas

It's a bit more complex than that, JS and WASM have a huge impedance mismatch (if you can call it that) because they can only communicate via shared memory and functions calls using numeric types as arguments.

As soon as you want to pass a string, struct or arbitrary map between JS and WASM you'll find yourself in a world of pain that comes from writing bindings that de/serialize data on both sides. Rust seems to have a somewhat capable bindings generator but the core issue still remains in any other language targeting WASM.

I'm not keeping myself up to date, but as far as I remember WASM/JS interface types proposal was supposed to address this issue. Has there been any progress on that front?

> To run a wasm-compiled program in a webpage you need maybe 30 lines of JS total. Maybe a 10 more lines if your application wants to draw on the page through a canvas

If you read more carefully you will see that I mean that if your application is completely written in WASM with no JS interop all you need is some JS glue code to load the WASM binary

If you want to manipulate the browser DOM from inside the WASM binary then yes, you need a lot of JS

> I'm not keeping myself up to date, but as far as I remember WASM/JS interface types proposal was supposed to address this issue. Has there been any progress on that front?

Last I heard it is somewhat abandoned proposal

Yeah, I don't know how you could have one gc that works for everything unless that gc was very tunable/configurable and you could have different profiles for each language. Maybe the program payload includes the gc tuning parameters such that the gc performs like the GC for the program's host language?

Isn't the JVM kinda of a universal GC? Putting the different GCs in the JVM itself aside, a lot of other languages actually have runtimes for Java and work very well, used in production and all. Jython, JRuby, JS engines (Rhino/Nashorn), Groovy, etc.

> Isn't the JVM kinda of a universal GC?

Nope. No interior pointers for one.

The reference JVM has at least 4 different GCs, with pages of tunables. That’s a far cry from universal.

AFAIK all of the different GCs are implementation transparent, no? Implementations like Jython or Jruby work independently of the GC being used

If your criteria for a universal GC is that the GC does the job of a GC, every GC is universal.

How universal did the JVM ever try to be? Aren't its semantics pretty tied to what's legal in Java?

Not quite, and this has had security implications. These are known as "full abstraction" failures, where JVM bytecodes can violate guarantees made by a language running on top of the JVM. The Joe-E language is basically a security-oriented subset of Java, and they had to explicitly decompile JVM bytecode of any code they're using, then recompile it in order to preserve full abstraction and avoid introducing vulnerabilities.

C# is close to CIL bytecode as well, but they too had some full abstraction failures: http://lambda-the-ultimate.org/node/1588

Reply on news.ycombinator.com