I think WASM is an example of a thin waist [1] with its garbage collector and N+M rather than N×M. (N languages + M virtual machines + G garbage collectors). That's a mature garbage collector in V8.

I was curious if there was a WASM to JVM and it seems there is one on GitHub, I haven't used it I was just curious because the JVM is a mature (and parallel) garbage collector.

Now I'm excited for WASM Threads for true parallelism and not just IO parallelism because I didn't think WASMGC would come out so soon.

The opportunity to solve async and parallelism and garbage collection EFFECTIVELY would strengthen WASM and not be a source of confusion or difficulty for developers. I think that's why WASI is so important, a chance to define an API as stable as POSIX.

1: https://www.oilshell.org/blog/2022/02/diagrams.html

2: https://github.com/cretz/asmble

While it works well, this was mostly a fun project for me and I no longer really maintain it. I hope that the ideas and explanations of how I mapped WASM IR to JVM bytecodes helps whoever does build this in a more official capacity. I don't have any plans to support WASM GC currently.

> More than 20 programming tools vendors offer some 26 programming languages — including C++, Perl, Python, Java, COBOL, RPG and Haskell — on .NET.

From https://news.microsoft.com/2001/10/22/massive-industry-and-d...

It's interesting that none of the languages that you list made .NET a primary target and have all either bit-rotted unofficial ports or sunsetted their mainline support. It's hard to say whether languages that now target Wasm will suffer the same fate, since that depends on level of maintenance that each project allocates to particular targets. Still, I don't really get your point.

Every guest language means additional IDE plugins with platform knowledge, since most communities want idiomatic libraries, an ecosystem on top of the ecosystem, as the actual platform is only implemented in a main "systems" language, mastering it is required anyway for all the leaky abstractions on the platform, additional build toolchains,...

In the end, each polyglot platform achieves a global maximum of main language, and possibly a winner among all guest languages, even if it takes a couple of years with projects fading away until this happens.

It sucks, however so it is the outcome of human nature attention span, and not being able to keep momentum for all languages across the whole lifetime of a given platform.

The DLR made it much easier for dynamic languages on .NET to interact and share infrastructure on top of the CLR, but it also gave C# directly just enough dynamic language powers that filled most people's use cases for that niche.

Even in the current race between C# and F#, unless you are using features such as Units of Measure or Type Providers, there is often a sense of "you don't need to use F# because that feature will be eventually in C# anyway" and "F# is just a proving ground for C# ideas". The F# community continues to try to find marketing messages that aren't that and better highlight some of the niches that F# can fill that C# won't. The most recent attempts have been trying to position F# as a "data sciences" language useful for Notebook-driven development in direct comparison/competition to Python/R/Julia. C# actually is finally useful in Notebooks now and has some alright REPL support, but F# likely will always better fit that niche. It will be interesting to see if that marketing approach helps.

I think that’s more because of the amount of good Java binaries than because the JVM is good at supporting alternative languages.

Scala had to make a few design choices they would never have made if they didn’t want to target the JVM and be compatible with existing Java binaries.

Examples:

- having Option[T], but still having null, too.

- value types aren’t supported in the JVM (yet), so they’ve had to implement them using classes.

- scala’s reflection would have been easier to understand if they could have tweaked the JVM to implement it (scala had to work hard to map its type system to that of the JVM)

- scala has its own integer classes that are subtly different from both Java’s value types and it’s integer classes.

Kotlin mostly is Java with a different syntax. Like scala, it must be doing some magic to support its value classes.

Also, as another post in this thread said, some languages my need a garbage collector that behaves different from the JVM one. If so, you either adapt, or give up running on the JVM.

The reflection claim is also questionable, as Scala used to be available for the CLR as well, but that version was abandoned, while the JVM is striving. In fact, erasure of generics help with guest languages, as it doesn’t bake into the variance.

I don’t know scala 3 well, but if it can make nonnullable types (that’s what “exempt null from ordinary types” means, isn’t it?), that’s not something the JVM knows about (although that may be changing with the addition of value types to the JVM)

Even if that’s incorrect, there are plenty of other examples of types that map badly to the JVM, such as Either[String,String] and AnyVal (a scala class with subclasses such as Int)

Another example are value classes, which are values until they aren’t. https://docs.scala-lang.org/overviews/core/value-classes.htm...:

“Universal traits allow basic inheritance of methods for value classes, but they incur the overhead of allocation”

And yes, scala3 has opaque types, but in the JVM, those must revert to their underlying type (if they don’t, the performance gains are lost), and scala3 also still has value classes.

> this can be completely decidable at compile time.

It can’t the moment you load a jar and call a method in it, and I think about every scala program does that.

> The reflection claim is also questionable

The JVM has strict single inheritance. Scala supports a form of multiple inheritance through traits. There’s no trivial way to map that to the JVM.

> In fact, erasure of generics help with guest languages, as it doesn’t bake into the variance.

I don’t understand that. It surely doesn’t always help. Scala reflection doesn’t want erasure, so they’ve had to work around that.

All the other alternative languages had better times behind themselves.

Groovy survives thanks Jenkins and Gradle.

The guest languages are like relying on (human or machine) speech/writing translation services to communicate with folks who only know the local lingua franca.

That added friction hobbles the minority languages.

Perhaps AI will aid in greatly reducing these issues over time (and I say this because large language translation models and text to speech + speech to text are finally reaching professional human quality while running on local hardware today). But I can't think of any other good method to hold back the floodgates of people being forced to choose between their mother tongue (with its corpus of invaluable baked in stories and perspectives) and being understood by others.

I would not be surprised if Kotlin takes a majority share eventually

No JVM will ever be rewriten in Kotlin for it to matter outside Android.

Unless you were intending this as a criticism of .NET?

I could see WASM actually pulling this off.

EDIT: Yes, F# is an ML-style language. I was answering the spirit of the question, which was 'statically-typed functional-first programming language running on the .NET CLR'.

Same, I'm very interested in using threads in the browser but sadly thus far threading in wasm on the browser requires the server providing an extremely restrictive response header making threads impractical for most applications.

Pedantic: threads are concurrent, not necessarily parallel. It's weird to see them called "true parallelism". I assume you mean in comparison to coroutines, but those are sequential (their execution order may be arbitrary, but we can rely on them not being concurrent).

If wasm adopts threads that would be another unfortunate WorseIsBetter situation, given that threads are probably the worst model of concurrency we've ever devised (other than concurrent COMEFROM)!

Like it or not, threads are here to stay. Threads with shared mutable memory are the abstraction that multi-processor systems give software. They are not a software invention (anymore, as they might have been considered in the uniprocessor era).

A key goal of Wasm is to be a portable (and safe!) abstraction over hardware. Thus exposing extremely pervasive hardware abstractions like threads is well within its mission. Doing so safely has meant careful design and specification that captures what hardware gives for memory models without forcing a new programming model or undue burden on languages, toolchains, or runtimes.

Given that there are literally billions of lines of software that use threads, hardware actually implements threads, and the entire stack is driven to optimize threads, it would indeed be a bold move to impose a different abstraction at the Wasm level. An abstraction that would incidentally be immediately used to emulate threads. That's a real layering screwup--abstraction inversion.

Also, I think your pedantry is unwarranted and a distraction. Many people accept the claim that threads are "true parallelism" and would consider cooperative (or even green) threading systems to be "not what we meant when we said threads". It's just a red herring to go off and discuss technicalities when the context is clearly Wasm exposing hardware threads.

That would be a win if performance was the same!

(Hopefully the new `Memory{T}` type makes it possible to compile even more code.)

Edit: I guess it will make allocation hoisting slightly easier.

That's obviously a common misconception given the name -- LLVM was meant to be a VM early in its life, but never was, and isn't now. It's clarified in the first sentence of a home page - https://llvm.org/

It's basically a bunch of C++ libraries that implements an IR that changes over time, which help you write compilers.

Curiously, I think a decade or more ago there was a project at Google targeting the same space as WASM which made this mistake. They thought LLVM was a virtual machine! That was PNaCl or something.

I guess it's a little like LuaJIT freezing Lua at Lua 5.1 -- Lua was never a standard, but for the purposes of re-implementation, a specific version of it can be frozen. (But there are obvious problems with that approach, namely that the re-implementers don't know about all the bugs they're also freezing in time.)

---

I have raised some eyebrows at the "compromises" of WASM, but the once thing that you can't doubt is that it is in fact a virtual machine !!!

I watched a talk on the WASM GC, and the creators were up front about the compromises (e.g. you will need runtime casts at first, with the measured overhead being reasonable), which gives me more confidence in it:

https://old.reddit.com/r/ProgrammingLanguages/comments/17crk...

I feel like I really don't get wasm. It's not clear to me what problem we're trying to solve here...

Is the goal to be able to write applications in programming languages that aren't javascript or (transpiled to javascript)? Does that include writing the parts that interact with the browser's DOM presentation layer? I think my understanding is that you can't actually do that? If that's right, is the goal instead to be able to run applications in a dedicated canvas within the DOM, like how Flash worked? If so, how big is the niche for that?

Or somebody in a different thread mentioned using wasm for cloudflare workers. Because those work via a javascript interpreter, I guess? But, like, if people want to write cloudflare workers in arbitrary runtimes, couldn't cloudflare just add support for those other runtimes? Surely they have the wherewithal to do that...

Or is there something that is uniquely great about wasm as a bytecode, beyond its connection to the javascript ecosystem?

I just really feel like I've missed reading some introductory material on why this technology is exciting, but it's embarrassing to ask at this late point...

For example, there's a project called Oak (https://github.com/project-oak/oak) that basically allows your private information to be processed by servers without revealing them to the servers. It uses a bunch of technologies and wasm is a center piece for allowing a safe form of code execution.

For another example, check out Mozilla's post about securing Firefox with wasm (https://hacks.mozilla.org/2020/02/securing-firefox-with-weba...). Again, here we compile C/C++ code with unknown memory safety properties into wasm and then compile that to native code. The benefit of doing it over directly compiling C/C++ to native code is that any memory safety issue is strictly sandboxed to be within the wasm module. You can't have one library's memory safety bug trampling over another library's memory.

WasmGC, which is the proposal under current discussion, is one of the biggest steps towards that. You can't safely interact with the DOM if you can't pin references to the DOM. You can't pin references to the DOM if you can't let the JS VM garbage collect you (or otherwise understand your garbage collection needs).

(One of the demos mentioned in the article shows Dart/Flutter driving what seems to be a lot of DOM via GC pointers. I haven't dug in far enough to see exactly what the balance is between JS and Dart there, but it should be a lot closer than previous demos.)

Besides memory checking, there are much fewer nasty things a process can do in terms of control flow since executable memory (procedures) do not exist in linear memory. It supports function pointers via a separate table system (kind of like having a separate address space for executable memory). All of this is in place so if a WASM module crashes, it doesn't take down whatever process it's running in.

LLVM (without a lot of coding anyway, wasmer has an LLVM backend) doesn't do the whole "easy secure sandbox by default" thing, which IMHO is easily the biggest differentiator of WASM.

WASM saw that and decided to make security priority number one from day one.

More like "WASM is the new JVM".

It's just turning into, excuse my philosophy nerdism ... like Hegel's quip about “the night in which all cows are black.” An Absolute into which meaningful content just dissolves. A proverbial hammer looking for nails, and finding them everywhere, but honestly, adding no new utility.

Wasm in the browser for porting certain kinds of apps makes a lot of sense. But if you're running e.g. JS inside Wasm on a server somewhere, you got off on the wrong exit on the hype train. You don't need to do that. It's neat that you can, but ... don't.

A "universal runtime" is a kind of ultimate nerd fantasy. I've had it too. It's also mostly pointless overhead. The reality is that containerized or virtualized execution already exists and there's no "universal" garbage collection or virtual machine. They end up inevitably tailored to the language they're there to support. And that's not a bad thing.

a lot of modern things have reach this point. You cannot possibly build your own car. You cannot possibly build your own house from scratch (too much of it require specialist knowledge, like building code etc).

It’s not too steep, it is literally impossible. A whole OS is a much easier deal than a browser.

He's talking about a browser that works with all the web pages. That's virtually impossible. Even Microsoft gave up. Mozilla are just about hanging in the fight but I would not at all be surprised if they fail at some point.

Browsers that only work with some pages are interesting to nerds, but normal people will use Chrome because it's still a great browser and it always works.

Why would the world's most successful & available hypermedia platform need to be something one can easily implement? Of course the most successful online system in the world is complex & featureful. That's why we use it & it has won.

you’re literally just not in the right circles.

> Of course the most successful online system in the world is complex & featureful. That's why we use it & it has won.

combine these two and you get the meme about IRC users (a protocol you could implement in a day) who refuse to leave that ecosystem. so as a starting point, if you’re looking for the people who are passionate about that kind of simplicity, you’ll have to meet them there. i’d start with the alternative kernels/OS (serenity, 9front, hurd) and then maybe the language side of things (Hare certainly has a prominent dev known for ranting about complexities). either way if you’re willing to dig, you absolutely will find the viewpoints around simplicity which you posit don’t exist.

Gopher and Gemini might be up your alley too. not as low in the stack as the others, but especially the latter's a pretty direct response against "Why would the world's most successful & available hypermedia platform need to be something one can easily implement".

> Linux From Scratch (LFS) is a project that provides you with step-by-step instructions for building your own custom Linux system, entirely from source code.

https://www.linuxfromscratch.org/

I still think what-one-person-can-solo-recreate is an awful terrible gate to limit what software is acceptable by though!

I look at how quickly & how competently people can make interesting powerful software systems on the web, that they can share & that can connect people, and I am in awe. Prioritizing recreating the platform is so low on my list of priorities: it's this time to power for devs, new & experienced, that seems like the better goal. And here the web just trounces everything else.

With just vanilla and some basic html one can take a page & very quickly begin to make it dance, in all kinds of wild ways.

I can take someone with a couple days of programming & pair with them & in a couple hours we can write a user script to rewrite some kind of weird or suboptimal computing experience they're already having, show them how easy it is to modify & improve their life & the online things they go through. That power is just amazing, and that there is so much freedom under the hood to be creative & do great things: that's thrilling & exciting for us all.

Time to start: fast, but with deep reserves of capabilities one can always tap into: that's greatness. The web's power curve is so much more exciting than anything else I've ever gotten to share with newcomers to the field. Connecting newcomers to computing has never been better, thanks to the great & powerful web.

I'm curious how much this will help some of the WASM-targeting languages that have issues with large binaries from building their runtime. IIRC, Blazor requires something like 1 MB just for a hello world; I wonder if WasmGC will help with that.

My concern, of course, is that there is not much incentive for those features to be added if .NET is the only platform that needs them... at that point having a form of 'include' (to where a specific GC version can just be cached and loaded by another WASM assembly) would be more useful, despite the pain it would create.

[0] - https://github.com/WebAssembly/gc/issues/77

https://developer.chrome.com/blog/wasmgc/

For Blazor, it'll only help with the GC - IIRC Blazor has to ship the entire dotnet runtime.

As of a few days ago, IOS support in alpha and will hit beta next year. Android and desktop support are now stable. Once that stuff stabilizes, you can write UI applications that basically work on any platform.

The wasm compiler will roll out along with kotlin 2.0 which is the next major release for Kotlin and features a new compiler (k2). This looks like it should happen early next year. k2 is currently available in beta release and you can enable it in kotlin 1.9.x.

The nice thing with the Kotlin multiplatform ecosystem is that there are already a lot of libraries that work across the various platforms. So, the wasm compiler will rapidly become part of that and inherit a lot of nice libraries. Mostly all that takes is for builds to be reconfigured to target that ecosystem and implementing some platform specific behavior where that is missing.

Another interesting thing in this space is using and linking libraries written in different libraries. For example a lot of the platform specifics are probably going to be dependent on e.g. C or Rust libraries that are already available. In many cases these might be the same libraries that Kotlin native uses.

Do you use the same widgets on Desktop, web, iOS and Android? I understand that on Android it's native. Does it emulate other styles on other platform? I guess, my question is mostly: How is the _feel_ of a Compose Multiplatform App on non-Android platforms.

Dart on web e.g. feels extremely janky to me, so does electron on Desktop. Dart on Desktop is ok, but all the applications tend to be very App-like with huge buttons and whitespace that just make it feel more like it was an Android App running in an emulator rather than an actual native app.

Would you recommend Kotlin as a language for new projects?

There is also compose web html which seems to be not getting a lot of attention lately. That depends on kotlin-js and works with the dom tree. But for obvious reasons it's a lot less easy to use the same components there.

I think it's too early to tell how it will perform, look, and feel on every platform. This is also a bit of a function of how much effort and design you put in. Using wasm in the browser should help with performance though. Dart might copy that trick as well. I think they currently cross compile to javascript.

Kotlin as a language is more than fine. Anything server related or Android related, it's a great language and I vastly prefer it to Java at this point (27 years of experience). I personally use it for web development (kotlin-js in the browser) and server development (spring-boot, ktor). IOS native development for libraries is also a popular option for sharing code across IOS and Android. That just got promoted to a stable release. There are some gotchas with interoperability with e.g. Swift and Flutter from what I understand. But it's basically very stable and workable at this point and fairly widely used.

Compose multiplatform is not quite ready yet. The Android and Desktop side work fine and are stable. But the rest is a work in progress. Compose web is going to be a while because even the compiler isn't ready yet. Compose IOS looks like it should get to a usable stage in the next six months or so. Stable is probably at least a year out for that.

https://developer.mozilla.org/en-US/docs/Web/HTML/Element/ca...

That's what this WasmGC is for :) Dart on web runs as dart2js whereas other platforms like Android/iOS/macOS/Linux/Windows runs as AOT arm64 or x86_64 code. Dart on wasm (as shown in demo in the article) will run better than transpiled JavaScript.

The syntactically similar language I’d rather have run everywhere is Swift. Swift Package Manager has problems too of course but in my experience has been less maddening, and the community has been more aggressive about writing native Swift replacements for Obj-C libraries.

What does this even mean?

There’s a similar issues with using Objective-C and C libraries in Swift, which makes Swift libraries more appealing where available despite Obj-C/C interop being good.

The only case I can think of is wrapping callbacks with coroutines, everything else will work in Kotlin out of the box.

EDIT: just to add some background, I am staunchly against any development platform that requires a developer to build a ridiculously complicated nest of file structures, libraries, bindings, etc out of dozens if not hundreds of disparate and usually incompatible projects yoinked from the internet that further makes broad and undocumented assumptions about the dev machine you're trying to install this all on.

Also bear in mind that package managers by themselves often make this process worse instead of better because they then proceed to proliferate into an entirely different level of the trashfire hierarchy. Get node/npm even though you're not coding in Javascript, then still have to get chocolaty or flatpack or fall back to trying to insulate everything into a docker container or use pip to install python packages but then drag out the venv when different projects want different versions of the packages and then further drag out conda when they want different versions of python as well.

Too much of the environment assumes that the developer is already steeped in all of the thousands of compromises existing developers have slowly gotten accustomed to over years of yielding and putting up with it. Another day, another fault line along which to fragment every tool you need just to create "hello world".

Gradle is generic, which does increase its surface area, but there is not many alternatives that are also fast and correct: there is bazel, and a new thing I very like: mill. But not much else is there.

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?

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.

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.

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.

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.

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

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.

  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

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

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

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.

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?

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...

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

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.

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.

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.

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....

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.)

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.

> 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.

>>"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.

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.

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.

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.

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.

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.

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.

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.

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

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 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.

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.

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?

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

Nope. No interior pointers for one.

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

Can you explain some more?

Seemed to me that it did?

Example given in the link.

https://gist.github.com/kripken/5cd3e18b6de41c559d590e44252e...

Or is it that the GC ignores interior pointers during mark and sweep?

Then once Java introduces value types, wouldn't the language encounter the same problem for composite types?

Would be a weird choice to not handle interior pointers.

I'm a bit out-of-my-depth here, just wondering.

In Go you can have a fixed-size array of structs, where each struct contains many fields, including a fixed-size array field. The whole thing can be allocated at once and is automatically zeroed out. And then you can take a pointer to any struct’s field or any internal array element.

“Interior” means the interior of a single object. A pointer to anywhere within an object prevents it from being collected.

Depending on how much code you want to run it may be interesting to be able to decide between shipping a GC implementation and slowing down your code to avoid it. If it is an extra 50% code size on top of a fairly small amount of first-party code you may pick WasmGC.

The overhead compared with interior pointers is relatively high due to the extra space for the fat pointer index, which space is taken everywhere a pointer could be an interior pointer, even if it's rare.

When a language runtime can optimise in whatever way it needs to, if interior pointers aren't an option there are various schemes to avoid the fat pointer space overhead and replace it with time overhead, but they often involve using unused bits in the pointer word, or recognise certain address ranges. Unfortunately, I assume those techniques are incompatible with a GC like WasmGC's, which requires all pointers to use the standard pointer representation, so prevents these kinds of space and time optimisations.

Whether a pointer is an interior pointer or not isn’t part of its type in Go.

https://habr-com.translate.goog/ru/articles/757182/?_x_tr_sl...

and the original article:

https://habr.com/ru/articles/757182/

This is from the author of TeaVM, who has 10 years of experience getting Java and JVM code to run efficiently in the browser. https://teavm.org/

TeaVM's existing transpilation of Java to JavaScript performs well (using the browsers JS GC). It will be interesting to see if WASM GC matures to the point where it is even faster.

Notes on the issues mentioned there:

* The need for a manual shadow stack: This is fixed in WasmGC (in the same way it works in JS, as the link mentions).

* Lack of try-catch: This is fixed by the Wasm exception handling proposal, which has already shipped in browsers, https://github.com/WebAssembly/exception-handling/blob/main/...

* Null checks: Mostly fixed by WasmGC. The spec defines non-nullable local types, and VMs can use the techniques the article mentions to optimize them using signals (Wizard does, for example).

* Class initialization: This is a difficult problem, as the article says. J2Wasm and Binaryen are working to optimize it through static analysis at the toolchain level. Here is a recent PR I wrote that makes progress there: https://github.com/WebAssembly/binaryen/pull/6061

* The vtable overhead issue the article mentions may be a problem. I'm not aware of good measurements on it, through. There are some ideas on post-MVP solutions for method dispatch that might help, but nothing concrete yet.

* Checks for null and trapping: There has been discussion of variants on the GC instructions that throw instead of trap. Measurements, however, have not shown it to be a big problem atm, so it is low priority.

The author is right that stack walking, signals, and memory control are important areas that could help here.

Overall with WasmGC and exceptions we are in a pretty good place for Java as emitted by J2Wasm today: it is usually faster than J2CL which compiles Java to JavaScript. But there is definitely room for improvement.

Would it make sense for the runtime to expose an inbuilt alloc library that C/C++/Rust can use? Programs could opt in to that library instead of bundling their own allocation library.

But a memory allocator API for malloc/free or whatever is not a minimal feature. A memory allocator is actually a bunch of policy and design decisions, and the algorithms used by the allocator will flow from those. The fundamental building block there is just "a linear piece of memory owned by the allocator", and that already exists. It's the linear memory WASM has had since day 1!

It might make sense for individual runtimes to do it though, i.e. give some built-in wasm import a piece of the linear memory and let a runtime-implemented allocator handle it. But it would almost certainly never become standardized I bet, and almost all of the tooling for non-GC'd Wasm languages is basically designed around porting working, existing codebases, including their allocators. So it's just more code to maintain for one-off implementations. The juice might not be worth the squeeze.

A difficulty with that approach is that the alloc library's behavior would need to be standardized and deterministic. If it isn't deterministic then differences in program behavior can end up mattering. For example, if one browser ships a "smarter" alloc that reuses memory better then it could succeed to run a program that another browser ends up with fragmentation in linear memory and an OOM. Historically browsers have worked really hard to standardize behavior to avoid such differences.

And standardizing the behavior of a malloc/free implementation is tricky for several reasons. First, there is a lot of complexity there - how you handle free lists, what chunk sizes do you use, etc. That's a lot to put in a spec. Second, once you standardize a particular behavior it can't be improved, and new ideas for better malloc/free are still being found.

For those reasons I'm skeptical of this making its way into the wasm spec.

In comparison, GC avoids these problems because there is nothing to spec: the pointer values are not observable.

Continuing with this analogy, that once all the building block are in place (GC, threads etc.), it would be time for building a WebAssembly-native programming language.

The wasm security model is a lot more complex than your CPU's. It was never a virtual CPI architecture.

And because it's not a virtual CPU architecture, it need those extra complexities. Your CPU is designed for running high-level languages without any of those extra features, but wasm can't do it (well enough).

https://www.destroyallsoftware.com/talks/the-birth-and-death...

That's why they are making it more complex.

https://spritely.institute/news/hoot-wireworld-live-in-brows...

Do you also not run javascript code of websites that has been run through a transpiler with tree-shaking and minification? Because WASM is about as locked down as that.

What does it even mean?

Containers have absolutely nothing to do with the topic, and I’m afraid if you mix them up with the former kind of “VM”s your point is moot.

Obviously this is terrible for document websites that need to be SEO optimised, however it would be great for dynamic web applications (think banking apps or Jira).

In those cases, the HTML file is just an unnecessary extra request and can actually contribute to slightly slower start up times.

Perhaps simply allowing html files to be sent in some kind of binary format where a wasm binary is inlined would be a more practical approach - as the html file does act as a kind of app manifest.

I mean you could just re-enable the Java Applet and everything would be solved.

I've been using Blazor for some time now (server-side mode), and I feel like even this part without WASM is overkill complexity for 99% of the target audience. Adding the client-side WASM piece just kicks it into another dimension of "hard to reason with".

Stack machines often cannot be targeted the same way as register machines; in addition, the fact that the call-stack doesn't share address space with the heap causes challenges.

Have a few years of professional compiler/VM experience, always looking for new challenges.

Without this, you can't really run languages like Go or C# inside the VM.

https://www.ptc.com/en/products/developer-tools/perc

https://www.aicas.com/wp/products-services/jamaicavm/

https://www.microej.com/

https://github.com/WebAssembly/gc/blob/main/proposals/gc/Pos...

If Go could depend on WASM having a GC, and if Go doesn't have some sort of critical semantic mismatch with what WASM implements... and it is shocking how small the mismatch has to be before it becomes a critical problem sometimes... then the Go WASM binaries could get smaller by not needing to ship a full GC. However, it's still going to be pretty large even so.

It's probably a critical feature for Go to be able to go WASM and in the long term be able to use WASM-based code, because it's often important for it to at least be an option. But I seriously doubt any WASM-first project in the next several years is ever going to pick Go as its base. You start with an awful lot of compromises right off the bat.

If WASM succeeds, it will slowly but surely start to escape the browser. When you're not in a browser anymore, and you have something like a WASM executable in hand that you want to run in some WASM environment for some reason, the tradeoffs get less bad, for much the same reason it is usually not that big a deal that Go executables can be a bit on the large side right now. But this is still years off. WASM's immediate future is in the browser, where the extra large runtime and build sizes is not necessarily a fatal objection, but a fairly significant cost right up front compared to a lot of alternatives.

And tinygo is an alternative compiler that implements another GC algorithm and aims at shipping small binaries, including wasm files.

- reference types: https://github.com/WebAssembly/reference-types/blob/master/p...

- interface types (inactive): https://github.com/WebAssembly/interface-types/blob/main/pro...

- component model: https://github.com/WebAssembly/component-model

If this looks like a hot mess, that's because it is. Compared to that, the current solution to go through a Javascript shim doesn't look too bad IMHO.

The GC support allows you to safely pass GC objects around without them dissapearing (being collected) on you.