design

As far as I can tell (5 minutes of internet research) this was to allow easier compilation to JavaScript as a fallback in the days when WASM wasn't widely supported. "Please add goto" issue has been open since 2016: https://github.com/WebAssembly/design/issues/796 Most interesting comment: > The upcoming Go 1.11 release will have experimental support for WebAssembly. This will include full support for all of Go's features, including goroutines, channels, etc. However, the performance of the generated WebAssembly is currently not that good. > This is mainly because of the missing goto instruction. Without the goto instruction we had to resort to using a toplevel loop and jump table in every function. Using the relooper algorithm is not an option for us, because when switching between goroutines we need to be able to resume execution at dif

Quite a letdown that the solution for a web-based spreadsheet is for users to install a local backend. Might be a case for edge computing even. > WebAssembly has a single contiguous, linear memory space shared by all dynamic memory allocations. This means that WASM cannot make use of several memory management features that operating systems provide, such as Virtual Memory, Swapping, etc. Additionally, it cannot make use of the CPU’s MMU optimisations such as prefetching and caching. WebAssembly has memory issues, but those are not them. Virtual memory and swapping are OS features that work at the page level. CPU prefetching and caching are CPU features that work at the cacheline/address level. [1] covers the major design limitations with WebAssembly memory. [1] https://github.com/WebAssembly/design/issues/1397

Wasm itself provides some determinism constraints[1] as an explicit design goal, which is what enables things like this. I made a very simple snapshottable compute executer for a talk last year and it took surprisingly little code if you want a look at how it works[2], but the complexity of something like Flawless is that doing anything useful involves communicating with the outside world, where non-determinism can easily sneak in. I've been following Bernard's work on Lunatic so I'm incredibly excited to see he's tackling these hard problems. [1] https://github.com/WebAssembly/design/blob/main/Nondetermini... [2] https://github.com/drifting-in-space/wasmbox/tree/main

When I implemented a WASM compiler, the only source of float-based non-determinism I found was in the exact byte representation of NaN. Floating point math is deterministic. See https://webassembly.org/docs/faq/#why-is-there-no-fast-math-... and https://github.com/WebAssembly/design/blob/main/Nondetermini....

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

Giving you a buffer that grows is the allocation approach I am talking about. This is not how your OS works. Your OS itself works with an allocator that does a pretty good job making sure that your memory ends up not fragmented. Because WASM is in between, the OS is not in control of the memory, and instead the browser is. The browser implementation of "bring your own allocator" is cute but realistically just a waste of time for everybody who wants to deploy a wasm app because whatever allocator you bring is crippled by the overarching allocator of the browser messing everything up. It seems like the vendors are recognizing this though, with firefox now having a discard function aparently! https://github.com/WebAssembly/design/issues/1397

Scientific performance critical code isn't written in Python, it is written in C/C++ which is used by Python. Python in ML usually merely describes the calculation not unlike React describes the DOM that should be displayed in the browser. JavaScript was never really known for admin or file manipulation (Perl replacement), so that was what probably established the dominant ecosystem for Python. I also don't think the runtime overhead is applicable due to native C/C++ part, and download time doesn't have to be bad since modules can be split just like in JavaScript ecosystem today. For an AI app, the model inference weights might be larger than the compiled WASM code itself. However, I'd agree with you that porting legacy apps might not be possible without something close to a rewrite. There is a reasonable chance that once WASM GC is imple