12 ms·

Wasmtime 1.0

497 points by ridruejo 4y ago

periram 4y ago
Congrats to the wasmtime team and loved the documentation!
ctoth 4y ago
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. thread 'main' panicked at 'not implemented: VirtualFile::poll is not implemented for non-Unix-like targets yet' Guess I still just have to wait, but seems weird to call it 1.0.
- syrusakbary 4y ago
  We are working on the poll for Windows in Wasmer... stay tuned!
- IshKebab 4y ago
  Because it uses WASI which is basically "POSIX for Webassembly". Check out the API: https://github.com/WebAssembly/wasi-libc/blob/main/libc-bottom-half/headers/public/wasi/api.h 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...
  - denisw 4y ago
    What you linked to is WASI-libc, which is a C standard library implementation on top of WASI - which itself is more low-level and less POSIX-like. https://github.com/WebAssembly/WASI https://github.com/WebAssembly/WASI
    - IshKebab 4y ago
      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/snapshot/docs.md https://github.com/WebAssembly/WASI/blob/main/phases/snapsho... You'll find it matches the file I linked. Search for "POSIX" or "errno".
      - jeffparsons 4y ago
        Fortunately the idea of WASI is for it to be modular. It makes sense for them to have the APIs required to make porting existing POSIX-ish-compatible apps easy, but there are also WASI modules (I forget the proper name) in the works for much more general IO objects etc. that better abstract away the underlying OS if you're willing to invest in that. So I guess you could summarise it as: backward compatible-ish first, and then figuring out what a neater, more idiomatic world would look like second. It's a pragmatic approach to bootstrapping the ecosystem, and there's no need for the POSIX-alike parts to hold anyone back, at least long term. Pretty soon you will be able to write apps that target WASI that end up reading and writing files in practice without the app even knowing what a "file" is (the runtime can just hand it an abstract IO object). That's a step beyond just not knowing about things like symlinks, and seems to me like a more "web-flavoured" future that can work even for CLI/desktop apps.
  - kortex 4y ago
    > 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... What's the alternative? If you want an I/O system interface into WASM, something POSIX-like is probably the sanest choice one could make. Portable is literally in the name. In fact I'd say POSIX the least obviously biased system interface. Is there some other syscall interface out there which implementS files, sockets, and clocks, which is simpler than POSIX? In fact WASI seems quite stripped down from POSIX.
syrusakbary 4y ago
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 https://github.com/titzer/wizard-engine [2] https://github.com/tetratelabs/wazero https://github.com/tetratelabs/wazero [3] https://github.com/lunatic-solutions/lunatic https://github.com/lunatic-solutions/lunatic
- jedisct1 4y ago
  New libsodium benchmarks are going to be published soon. Prepare your engines!
  - syrusakbary 4y ago
    Please make sure you benchmark with the latest beta of Wasmer! (3.0.0-beta2) https://github.com/wasmerio/wasmer/releases https://github.com/wasmerio/wasmer/releases
lhnz 4y ago
Maybe a stupid question, but: what is Wasmtime for? What kind of use-cases/applications does it enable and why is this good?
- dljsjr 4y ago
  The Bytecode Alliance is a nonprofit group with members from all over the industry working to provide what is ostensibly a reference implementation of a WebAssembly runtime w/ full WASI support. Wasmtime is their implementation. They are far from the only implementation, though. You can find links to other runtimes in other comments here already.
- oxff 4y ago
  https://blog.cloudflare.com/announcing-wasi-on-workers/ https://blog.cloudflare.com/announcing-wasi-on-workers/ will probably open it up a bit for you with a concrete example
  - baq 4y ago
    Thanks for that. > Back to the future > For those of you who have been around for the better part of the past couple of decades, you may notice this looks very similar to RFC3875, better known as CGI (The Common Gateway Interface). While our example here certainly does not conform to the specification, you can imagine how this can be extended to turn the stdin of a basic 'command line' application into a full-blown http handler. they should've started with that ;)
  - btown 4y ago
    I would add that it can be useful to have isolated runtimes even if you're not a PaaS. Say you need to parse an obscure file format that can be uploaded from untrusted users (and nowadays, that's all users). You've got some ancient C or C++ source code for the parser, but it hasn't been vetted for security or denial-of-service issues. Compile it to WASM, run it in an isolated runtime, and you can be confident that it won't be able to escape its sandbox while also minimizing startup times and using significantly fewer resources than needing a container for each invocation.
gkorland 4y ago
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.
- gkorland 4y ago
  I see on the blog some performance numbers compared to Spidermonkey.wasm anyone compared it to V8?
  - cfallin 4y ago
    The perf blogpost actually uses SpiderMonkey-compiled-to-Wasm as a benchmark rather than a comparison (peer) of Wasmtime. However, there are some good comparisons done by a third party in this paper: https://arxiv.org/pdf/2011.13127.pdf https://arxiv.org/pdf/2011.13127.pdf See Figs. 20-22 on page 19. They found Wasmtime to be quite competitive to V8 and others. (disclosure: I work on Wasmtime + Cranelift)
asim 4y ago
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.
- justsomeuser 4y ago
  Being isolated is good and bad for WASM. You get lots of benefits, but then you cannot use any C system calls which most code relies on (networking, disk, GUI) etc. It looks like runtimes are going to create message passing interfaces to access these C system calls. Wouldn't it be easier just to create better sandboxes for the old code rather than create a WASM runtime with new message passing interfaces to all the old C system functions?
- Deukhoofd 4y ago
  Doesn't WASI have what you need for networking?
- syrusakbary 4y ago
  Nice to see you here Asim! Stay tuned for some updates from Wasmer regarding networking, I'm super excited on what's coming next for full networking apps running on Wasm... can't wait to share it!
dang 4y ago
Recent and related: Security and Correctness in Wasmtime - https://news.ycombinator.com/item?id=32825377 https://news.ycombinator.com/item?id=32825377 - Sept 2022 (16 comments) Wasmtime 1.0: A Look at Performance - https://news.ycombinator.com/item?id=32739941 https://news.ycombinator.com/item?id=32739941 - Sept 2022 (22 comments)
eins1234 4y ago
Instantiating a runtime in microseconds is deeply exciting! Though after skimming through the docs, I'm still left wondering a few things: - 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?) - 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. - 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?
- ctvo 4y ago
  > - 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 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 https://github.com/deislabs/wagi - https://suborbital.dev/ https://suborbital.dev/ - https://github.com/fermyon/spin https://github.com/fermyon/spin They handle the passing of data between host and guest for you. Your module, written in a language that compiles down to wasm, is evaluated against the request. They make host functionality, such as the ability to make other network calls, available to your module as needed. > - 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? See suborbital linked above. Not much. This is the primary current use case for server side wasm.
continuational 4y ago
Really exciting, however, I'd like to see some benchmarks backing up those "Wasmtime is fast" claims.
ainar-g 4y ago
Go issue for adding WASI: https://github.com/golang/go/issues/31105 https://github.com/golang/go/issues/31105
1980phipsi 4y ago
I like the little drawings that Lin Clark includes.
brundolf 4y ago
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: https://github.com/bytecodealliance/wasmtime#example https://github.com/bytecodealliance/wasmtime#example Maybe I'll take it for a spin
ur-whale 4y ago
Dumb question time: 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. I therefore assume that this product does not run in a browser, but rather standalone, and therefore probably on the server ... That brings up the following, likely dumb question: what is the use case?
- schemescape 4y ago
  I’m not an expert, but you could drop the same WASM binary on servers of any architecture, provided the runtime is installed. I also assume (hope) this runtime is much lighter weight than e.g. Node or Ruby or Python or whatever is popular. It also seems nice because of the sandbox aspect, similar to how I’d rather run a random tool in my browser than give it unfettered access to my local resources by default.
- bbatchelder 4y ago
  Universal bytecode that is architecture agnostic. Take some rust code, compile it into wasm, and call it from dotnet. Compile your app into wasm and run it anywhere on any architecture. At least that is the end goal as I understand it. The idea of it also being really fast and safe is an extra bonus.
  - pjmlp 4y ago
    The idea is as old as UNCOL (1958). https://en.m.wikipedia.org/wiki/UNCOL https://en.m.wikipedia.org/wiki/UNCOL
- callahad 4y ago
  Same as with Node. Take some browser tech, remove the browser, find out it's useful on its own. Browsers are really good incubators for fast, secure runtimes. Every time you open a new tab, that engine has to run untrusted, third-party code provided by the website. And it has to do start up so quickly that you don't perceive it. Turns out those properties are useful on the server, too.
eis 4y ago
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.
tensors 4y ago
Why would you choose to use this runtime, rather than, say, writing your program in Rust to get both its safety guarantees and native performance?
- colordrops 4y ago
  Performance is going to be fast enough in most cases, you get the extra sandboxing, and it runs multiplatform. I'm not speaking from experience but just my understanding, so I may be incorrect.
- anderspitman 4y ago
  A standard Rust program has full access to any filesystem, network, etc resources that the user running the program has. WASM sandboxes these resources by default, only giving the program access to exactly what you explicitly allow at runtime.
- vanous 4y ago
  This allows you to run my library without having to trust me or my code.
  - encryptluks2 4y ago
    Isn't that what Docker, firejail, nsjail, flatpak and others already achieve...?
    - awestroke 4y ago
      No
      - encryptluks2 4y ago
        Yes
deleted 4y ago
[deleted]
xmly 4y ago
Exciting! Can not wait to try it!
xmly 4y ago
Exciting! Can not wait to try it!
bullen 4y ago
Seems the micro runtime also released 1.0: https://github.com/bytecodealliance/wasm-micro-runtime https://github.com/bytecodealliance/wasm-micro-runtime But why does it not have binaries compiled and ready? nm: https://github.com/bytecodealliance/wasm-micro-runtime/issues/1482 https://github.com/bytecodealliance/wasm-micro-runtime/issue...
- asim 4y ago
  I'm more bullish on this runtime than all the others. I personally think this one could promote itself as being embeddable and spread far and wide.
  - bullen 4y ago
    Yes, I had almost given up on modern solutions but this might just lead to something! wasmtime.dll is 8MB... if the micro runtime .dll is around 1MB I'm giving it a try! Edit: Looking at source sizes it could be 500KB! But we'll see!
my2iu 4y ago
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.
sn9 4y ago
Deeply envious of everyone who gets to work on this. What a dream project.
deleted 4y ago
[deleted]
RantyDave 4y ago
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. 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?
- why_only_15 4y ago
  Java and C# to my understanding are intended to be run in an untrusted way and can cause segfaults or take over the surrounding process (with JNI or C# unsafe). With something like wasmtime I can have untrusted user code in the same process that I have. This means I can do things like have really low-latency interconnect or start running a user's code in microseconds.
  - saagarjha 4y ago
    You can just deny the process access to JNI; it's not too difficult assuming you've patched the JDK appropriately.
    - awestroke 4y ago
      Running untrusted java code sounds like a nightmare. And saying you can do something in java if you've "patched the JDK appropriately"... How is that even comparable to a 100% sandboxed by default vm and runtime?
      - saagarjha 4y ago
        You patch the JDK because it doesn’t make sense to try to access the filesystem if there is no filesystem, lol. The JVM is sandboxed, it’s the APIs you give it that let it break out.
- 4y ago
survirtual 4y ago
Nice job on the release… But still no multithreading? https://github.com/bytecodealliance/wasmtime/issues/888 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.
- znwu 4y ago
  They seem to adopt a rapid iteration model closer to browser rather than typical language runtimes. So a browser 1.0 is nothing close to finished. I personally have no problem on it. But I think it is indeed strange that they sound so serious about correctness while constantly rolling new major versions.
  - survirtual 4y ago
    Nothing closed to finished is no joke. Been trying to share memory between a main-thread wasm controlling UI and worker-thread wasm doing heavy compute. One problem after another only to find mutexes are janky / non-operable due to main thread wasm not being allowed to block? So need to come up with some hacks so my code can do basic things like locks with shared memory. Not sure what these folks are thinking but I’m looking forward to a day when one codebase truly works everywhere.

497 points by ridruejo 4y ago

Congrats to the wasmtime team and loved the documentation!

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. thread 'main' panicked at 'not implemented: VirtualFile::poll is not implemented for non-Unix-like targets yet' Guess I still just have to wait, but seems weird to call it 1.0.

syrusakbary 4y ago
We are working on the poll for Windows in Wasmer... stay tuned!
IshKebab 4y ago
Because it uses WASI which is basically "POSIX for Webassembly". Check out the API: https://github.com/WebAssembly/wasi-libc/blob/main/libc-bottom-half/headers/public/wasi/api.h 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...
- denisw 4y ago
  What you linked to is WASI-libc, which is a C standard library implementation on top of WASI - which itself is more low-level and less POSIX-like. https://github.com/WebAssembly/WASI https://github.com/WebAssembly/WASI
  - IshKebab 4y ago
    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/snapshot/docs.md https://github.com/WebAssembly/WASI/blob/main/phases/snapsho... You'll find it matches the file I linked. Search for "POSIX" or "errno".
    - jeffparsons 4y ago
      Fortunately the idea of WASI is for it to be modular. It makes sense for them to have the APIs required to make porting existing POSIX-ish-compatible apps easy, but there are also WASI modules (I forget the proper name) in the works for much more general IO objects etc. that better abstract away the underlying OS if you're willing to invest in that. So I guess you could summarise it as: backward compatible-ish first, and then figuring out what a neater, more idiomatic world would look like second. It's a pragmatic approach to bootstrapping the ecosystem, and there's no need for the POSIX-alike parts to hold anyone back, at least long term. Pretty soon you will be able to write apps that target WASI that end up reading and writing files in practice without the app even knowing what a "file" is (the runtime can just hand it an abstract IO object). That's a step beyond just not knowing about things like symlinks, and seems to me like a more "web-flavoured" future that can work even for CLI/desktop apps.
- kortex 4y ago
  > 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... What's the alternative? If you want an I/O system interface into WASM, something POSIX-like is probably the sanest choice one could make. Portable is literally in the name. In fact I'd say POSIX the least obviously biased system interface. Is there some other syscall interface out there which implementS files, sockets, and clocks, which is simpler than POSIX? In fact WASI seems quite stripped down from POSIX.

syrusakbary 4y ago

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 https://github.com/titzer/wizard-engine [2] https://github.com/tetratelabs/wazero https://github.com/tetratelabs/wazero [3] https://github.com/lunatic-solutions/lunatic https://github.com/lunatic-solutions/lunatic

jedisct1 4y ago
New libsodium benchmarks are going to be published soon. Prepare your engines!
- syrusakbary 4y ago
  Please make sure you benchmark with the latest beta of Wasmer! (3.0.0-beta2) https://github.com/wasmerio/wasmer/releases https://github.com/wasmerio/wasmer/releases

lhnz 4y ago

Maybe a stupid question, but: what is Wasmtime for? What kind of use-cases/applications does it enable and why is this good?

dljsjr 4y ago
The Bytecode Alliance is a nonprofit group with members from all over the industry working to provide what is ostensibly a reference implementation of a WebAssembly runtime w/ full WASI support. Wasmtime is their implementation. They are far from the only implementation, though. You can find links to other runtimes in other comments here already.
oxff 4y ago
https://blog.cloudflare.com/announcing-wasi-on-workers/ https://blog.cloudflare.com/announcing-wasi-on-workers/ will probably open it up a bit for you with a concrete example
- baq 4y ago
  Thanks for that. > Back to the future > For those of you who have been around for the better part of the past couple of decades, you may notice this looks very similar to RFC3875, better known as CGI (The Common Gateway Interface). While our example here certainly does not conform to the specification, you can imagine how this can be extended to turn the stdin of a basic 'command line' application into a full-blown http handler. they should've started with that ;)
- btown 4y ago
  I would add that it can be useful to have isolated runtimes even if you're not a PaaS. Say you need to parse an obscure file format that can be uploaded from untrusted users (and nowadays, that's all users). You've got some ancient C or C++ source code for the parser, but it hasn't been vetted for security or denial-of-service issues. Compile it to WASM, run it in an isolated runtime, and you can be confident that it won't be able to escape its sandbox while also minimizing startup times and using significantly fewer resources than needing a container for each invocation.

gkorland 4y ago

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.

gkorland 4y ago
I see on the blog some performance numbers compared to Spidermonkey.wasm anyone compared it to V8?
- cfallin 4y ago
  The perf blogpost actually uses SpiderMonkey-compiled-to-Wasm as a benchmark rather than a comparison (peer) of Wasmtime. However, there are some good comparisons done by a third party in this paper: https://arxiv.org/pdf/2011.13127.pdf https://arxiv.org/pdf/2011.13127.pdf See Figs. 20-22 on page 19. They found Wasmtime to be quite competitive to V8 and others. (disclosure: I work on Wasmtime + Cranelift)

asim 4y ago

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.

justsomeuser 4y ago
Being isolated is good and bad for WASM. You get lots of benefits, but then you cannot use any C system calls which most code relies on (networking, disk, GUI) etc. It looks like runtimes are going to create message passing interfaces to access these C system calls. Wouldn't it be easier just to create better sandboxes for the old code rather than create a WASM runtime with new message passing interfaces to all the old C system functions?
Deukhoofd 4y ago
Doesn't WASI have what you need for networking?
syrusakbary 4y ago
Nice to see you here Asim! Stay tuned for some updates from Wasmer regarding networking, I'm super excited on what's coming next for full networking apps running on Wasm... can't wait to share it!

dang 4y ago

Recent and related: Security and Correctness in Wasmtime - https://news.ycombinator.com/item?id=32825377 https://news.ycombinator.com/item?id=32825377 - Sept 2022 (16 comments) Wasmtime 1.0: A Look at Performance - https://news.ycombinator.com/item?id=32739941 https://news.ycombinator.com/item?id=32739941 - Sept 2022 (22 comments)

eins1234 4y ago

Instantiating a runtime in microseconds is deeply exciting! Though after skimming through the docs, I'm still left wondering a few things: - 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?) - 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. - 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?

ctvo 4y ago
> - 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 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 https://github.com/deislabs/wagi - https://suborbital.dev/ https://suborbital.dev/ - https://github.com/fermyon/spin https://github.com/fermyon/spin They handle the passing of data between host and guest for you. Your module, written in a language that compiles down to wasm, is evaluated against the request. They make host functionality, such as the ability to make other network calls, available to your module as needed. > - 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? See suborbital linked above. Not much. This is the primary current use case for server side wasm.

continuational 4y ago

Really exciting, however, I'd like to see some benchmarks backing up those "Wasmtime is fast" claims.

ainar-g 4y ago

Go issue for adding WASI: https://github.com/golang/go/issues/31105 https://github.com/golang/go/issues/31105

1980phipsi 4y ago

I like the little drawings that Lin Clark includes.

brundolf 4y ago

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: https://github.com/bytecodealliance/wasmtime#example https://github.com/bytecodealliance/wasmtime#example Maybe I'll take it for a spin

ur-whale 4y ago

Dumb question time: 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. I therefore assume that this product does not run in a browser, but rather standalone, and therefore probably on the server ... That brings up the following, likely dumb question: what is the use case?

schemescape 4y ago
I’m not an expert, but you could drop the same WASM binary on servers of any architecture, provided the runtime is installed. I also assume (hope) this runtime is much lighter weight than e.g. Node or Ruby or Python or whatever is popular. It also seems nice because of the sandbox aspect, similar to how I’d rather run a random tool in my browser than give it unfettered access to my local resources by default.
bbatchelder 4y ago
Universal bytecode that is architecture agnostic. Take some rust code, compile it into wasm, and call it from dotnet. Compile your app into wasm and run it anywhere on any architecture. At least that is the end goal as I understand it. The idea of it also being really fast and safe is an extra bonus.
- pjmlp 4y ago
  The idea is as old as UNCOL (1958). https://en.m.wikipedia.org/wiki/UNCOL https://en.m.wikipedia.org/wiki/UNCOL
callahad 4y ago
Same as with Node. Take some browser tech, remove the browser, find out it's useful on its own. Browsers are really good incubators for fast, secure runtimes. Every time you open a new tab, that engine has to run untrusted, third-party code provided by the website. And it has to do start up so quickly that you don't perceive it. Turns out those properties are useful on the server, too.

eis 4y ago

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.

tensors 4y ago

Why would you choose to use this runtime, rather than, say, writing your program in Rust to get both its safety guarantees and native performance?

colordrops 4y ago
Performance is going to be fast enough in most cases, you get the extra sandboxing, and it runs multiplatform. I'm not speaking from experience but just my understanding, so I may be incorrect.
anderspitman 4y ago
A standard Rust program has full access to any filesystem, network, etc resources that the user running the program has. WASM sandboxes these resources by default, only giving the program access to exactly what you explicitly allow at runtime.
vanous 4y ago
This allows you to run my library without having to trust me or my code.
- encryptluks2 4y ago
  Isn't that what Docker, firejail, nsjail, flatpak and others already achieve...?
  - awestroke 4y ago
    No
    - encryptluks2 4y ago
      Yes

deleted 4y ago

[deleted]

xmly 4y ago

Exciting! Can not wait to try it!

xmly 4y ago

Exciting! Can not wait to try it!

bullen 4y ago

Seems the micro runtime also released 1.0: https://github.com/bytecodealliance/wasm-micro-runtime https://github.com/bytecodealliance/wasm-micro-runtime But why does it not have binaries compiled and ready? nm: https://github.com/bytecodealliance/wasm-micro-runtime/issues/1482 https://github.com/bytecodealliance/wasm-micro-runtime/issue...

asim 4y ago
I'm more bullish on this runtime than all the others. I personally think this one could promote itself as being embeddable and spread far and wide.
- bullen 4y ago
  Yes, I had almost given up on modern solutions but this might just lead to something! wasmtime.dll is 8MB... if the micro runtime .dll is around 1MB I'm giving it a try! Edit: Looking at source sizes it could be 500KB! But we'll see!

my2iu 4y ago

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.

sn9 4y ago

Deeply envious of everyone who gets to work on this. What a dream project.

deleted 4y ago

[deleted]

RantyDave 4y ago

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. 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?

why_only_15 4y ago
Java and C# to my understanding are intended to be run in an untrusted way and can cause segfaults or take over the surrounding process (with JNI or C# unsafe). With something like wasmtime I can have untrusted user code in the same process that I have. This means I can do things like have really low-latency interconnect or start running a user's code in microseconds.
- saagarjha 4y ago
  You can just deny the process access to JNI; it's not too difficult assuming you've patched the JDK appropriately.
  - awestroke 4y ago
    Running untrusted java code sounds like a nightmare. And saying you can do something in java if you've "patched the JDK appropriately"... How is that even comparable to a 100% sandboxed by default vm and runtime?
    - saagarjha 4y ago
      You patch the JDK because it doesn’t make sense to try to access the filesystem if there is no filesystem, lol. The JVM is sandboxed, it’s the APIs you give it that let it break out.
4y ago

survirtual 4y ago

Nice job on the release… But still no multithreading? https://github.com/bytecodealliance/wasmtime/issues/888 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.

znwu 4y ago
They seem to adopt a rapid iteration model closer to browser rather than typical language runtimes. So a browser 1.0 is nothing close to finished. I personally have no problem on it. But I think it is indeed strange that they sound so serious about correctness while constantly rolling new major versions.
- survirtual 4y ago
  Nothing closed to finished is no joke. Been trying to share memory between a main-thread wasm controlling UI and worker-thread wasm doing heavy compute. One problem after another only to find mutexes are janky / non-operable due to main thread wasm not being allowed to block? So need to come up with some hacks so my code can do basic things like locks with shared memory. Not sure what these folks are thinking but I’m looking forward to a day when one codebase truly works everywhere.