Congrats to the Wasmtime team on the 1.0 release!<p>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!<p>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].<p>The future is bright in Wasm land :)<p>[1] <a href="https://github.com/titzer/wizard-engine" rel="nofollow">https://github.com/titzer/wizard-engine</a><p>[2] <a href="https://github.com/tetratelabs/wazero" rel="nofollow">https://github.com/tetratelabs/wazero</a><p>[3] <a href="https://github.com/lunatic-solutions/lunatic" rel="nofollow">https://github.com/lunatic-solutions/lunatic</a>
Instantiating a runtime in microseconds is deeply exciting!<p>Though after skimming through the docs, I'm still left wondering a few things:<p>- 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?)<p>- 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.<p>- What would it take to build a multitenant web service where customer code is isolated using wasmtime, like the one like described in the post?
I'm sold on the future of wasm. What really still bothers me is the effort and hoops I have to jump through to actually leverage it. Networking, just fix networking so I can drop in most things and it would be great. The fact that I have to rewrite the majority of my network access to do any external IO is painful but I get that containers took more than a decade after Google's use to get there too.
I assumed that like most low-level runtimes it wouldn't be easy to just go and play with for fun, but the example is impressively simple: <a href="https://github.com/bytecodealliance/wasmtime#example" rel="nofollow">https://github.com/bytecodealliance/wasmtime#example</a><p>Maybe I'll take it for a spin
Nice job on the release…<p>But still no multithreading?
<a href="https://github.com/bytecodealliance/wasmtime/issues/888" rel="nofollow">https://github.com/bytecodealliance/wasmtime/issues/888</a><p>It is strange to me to call it 1.0 without seamless threading support and while wasm & wasi still have standards to work out.<p>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.<p>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.<p>Anyway, congrats on the release. I will look forward to 2.0 of these runtimes.
Go issue for adding WASI: <a href="https://github.com/golang/go/issues/31105" rel="nofollow">https://github.com/golang/go/issues/31105</a>
Seems the micro runtime also released 1.0:<p><a href="https://github.com/bytecodealliance/wasm-micro-runtime" rel="nofollow">https://github.com/bytecodealliance/wasm-micro-runtime</a><p>But why does it not have binaries compiled and ready?<p>nm: <a href="https://github.com/bytecodealliance/wasm-micro-runtime/issues/1482" rel="nofollow">https://github.com/bytecodealliance/wasm-micro-runtime/issue...</a>
Congrats on the 1.0 release! Wasmtime has a world class team of developers and I truly believe that WASM will play an important part in many industries. I'm pretty excited for what's to come. We've barely scratched the surface yet.
Dumb question time:<p>I am assuming that browsers come with a pre-installed wasm engine, and that this can't easily be replaced with a 3rd party one.<p>I therefore assume that this product does not run in a browser, but rather standalone, and therefore probably on the server ...<p>That brings up the following, likely dumb question: what is the use case?
Doesn't seem as though I can run the QJS REPL on Windows with this yet. I thought the entire point of these sorts of projects was serving as a cross-platform runtime, but Wasmtime doesn't actually accept key input for the REPL, and Wasmer errors out with an ugly error.<p>thread 'main' panicked at 'not implemented: VirtualFile::poll is not implemented for non-Unix-like targets yet'<p>Guess I still just have to wait, but seems weird to call it 1.0.
Congratulation! We're following this project for long time, considering embedding it in couple of projects.
The aim is to use it as a lightweight sandbox to replace docker.
But, it still feels like the performance impact is too high compared to docker.
I don't understand how we got here. A cross platform byte code that runs in some kind of emulated machine was done ages ago and called Java. Or C#. And they seem not-exactly-immune to security problems. Then we did containers and they were better. Then we did containers running in a lightweight VM and they were better too.<p>Surely a compiled language on a unikernel (as in no kernel) in a lightweight VM is the ultimate good result for secure + fast + scales? Wouldn't this buy you all sorts of hardware acceleration goodies like direct access to network hardware a la DPDK and no switching between user and kernel modes?
I don't understand why they propose all sorts of enterprise use-cases for wasmtime, yet they don't provide any official Java bindings for wasmtime.