Hacker News Reader

> I really do not understand the push to provide higher-level features as intrinsic types and instructions

As mentioned in the article, the purpose of WebAssembly is not to provide the lowest level instruction support possible but to be a good compilation target. Not having a string type makes targeting WASM GC more complicated and the runtime less efficient.

> By putting it directly into the instruction set, you'd be baking in assumptions about how JS engines in 2023 function, even though those assumptions can (and hopefully will) change over time.

The stringref proposal does a good job of balancing the world we exist in with the "right thing", IMO. I implemented a subset of it for an interpreter hosted in Guile Scheme, using Guile's string type which is very unlike Java/JavaScript (not UTF-16), and it works well. I'd like to see the proposal get more support.

I don't understand how the counter-proposal makes WebAssembly a worse compilation target.

Take the simple example of memory.copy. How is it worse to compile memcpy() to import+memcpy() rather than memory.copy?

Why can't a string type be efficiently GC'd via an imported type?

To work with GC, you need some way to track if the GC'd object is accessible in WASM itself. You can't just have gc.release $addr because then you need to introduce a check everywhere you try and do something with $addr in WASM as WASM is supposed to be memory safe.

The reason why you probably need a custom string type is so you can actually embed string literals without relying on interop with the environment. If a WASM module tries to simulate this by having an initialization function that constructs all your string constants in linear memory or something, I could see that getting pretty expensive and/or difficult to optimize.

> To work with GC, you need some way to track if the GC'd object is accessible in WASM itself.

I've never heard of a GC with that kind of API. Usually any native code that holds a GC reference would either mark that reference as a root explicitly (eg. https://github.com/WebAssembly/design/issues/1459) or ensure that it can be traced from a parent object. Either way, this should prevent collection of the object for as long as the reference is reachable from a root. I agree that explicitly checking whether a GC'd object has been freed would not make any sense.

> The reason why you probably need a custom string type is so you can actually embed string literals without relying on interop with the environment.

WASM already has ways of embedding flat string data. This can be materialized into GC/heap objects at module startup. This must happen in some form anyway, as all GC-able objects must be registered with the GC upon creation, for them to be discoverable as candidates for collection.

Overall I still don't understand the issue. There is so much prior art for these patterns in native extensions for Python, PHP, Ruby, etc.

I think string builtins seem to be the direction the wasm committee is moving towards anyways? Unless I'm mistaken

Yeah, the JS String Builtins proposal is an alternative to stringref. Having experienced some of both, I think that stringref is much better.

Yeah, builtins seem like a bit of a specialized case. If I'm not mistaken, it doesn't even really give a Wasm-side method to create strings? Bit of a shame.

Right, inside the wasm module you're on your own and you use (array i8). Alternatively, you could decide that your strings are the host's strings and use (ref extern), but performance within the wasm module suffers because every string operation is a host call. The least worst option right now is (array i8) internally and copying whenever they cross the guest/host boundary.

I believe it's mainly because of the requirements for

(1) integration with a single GC (the one in the browser), and

(2) zero-copy inter-op with JavaScript strings.

If you take them as axioms, those pretty much force you to put strings as a native type in WASM. They can't really be done as libraries.

Not sure if it helps, but I wrote about my experience writing a GC here, and the "reality sandwich" metaphor:

https://www.oilshell.org/blog/2023/01/garbage-collector.html

https://lobste.rs/s/v5ferx/scheme_browser_hoot_tale#c_n87bzw

https://lobste.rs/s/v5ferx/scheme_browser_hoot_tale#c_mw6tfx

The sandwich has:

(1) the mutator's view on one side

(2) the single bit representation of data types in the middle

(3) the GC's view on the other side

Basically a bunch of people thought that you could just have one half of the sandwich -- you could just have the GC, and use whatever data types you want.

Implementing a GC will disabuse you of that notion (ESPECIALLY a GC that runs remote, untrusted code, but it's true for any GC.)

The core data types and the GC are tightly coupled, and the GC already lives in the browser.

So WASM necessarily gives you the WHOLE sandwich -- both data types and the GC. Fundamentally, it can't do anything else.

But that means that the data types are a huge design compromise -- there are winners and losers. Now you have a MAPPING problem from every language to WASM types.

---

As a concrete example, I mentioned that Go has slices, which are reference types, and they have pointers to anywhere in a string.

This means the GC has to be able to find the head of a string from an interior pointer, which is hard in general.

So, without being very close to WASM GC, I suspect Go will be a loser in this respect (it will perform less well), simply because JS GC's don't have to deal with interior pointers.

Every design decision involves winners and losers -- "universal VM" is a bit of a fallacy.

---

Strings are another area where there are winners and losers -- UTF-16 means JS/Java perform better, but UTF-8 means other languages perform better.

Although this stringref proposal is interesting because it tries not to be biased -- it tries to develop an API that can be implemented with both UTF-8 or UTF-16 representations. Still, it's very hard problem and involves deep compromises.

> They can't really be done as libraries.

It's definitely the case that you can't implement a string type in WASM and have it interoperate with JavaScript strings.

But there is no reason that JavaScript strings can't be a "special" kind of import that provides functionality implemented by the engine. In other words, #include <wasm/wtf16string.h> could provide an API for the built-in JavaScript string, much like #include <ruby.h> provides access to the native Ruby string in Ruby extensions.

I believe this is how the counter-proposal works: https://github.com/WebAssembly/js-string-builtins/blob/main/...

For engines that do not have a built-in JavaScript-like string type, the wasm/wtf16string.h library could be implemented in WASM as a polyfill. In that case, there is no native string to interoperate with, so no disadvantage to implementing directly in WASM (except perhaps a bit of speed penalty).

What I'm reading there is that it's less ambitious -- it would only work for languages that have JavaScript string semantics.

Some languages targeting WebAssembly may have compatible primitives and would benefit from being able to use the equivalent JavaScript primitive for their implementation

I believe Java fits that bill (it's UTF-16, at least). So if you were writing a JVM to work on WASM, then you could possibly just import the JS string and use it, and get zero-copy inter-op.

---

But what the Wingo article is saying is they want something even more ambitious: have a working Scheme or Python or Lua implementation with zero-copy JS inter-op.

If they can paper over the bytes vs. UTF-16 vs. code points API issue, making a single string type that's not biased toward one or the other, I think it's a step in the right direction. (The aside about decoupling JS itself from UTF-16 string APIs is pretty intriguing too!)

But it's still not obvious to me that even this gets you all the way there. For example, Python interns some strings, and Lua apparently interns ALL strings, and they both have hash codes in the string object, and expose it to users. (Even changes to the hash function may break some programs)

Unique object IDs in many languages are another issue -- the JVM apparently uses space for them in the header of every object.

So you still may have more compromises about how to implement the WASM string, that produces winners and losers. The only way to know how the compromises pan out is to try, and I'm glad people are doing that.

---

So anyway, I'm not very close to WASM, but I do see a pretty clear difference between the proposals. I think it depends on what the goals are -- is "running Python or Scheme with zero-copy JS string interop" a goal?

I guess people want to manipulate the DOM directly from Scheme or Python, which seems reasonable. If you have to copy all the strings, that will be a huge drag. DOM operations are already hugely expensive and have tons of objects. It seems like the proposal you linked doesn't address that issue.