Bytecode Alliance

Late to the party, but I didn't see anyone mentioning this: Shopify seems to be curiously extremely involved in sponsoring WebAssembly-related projects. It's a gold sponsor on AssemblyScript[1], it used to develop javy[2] which compiles JavaScript to WebAssembly, a member of the BytecodeAlliance[3]. I wouldn't think they sponsor LadyBird just for LibWasm[4], as that doesn't make any sense, but technically, they add that to their wasm sponsorships now. Honestly, it looks like a really nice place to work if you like WebAssembly, I wouldn't mind a collaboration or to work with them. [1] https://www.assemblyscript.org/ [2] https://github.com/Shopify/javy [3] https://bytecodealliance.org/ [4] https://github.com/SerenityOS/serenity/tree/master/Userland/Libraries/…

That's the pain. This, Microsoft, AWS etc they should have something like https://bytecodealliance.org/ I found that their language semantics are pretty similar, probably deserve at least the same AST.

Thanks. Interested in out-of-browser runtime here so Google does not count. I think Intel and Fastly are together at https://bytecodealliance.org/ along with Microsoft and Mozilla. wazero is totally new to me, will watch it.

Wasmer is considered a bad actor by many, and there are many in the WASM space who want nothing to do with them. It's no accident Wasmer isn't a part of the Bytecode Alliance [1]. A particularly damning incident was the time they tried and failed to trademark "WEBASSEMBLY", an open W3C standard [2] [3]. There are many choice words for companies trying these kinds of stunts. Webassembly is growing despite Wasmer's existence. Not because of them. Be cautious. [1]: https://bytecodealliance.org/ [2]: https://tsdr.uspto.gov/documentviewer?caseId=sn88703780&docId=OOA2… [3]: https://github.com/WebAssembly/WASI/issues/3#issuecomment-713048681

It's really the other way around: we joined Fastly because we knew it's a place where we could do this kind of work in the open. None of the code involved here existed a year ago, and none of it was somehow forced to be open source. (Also, the code in these two repositories is in many ways the most boring part of this solution. See this blog post for an excellent overview of the more interesting parts: https://bytecodealliance.org/articles/making-javascript-run-fast-on-we…

For what it's worth, the Fastly team recently ported spidermonkey to WASI https://bugzilla.mozilla.org/show_bug.cgi?id=1701197 https://spidermonkey.dev/blog/2021/07/19/newsletter-firefox-90-91.html… https://bytecodealliance.org/articles/making-javascript-run-fast-on-we…

Ah my bad, I think I misunderstood your comment. I was reaffirming this: > wasm can still be JITimed and get close to native performance I’m also not super familiar with this subject, so I unfortunately don’t understand the distinction you’re making between source and target. > Seems like it's not really providing the needed tools and you'd have to build a lot of basics on top of it My understanding is that this is accurate, and folks like the Bytecode Alliance[0] are working on building that ecosystem of tools on top of WASM, and I see wasmtime as being one of those tools. [0] https://bytecodealliance.org/

This paper describes how Vanessa's groundbreaking Smalltalk VM implemented in JavaScript runs historic Smalltalk images, and elegantly and efficiently integrates Smalltalk's garbage collector with JavaScript's. I've written about her work and this paper previously on Hacker News: https://news.ycombinator.com/item?id=40917424 DonHopkins 4 months ago | parent | context | favorite | on: Dynamic translation of Smalltalk to WebAssembly Here's some stuff Vanessa and I discussed about Self and her SqueakJS paper: DonHopkins 6 months ago | parent | context | favorite | on: Croquet: Live, network-transparent 3D gaming Excellent article -- Liam Proven does it again! Speaking of a big Plate of Shrimp -- https://www.youtube.com/watch?v=rJE2gPQ_Yp8 ... The incredible Smalltalk developer Vanessa Freudenberg -- who besides being Croquet's devops person, also developed Squeak Smalltalk, EToys, Croquet, and the SqueakJS VM written in JavaScript, and worked extensively with Alan Kay -- was just tweeting (yeah, it's ok to deadname Twitter!) about reviving Croquet from 20 years ago: https://twitter.com/codefrau/status/1738778761104068754 Vanessa Freudenberg @codefrau I've been having fun reviving the Croquet from 20 years ago using @SqueakJS . It's not perfect yet, but a lot of the old demos work (sans collaboration, so far). This is pretty close to the version Alan Kay used to give his Turing Award lecture in 2004: https://github.com/codefrau/jasmine Live version:…

The roadmap I linked above. The WASI folks have done a poor job at communicating, no doubt. Just for you I did some googling: see here[0] for the current status of WASI threads overall, or here[1] and here[2] for what they are up to with WASI in general. In this PR[3] you can see they enabled threads (atomic instructions and shared memory, not thread creation) by default in wasmtime. And in this[4] repository you can see they are actively developing the thread creation API and have it as their #1 priority. If folks want to use WASIX as a quick and dirty hack to compile existing programs, then by all means, have at it! I think that's great. Just know that your WASIX program isn't going to run natively in wasmtime (arguably the best WASM runtime with the strongest long-term outlook), nor will it run in browsers, because they're going to follow standards.. not WASIX. I don't think anyone believes exposing POSIX fork() to WASM is a good idea, even if it lets you build existing apps 'without modification'. Please stop accusing me of being polarizing. I just don't want to live in a world with two competing WASI standards, two competing thread creation APIs, and a split WASM ecosystem overall. I want good tech to win, not shitty power plays. [0] https://github.com/bytecodealliance/jco/issues/247#issuecomment-179918… [1] https://bytecodealliance.org/articles/wasmtime-and-cranelift-in-2023 [2]…

Interesting to see that it has JavaScript support built in. It seems to be based on QuickJS which will work for some things but as they acknowledge quite slow. > In the end, running v8 in a cloud-native environment often requires a full stack of software tools consisting of "Linux container + guest OS + node or deno + v8", which makes it much heavier and slower than a simple WasmEdge + QuickJS container runtime. https://wasmedge.org/book/en/write_wasm/js.html#a-note-on-v8 Whether it's faster or not really depends on the complexity of what's being run. After reading about wasmtime 1.0's super fast 5 microsecond snapshot restore time (https://bytecodealliance.org/articles/wasmtime-1-0-fast-safe-and-produ… I did some experiments with QuickJS and Javy which runs QuickJS in wasmtime. Rendering a moderately complex web page with React renderToString production 30kB of html on my MacBook Air M1 took: - Deno first iteration: 12-20ms - Deno subsequent iterations: 2-4ms - qjs native: 18-24ms - javy (qjs wasmtime): 40-60ms I've not tried WasmEdge but it's JS performance would presumably fall somewhere between that of qjs native and under wasmtime. Firecracker claims a ~3ms snapshot restore time on ARM so might be the best way to go currently for such workloads but there is certainly a large subset of problems for which the current performance is adequate. There has been talk of AOT compilation for SpiderMonkey.wasm…

Typically the trademarks are held by the collation/organization behind the OSS or the open standard. Either that, or held by the person/org who created the software and released it. Here, wasmer is not the inventor of WebAssembly, and the group behind webassembly (the w3c community group and w3c working group) [^1] probably would be the ones you'd expect to own the trademark. It seems part of the motivation for Wasmer to apply for the trademark was because they felt snubbed by the Bytecode alliance [^2] and wanted to start their own foundation (with blackjack and hookers, presumably). The Bytecode alliance doesn't own any of the trademarks either, and seems to be more of a collaborative effort, but is worth mentioning as part of the overall story. [^1]: Groups listed here: https://webassembly.org/. and members here: https://www.w3.org/Consortium/Member/List and https://www.w3.org/community/webassembly/participants. Note that a few Wasmer employees (the CEO, for one) belong to the community group, but don't chair it. [^2]: https://bytecodealliance.org/ and https://wasmer.io/posts/wasmer-and-trademarks

> I can't really square the idea that the 50-150ms time-delays in question comes down to the actual programming language, but it is absolutely believable that a longer test reduces the median latency rather than a high load test for a shorter duration. It seems plausible to me: in Fastly's case, they're using WebAssembly via wasmtime[1] which does support AOT compilation but most JavaScript code is dynamic enough that they still need a runtime JIT engine. I believe the the current approach Fastly is using is to compile Mozilla's SpiderMonkey JIT engine itself into WebAssembly and they've done some really nice work making that load as quickly as possible: https://bytecodealliance.org/articles/making-javascript-run-fast-on-we… The catch, of course, is that this still leaves a fair amount work which a JavaScript program has to deal with at runtime compared to a Rust program which the compiler can spend minutes optimizing long before deployment. This is a classic tradeoff for dynamic languages and a lot of people are satisfied with the approach of defaulting to faster developer turnaround and later converting hot spots to something like C or Rust, but I think it's definitely dodgy to use a single example of something you know to be this complex and present the results as generally representative of the entire platform. I have no knowledge of how Cloudflare ran their tests or reason to suspect malice but not disclosing test methodology and a “no benchmarks” license…

It's lightweight, capability-secured, services start up way faster, smaller overhead than VMs, better isolation than containers, faster replication, etc. The original Wasmtime 1.0 blog post explains it all really well: https://bytecodealliance.org/articles/wasmtime-1-0-fast-safe-and-produ…

Hey everyone, we just published the announcement post for WASI 0.3 on the Bytecode Alliance blog: https://bytecodealliance.org/articles/WASI-0.3 The current link is just the release notes and covers only the interface-level changes. The announcement post goes into more detail on what's new in WASI 0.3, how it differs from WASI 0.2, and includes examples.

Lots of context for this project on the Bytecode Alliance blog: https://bytecodealliance.org/articles/endive-and-the-next-chapter-of-w…

See also https://bytecodealliance.org/articles/javy-hosted-project

Compiler dev has its share of insane plumbing but also rewards stubbornly finding O(N) heuristics to non-polynomial problems. Cranelift are doing interesting things, e.g. https://bytecodealliance.org/articles/cranelift-progress-2022

Embeddable plugin systems are absolutely a goal! See this part of the blog post: https://bytecodealliance.org/articles/wasmtime-1-0-fast-safe-and-produ…

https://bytecodealliance.org/articles/wasmtime-1-0-fast-safe-and-produ… Hope you saw wasmtime announcement Shopify etc

Wasm is Turing-complete. What people typically mean by this is that in a browser context, compiling JS to Wasm does not currently make it run faster than just running the JS as JS. Javascript can be compiled to WebAssembly, and there are people doing it: https://bytecodealliance.org/articles/making-javascript-run-fast-on-we…

There are interesting plans to speed up [the cold start latency of] V8 by compiling it to wasm[0] AFAIU the main point is that for wasm you can condense startup to a mmap operation and that you can "freeze" a running wasm process (essentially by dumping the memory/stacks to a new wasm module. In [0] they use [1] to do this. [0] https://bytecodealliance.org/articles/making-javascript-run-fast-on-we… [1] https://github.com/bytecodealliance/wizer

> Does WebAssembly even make sense as a standalone runtime, like the JVM? Is "server-side WebAssembly" going to be "a thing", or is it just a compatibility kludge? Yes, see: https://bytecodealliance.org/articles/1-year-update > Or would it be better to compile things directly to WebAssembly? It'd be even better to roll out one's own Lambda@Edge: https://krustlet.dev/

In the end I think the solution to these issues will be something like what's promised by the Bytecode Alliance[0]. The idea is you give each package its own WASM sandbox with granular control over its permissions. That solution also has the benefit of allowing you to call a package from any language from your language of choice. I highly recommnend reading their the article introducing the idea, its very convincing: [0] https://bytecodealliance.org/articles/announcing-the-bytecode-alliance

I don't think it's fair to say this work has happened in the shadows. I work on CNCF wasmCloud, and I know how hard we try to make this content available. - Many standing meetings organized around SIGs, all on the public community calendar: https://calendar.google.com/calendar/u/0/newembed?src=events@bytecodea… - A dedicated Zulip: https://bytecodealliance.zulipchat.com/ - Conferences organized around exactly these topics: Wasm Day, WasmCon, Wasm I/O, and the Bytecode Alliance Plumbers Summit - CNCF projects: wasmCloud, Spin - Blogs, many with recordings, summaries, and transcripts: https://bytecodealliance.org/articles/the-road-to-component-model-1-0, https://wasmcloud.com/community/, https://spinframework.dev/blog/index If you want the architectural direction straight from the source, Luke Wagner's keynotes are the best place to start: - "What is a Component (and Why)?" (WasmCon 2023): https://www.youtube.com/watch?v=tAACYA1Mwv4 - "The Path to Components": https://www.youtube.com/watch?v=phodPLY8zNE - "Towards a Component Model 1.0" (Wasm I/O 2026): https://www.youtube.com/watch?v=qq0Auw01tH8 I mean this, though - what else would you like to see to try and make the content and process more accessible? Are there communities that are doing this really well that we could use for inspiration?

I could have better explained what I was talking about. The point of a custom kernel would be to get extremely fast startup and context switch times, and extremely low per-process memory overhead, by doing things that Linux doesn't do - either because they're unnecessary or unhelpful for typical Linux use cases, or because they require making stronger assumptions about what userland needs to do. As a relatively flashy example, if you can assume that processes don't need overlapping addresses, you can share page tables between processes and rely on PCID/ASID to ensure each process can only access its own memory. [3] But there are also simpler things like - on Linux, starting a process requires forking the parent process, creating copies of its page tables, only for `exec` to immediately throw them away. Even posix_spawn is implemented on top of vfork. That's fast enough for Linux, but it's unnecessary. A custom kernel that doesn't provide Unix compatibility could dispense with it. To be fair, none of that may be necessary. This blog post is advertising 1-2ms startup time. Based on a little benchmark [1] I just ran, on my desktop, Linux can execute a trivial process (/bin/busybox true) from start to finish in 0.4ms. A real application executed normally would obviously take much longer to start up. But I think their 1-2ms number is based on snapshotting the process after initialization, so a fair comparison would do that on native as well. Full process snapshotting…