Skip to content

Commit 82eed94

Browse files
ricochetsunfishcode
ricochet
and
sunfishcode
authored
wasi-preview2 article (#83)
* docs(articles): WASI-Preview2 Cross-posting with Dan's permission from personal blog detailing the WASI P2 milestone. * Say "WASI 0.2" instead of "WASI Preview 2". (#85) * Say "WASI 0.2" instead of "WASI Preview 2". * Tidy up the beginning. --------- Co-authored-by: Dan Gohman <dev@sunfishcode.online>
1 parent b3e6b82 commit 82eed94

1 file changed

Lines changed: 207 additions & 0 deletions

File tree

‎_posts/2024-01-25-WASI-0.2.md‎

Lines changed: 207 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,207 @@
1+
---
2+
title: WASI 0.2 Launched
3+
author: "Dan Gohman"
4+
github_name: sunfishcode
5+
---
6+
7+
The WASI Subgroup voted on January 25, 2024 to launch WASI 0.2, also known
8+
as WASI Preview 2, or WASIp2! This blog post is a brief look at the present,
9+
past, and future of WASI, and a repost of an original article shared
10+
[here]( https://blog.sunfishcode.online/wasi-0-2/).
11+
12+
## The present
13+
14+
The Subgroup voted to launch WASI 0.2!
15+
16+
This is a major milestone! We made it! At the same time, the journey is
17+
only just beginning. But let's talk this moment to step back and look at
18+
what this means.
19+
20+
Most immediately, what this means is that the WASI Subgroup officially
21+
says that the WASI 0.2 APIs are stable. There is still a lot more
22+
to do, in writing more documentation, more tests, more toolchains, more
23+
implementations, and there are a lot more features that we all want to add.
24+
This vote today is a milestone along the way, rather than a destination in
25+
itself.
26+
27+
It also means that WASI is now officially based on the Wasm [component model],
28+
which makes it cross-language and virtualizable. Figuring out what a
29+
component model even is, designing it, implementing it, and building APIs
30+
using it has been a huge effort with involving many people, and it's now
31+
officially in WASI. Yay!
32+
33+
WASI 0.2 includes two *worlds*:
34+
35+
- *wasi-cli*, the "command-line interface" world, which roughly
36+
corresponds to POSIX. Files, sockets, clocks, random numbers, etc.
37+
38+
- *wasi-http*, an HTTP proxy world, organized around requests
39+
and responses.
40+
41+
There are more worlds in development, but for now, the important thing is
42+
that we do have multiple worlds included. This means wasi-cli world isn't
43+
the only world, or even the primary world. It's just one world, among
44+
multiple.
45+
46+
One things I'm looking forward to that's enabled by having multiple worlds is
47+
[Typed Main] (some details in that presentation are out of date by now, but
48+
the big ideas still make sense), because we can have new worlds with new
49+
entrypoints, with new signatures. It's also a part of how we can grow WASI to
50+
fit into new non-traditional computing environments. And this is just the
51+
beginning.
52+
53+
## Looking back
54+
55+
All the way back since the beginning of WebAssembly, people have been talking
56+
about using it outside of browsers. Node.js had famously made JavaScript popular
57+
on servers and more, and if it made sense for JavaScript, it was pretty natural to
58+
imagine WebAssembly doing similar things. But beyond the basic outline, there
59+
were a lot of questions, and a lot of ideas.
60+
61+
- How can we build a coherent ecosystem without fragmentation? And how do
62+
we prevent an NPM-like situation with one company gaining control over the
63+
ecosystem?
64+
65+
- To some people, POSIX was the obvious place to start on a non-JS-based API.
66+
POSIX is a C API, so how do we ensure that our C *ABI* is future-proof?
67+
C ABIs tend to get baked in if one is not super careful, and bugs can
68+
[take decades to fix].
69+
70+
- As much as POSIX was the obvious starting point for a lot of people, it was
71+
just as much an obvious non-starter for a lot of other people. WASI being based
72+
on POSIX made it *very* biased toward C, with raw pointers everywhere, implied
73+
data structures, and so on. And would there need to be a `fork` function, with
74+
all its ecosystem-wide implications? Building an ecosystem with C ABIs as its
75+
primary connective tissue is very undesirable from a security perspective. Also,
76+
what's the plan when Wasm GC arrives?
77+
78+
- Should we always export linear memory, to ensure that we can pass pointers
79+
around? But if we do that, we lose the benefit of the sandboxing that Wasm is
80+
otherwise doing between modules&mdash;if you can corrupt a C program's memory,
81+
its game is over. But if we don't export linear memory, how else do we pass
82+
around complex data structures?
83+
84+
Looking at use cases, there are the "port existing code" use cases, and the "do things
85+
that other systems can already do, but do them *IN WASM*" use cases, and these are
86+
important. But there are also new use cases that we can imagine Wasm can do, and we
87+
wanted to be sure we didn't define the system in terms of compatibility and exclude
88+
these new use cases. One of the big themes that came up repeatedly was *virtualization*.
89+
All I/O in Wasm goes through its imports and exports, so we can completely virtualize a
90+
Wasm module's view of the outside just by controlling what the imports and exports are
91+
linked to.
92+
93+
And, Wasm has a trusted stack, which is what makes it possible to call from
94+
Wasm into JS and back within JS engines. In theory we should be able to use this
95+
property to enable calling from Wasm into some other mutually untrusted Wasm.
96+
97+
Also, early on, some security-minded folks told us that we should look at something
98+
called "capabilities", which they said were really great. And avoiding global state
99+
sounded like a good direction to go in. CloudABI combined capability-based security and
100+
some impressive work to simplify the Unix platform down to a relatively small set of
101+
carefully-designed primitives, which made it especially appealing. Consequently, much
102+
of WASI 0.1 was closely derived from CloudABI.
103+
104+
That helped get us started, and helps us build systems that people could write
105+
code with and get things working, but we still had all these open questions, and
106+
big ideas to figure out.
107+
108+
### Component Model enters the chat
109+
110+
So while WASI 0.1 was out in the world, people were starting to think big
111+
thoughts about how to answer all these big questions and how to fit all the
112+
big ideas into a coherent design. There were these early proposals called
113+
"interface types" and "module linking", which seemed to be pointing toward
114+
something, but had been through numerous iterations and hadn't quite settled
115+
in yet.
116+
117+
When I first heard about the idea for a component model, which would
118+
subsume interface types and module linking, I didn't know what a "component"
119+
meant. My knowledge of COM was "that's some Windows thing, right?". And I knew
120+
only slightly more about CORBA. Mostly, I knew just barely enough to react
121+
"surely we don't want to do *that*". But as I got into it, I learned that
122+
the Wasm component model was a chance to both learn from those existing systems
123+
which had solved many of the problems we needed to solve, and also to learn
124+
from those systems and do some things differently.
125+
126+
We didn't want to force everyone to think about distributed computing just
127+
to link libraries together. And we didn't want to lose the advantage of Wasm
128+
sandboxing each module independently. And when we looked at where that leaves
129+
us, the common theme that remained was *composition*. It's about building
130+
things that can be easily put together to make larger things.
131+
132+
And then from there, composition ties together an entire family of ideas.
133+
Even [Mark Miller's PhD thesis] about capability-based security is literally
134+
titled "Robust Composition". It's right there. It's what this is all about.
135+
How do we put together parts to make a whole, without all kinds of complexities
136+
creeping in?
137+
138+
- Cross-language interop is needed to compose components written in
139+
different languages.
140+
141+
- Component isolation supports composition without the fear of components
142+
having unexpected conflicts.
143+
144+
- No global namespace at runtime, so that composed component don't
145+
collide in or have differing requirements of the namespace.
146+
147+
- Any interface can be virtualized, which is to say, composed with
148+
any implementation of that interface.
149+
150+
- The output of linking two components is a component, so composition
151+
can happen incrementally.
152+
153+
- Capabilities are a way to compose two components together, in which
154+
they share some parts of themselves with each other and not others.
155+
156+
There's a lot more to these topics, but this is hopefully enough to paint
157+
the picture that there are some themes that all fit well with each other,
158+
within the conceptual framework of composition.
159+
160+
And so, WASI 0.2 represents not just a new API, but a new approach to
161+
APIs that gets us out of worrying about C ABI fragility, or C pointer hazards,
162+
and that has reasonable paths forward for supporting many different
163+
programming languages without hard fragmentation. It even allows us to not
164+
worry so much about getting WASI 0.2 itself perfectly right for all time,
165+
because we know we can virtualize WASI 0.2 itself in terms of future APIs.
166+
167+
This is why the Subgroup voting to launch WASI 0.2 is such a big deal.
168+
169+
## Looking ahead
170+
171+
Ok, that's a high-level view of how we got here. What's next?
172+
173+
In terms of standards, there are two activities that people are already
174+
looking forward to. With WASI 0.2.0 finalized, it'll be time to start planning
175+
for things we want to add in a WASI 0.2.1 soon after it. That'll be another
176+
milestone: the first update to WASI 0.2, which will establish how to do updates,
177+
and set up the rhythm for doing incremental updates. WASI 0.2 is small still;
178+
we had to scope down a number of features that people really wanted, so we're
179+
looking forward to doing many updates in WASI 0.2.1 and beyond.
180+
181+
At the same time, work towards WASI 0.3, also known as WASI Preview 3, will be getting underway. The
182+
major banner of WASI 0.3 is *async*, and adding the `future` and `stream` types
183+
to Wit. And here again, the theme is *composability*. It's one thing to do
184+
async, it's another to do *composable* async, where two components that are
185+
async can be composed together without either event loop having to be nested
186+
inside the other. Designing an async system flexible enough for Rust, C#,
187+
JavaScript, Go, and many others, which all have their own perspectives on async,
188+
will take some time, so while the design work is starting now, WASI 0.3
189+
is expected to be at least a year away.
190+
191+
And when we do get there, the transition from WASI 0.2 to WASI 0.3 should be much smoother
192+
than WASI 0.1 to WASI 0.2. The component model's virtualizability means it
193+
should be easier to polyfill WASI 0.2 in terms of WASI 0.3. And, it should be
194+
easier for engines to support both WASI 0.2 and WASI 0.3 at the same time if
195+
they wish to, because WASI 0.2 will essentially use a subset of WASI 0.3's
196+
language features.
197+
198+
## Wrapping it up
199+
200+
WASI 0.2 is a major milestone that many people have contributed to, and
201+
it's now launched! It's an API, but it also represents a new way to define
202+
APIs for Wasm.
203+
204+
[take decades to fix]: https://en.wikipedia.org/wiki/Year_2038_problem
205+
[component model]: https://github.com/WebAssembly/component-model/
206+
[Mark Miller's PhD thesis]: http://www.erights.org/talks/thesis/markm-thesis.pdf
207+
[Typed Main]: https://sunfishcode.github.io/typed-main-wasi-presentation/chapter_1.html

0 commit comments

Comments
 (0)