Our great sponsors
-
-
-
InfluxDB
Power Real-Time Data Analytics at Scale. Get real-time insights from all types of time series data with InfluxDB. Ingest, query, and analyze billions of data points in real-time with unbounded cardinality.
-
-
-
-
-
WorkOS
The modern identity platform for B2B SaaS. The APIs are flexible and easy-to-use, supporting authentication, user identity, and complex enterprise features like SSO and SCIM provisioning.
-
-
-
-
-
Nope, the file I linked to is the WASI API, just expressed as a C header (which I find a bit easier to skim than the actual specification).
Here's the actual WASI spec:
https://github.com/WebAssembly/WASI/blob/main/phases/snapsho...
You'll find it matches the file I linked. Search for "POSIX" or "errno".
https://github.com/bytecodealliance/wasmtime/issues/888
It is strange to me to call it 1.0 without seamless threading support and while wasm & wasi still have standards to work out.
Multithreading is a basic operation in everything I build right now. It allows me to make a highly responsive UI while doing massive computations without any user experience impact. It lets me make services which can handle thousands of requests a second. And with Rust, this all comes ergonomically. At this point, I can’t think of a single solution I would implement without doing some form of this.
While I could treat a wasm application as a client server model (have one module for interfacing / managing, have X for processing where X is the number of available cores) then share memory between them, this creates a lot of boilerplate and makes the code less ergonomic, and can drastically increase friction. I don’t want to have to hack threading into an application with so much manual setup, and I don’t like when a runtime forces architecturally decisions because it lacks a basic capability.
Anyway, congrats on the release. I will look forward to 2.0 of these runtimes.
Congrats to the Wasmtime team on the 1.0 release!
I'm happy to see that more runtimes are maturing and getting use on production cases... I can't wait to see and show what the future entails for WebAssembly on both the server side and the browser!
Keep up the good work. Also I'd like to use this message to congratulate other runtimes that I'm excited about (apart from Wasmer, of course!): Wizard Engine [1], Wazero [2] and Lunatic [3].
The future is bright in Wasm land :)
[1] https://github.com/titzer/wizard-engine
[2] https://github.com/tetratelabs/wazero
[3] https://github.com/lunatic-solutions/lunatic
Congrats to the Wasmtime team on the 1.0 release!
I'm happy to see that more runtimes are maturing and getting use on production cases... I can't wait to see and show what the future entails for WebAssembly on both the server side and the browser!
Keep up the good work. Also I'd like to use this message to congratulate other runtimes that I'm excited about (apart from Wasmer, of course!): Wizard Engine [1], Wazero [2] and Lunatic [3].
The future is bright in Wasm land :)
[1] https://github.com/titzer/wizard-engine
[2] https://github.com/tetratelabs/wazero
[3] https://github.com/lunatic-solutions/lunatic
Congrats to the Wasmtime team on the 1.0 release!
I'm happy to see that more runtimes are maturing and getting use on production cases... I can't wait to see and show what the future entails for WebAssembly on both the server side and the browser!
Keep up the good work. Also I'd like to use this message to congratulate other runtimes that I'm excited about (apart from Wasmer, of course!): Wizard Engine [1], Wazero [2] and Lunatic [3].
The future is bright in Wasm land :)
[1] https://github.com/titzer/wizard-engine
[2] https://github.com/tetratelabs/wazero
[3] https://github.com/lunatic-solutions/lunatic
Because it uses WASI which is basically "POSIX for Webassembly". Check out the API:
https://github.com/WebAssembly/wasi-libc/blob/main/libc-bott...
Symlinks, hardlinks, errno, etc. It's not surprising that it's better supported on Unix than other platforms.
And yeah I agree it's disappointing they tacked such an obviously platform-biased API on to something that is supposed to be platform independent. I guess it was the pragmatic thing but still...
> - JS is notably missing from the list of languages supported on the front page. But I see mentions of a Spidermonkey.wasm in the blog post. Is running JS on top of wasmtime in production a realistic prospect today? If so, where can I read more? (mainly interested in this for the instantiation time benefits, though maybe all/most of that will be negated by the embedded JS engine?)
Shopify and others use QuickJS as their JS engine of choice. See https://github.com/Shopify/javy as a starting point. The real benefit is allowing authors of plugins to write JS and not AssemblyScript, not any performance or instantiation time benefits.
> - How should I go about building a typical web service on top of wasmtime? Can wasmtime itself handle network requests/connections or would I need to build the web server in some other host language and pass request data to wasmtime modules? Haven't been able to find anything in the docs about this.
There are a lot of choices for this. None I would consider mature, but some leads:
- https://github.com/deislabs/wagi
These are good questions! Here's some answers from the corner of the world I know best as a Wasmtime contributor at Fastly:
1. Spidermonkey.wasm is the basis of Fastly's JavaScript on Compute@Edge support. We have found it to be faster than QuickJS. The source code is here: https://github.com/fastly/js-compute-runtime.
2. Fastly Compute@Edge is built on wasmtime. You can develop web services for it in Rust, JS, and Go: https://developer.fastly.com/learning/compute/
3. Fastly's multi-tenant platform is closed source, but our single-tenant local development platform, which also uses wasmtime under the hood as well, is open source: https://github.com/fastly/viceroy. It isn't a big leap to make viceroy multi-tenant: Wasmtime provides everything you need, and all Viceroy would have to do is dispatch on e.g. HTTP host header to the correct tenant. Our multi-tenant platform is closed source because it is very specialized for use on Fastly's edge, not because the multi-tenant aspect is special.
These are good questions! Here's some answers from the corner of the world I know best as a Wasmtime contributor at Fastly:
1. Spidermonkey.wasm is the basis of Fastly's JavaScript on Compute@Edge support. We have found it to be faster than QuickJS. The source code is here: https://github.com/fastly/js-compute-runtime.
2. Fastly Compute@Edge is built on wasmtime. You can develop web services for it in Rust, JS, and Go: https://developer.fastly.com/learning/compute/
3. Fastly's multi-tenant platform is closed source, but our single-tenant local development platform, which also uses wasmtime under the hood as well, is open source: https://github.com/fastly/viceroy. It isn't a big leap to make viceroy multi-tenant: Wasmtime provides everything you need, and all Viceroy would have to do is dispatch on e.g. HTTP host header to the correct tenant. Our multi-tenant platform is closed source because it is very specialized for use on Fastly's edge, not because the multi-tenant aspect is special.
Seems the micro runtime also released 1.0:
https://github.com/bytecodealliance/wasm-micro-runtime
But why does it not have binaries compiled and ready?
We worked with Igalia to upstream the SpiderMonkey patches required to build for wasm32-wasi. We point to a fixed version (see: https://github.com/fastly/spidermonkey-wasi-embedding) which we haven't updated for a minute.
Please make sure you benchmark with the latest beta of Wasmer! (3.0.0-beta2)
https://github.com/wasmerio/wasmer/releases