[HN Gopher] Wasmtime 1.0
       ___________________________________________________________________
        
       Wasmtime 1.0
        
       Author : ridruejo
       Score  : 331 points
       Date   : 2022-09-20 15:57 UTC (7 hours ago)
        
 (HTM) web link (bytecodealliance.org)
 (TXT) w3m dump (bytecodealliance.org)
        
       | gkorland wrote:
       | 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 wrote:
         | I see on the blog some performance numbers compared to
         | Spidermonkey.wasm anyone compared it to V8?
        
           | cfallin wrote:
           | 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
           | 
           | See Figs. 20-22 on page 19. They found Wasmtime to be quite
           | competitive to V8 and others.
           | 
           | (disclosure: I work on Wasmtime + Cranelift)
        
       | bullen wrote:
       | 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?
       | 
       | nm: https://github.com/bytecodealliance/wasm-micro-
       | runtime/issue...
        
         | asim wrote:
         | 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 wrote:
           | 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!
        
       | asim wrote:
       | 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.
        
       | tensors wrote:
       | 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?
        
         | anderspitman wrote:
         | 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 wrote:
         | This allows you to run my library without having to trust me or
         | my code.
        
         | colordrops wrote:
         | 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.
        
       | syrusakbary wrote:
       | 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
        
       | lhnz wrote:
       | Maybe a stupid question, but: what is Wasmtime for? What kind of
       | use-cases/applications does it enable and why is this good?
        
         | dljsjr wrote:
         | 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 wrote:
         | https://blog.cloudflare.com/announcing-wasi-on-workers/ will
         | probably open it up a bit for you with a concrete example
        
           | btown wrote:
           | 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.
        
             | jon-wood wrote:
             | Personally I'd want to be very cautious about this. It's
             | probably more secure than just running this untrusted
             | binary directly on a server full of user uploaded content
             | but I don't know what level of confidence is should have in
             | wasmtime not having any container escapes possible.
        
               | schemescape wrote:
               | Yes. Consider that Spectre allowed reading browser memory
               | that wasn't exposed to JavaScript from within the JS
               | sandbox. Something similar probably would have been
               | possible with WASM, if Spectre hadn't already been found
               | and mitigated.
               | 
               | I love capability based limits like this (and in Deno),
               | but they're not a panacea.
        
             | cesarb wrote:
             | > 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
             | 
             | This is not just a theory: according to
             | https://hacks.mozilla.org/2021/12/webassembly-and-back-
             | again... Firefox does exactly that trick with five of its C
             | or C++ dependencies.
        
           | baq wrote:
           | 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 ;)
        
         | mikewarot wrote:
         | It's a way of running WASM code, which can be anything from
         | anywhere, safely. It only gets access to the folders you let it
         | access as a _capability_. It gets no access to anything else.
         | 
         | So, no matter how evil, or confused, the program is, you aren't
         | risking your entire system. It's the best part of capability
         | based security.
        
           | imhoguy wrote:
           | "Write once run anywere" heard that many times. No sandbox is
           | going to give you safety. Spectre and Meltdown are great
           | examples of that. It is the matter of time and popularity.
           | Cryptojacking and malware is already the problem[0].
           | 
           | [0] https://software-lab.org/publications/sp2022.pdf
        
           | pjmlp wrote:
           | Basically Java Security Manager for App Servers rebranded for
           | a new generation.
        
             | hinkley wrote:
             | Java Security Manager has a rich history of leaking
             | capabilities to code that should not have them. As has
             | practically every capability-based system ever.
             | 
             | Capabilities are no Silver Bullet. They work exceptionally
             | well with small teams, but like memory leaks, reachability
             | decisions tend not to scale to very large teams, and people
             | start exposing information for a feature without being able
             | to trace the consequences of having done so.
             | 
             | I could potentially see someone recasting this story as a
             | parable against shared state, but I'm not convinced it's
             | the sole cause or that you could have one without the
             | other. I think it is true that they share a problem space,
             | but that's neither a particularly brave nor illuminating
             | statement.
        
               | anderspitman wrote:
               | Do you have a favorite alternative to the capability
               | model that you feel is superior? I somewhat casually
               | follow these discussions and I'm always looking for new
               | ideas (or old ones that actually work better in some
               | cases).
        
               | hinkley wrote:
               | The weird thing about the security APIs in Java is that
               | it contained both capabilities and an ACL model with a
               | sort of hierarchy to it, both of inheritance and being
               | able to run a function in a scope. I got to use it for
               | real on a project and if you overlooked the extreme
               | clunkiness of trying to capture a set of rights as
               | configuration, it wasn't that bad.
               | 
               | So I could say, do that again but with a better way to
               | define rules programatically instead of a priori. Multi-
               | tenant, multiple roles, or a Cartesian product of the two
               | sort of demand a little bit of bespoke rules engine work.
        
           | VyseofArcadia wrote:
           | A bit like OpenBSD's pledge[0]. Seems a bit of a waste to
           | need a whole runtime for something the OS could provide.
           | 
           | [0] https://man.openbsd.org/pledge.2
        
             | VWWHFSfQ wrote:
             | Operating systems on are becoming increasingly irrelevant.
        
             | mtkhaos wrote:
             | Missing interoperability between web/server. It's moving
             | away from the OS model into something more pure
        
         | mnemonik wrote:
         | There is a section in the linked announcement titled "Why use a
         | WebAssembly Runtime?" that hopefully answers your question.
        
           | fweimer wrote:
           | It doesn't say why one should use _this_ WebAssembly
           | implementation, and not (for example) the V8-based
           | implementation that comes with Node.js.
        
             | paulgb wrote:
             | I wrote a (very surface level) comparison on this last
             | year[1]. If you already have V8 in your environment, it's
             | _probably_ worth using V8, but if you just want to load a
             | wasm interpreter into some Rust code, wasmtime is a much
             | nicer interface to work with and more lightweight.
             | 
             | [1] https://paulbutler.org/2021/calling-webassembly-from-
             | rust/
             | 
             | (nb. if I were to write this post today, it would be an
             | omission not to mention the component model)
        
         | wongarsu wrote:
         | Anything that wants to run arbitrary, possibly untrusted user-
         | provided code, with good speed and minimal startup time. The
         | big use cases are AWS Lambda-like things (whether that's
         | serving web requests or reacting to event queues), as well as
         | plugin systems for software.
        
         | eminence32 wrote:
         | The announcement post has a "Why use a WebAssembly Runtime?"
         | section that might answer your question.
        
       | eis wrote:
       | 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.
        
       | xmly wrote:
       | Exciting! Can not wait to try it!
        
       | ainar-g wrote:
       | Go issue for adding WASI:
       | https://github.com/golang/go/issues/31105
        
       | xmly wrote:
       | Exciting! Can not wait to try it!
        
       | continuational wrote:
       | Really exciting, however, I'd like to see some benchmarks backing
       | up those "Wasmtime is fast" claims.
        
       | 1980phipsi wrote:
       | I like the little drawings that Lin Clark includes.
        
       | dang wrote:
       | Recent and related:
       | 
       |  _Security and Correctness in Wasmtime_ -
       | 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 - Sept 2022 (22
       | comments)
        
       | my2iu wrote:
       | 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.
        
       | periram wrote:
       | Congrats to the wasmtime team and loved the documentation!
        
       | [deleted]
        
       | sn9 wrote:
       | Deeply envious of everyone who gets to work on this. What a dream
       | project.
        
       | ctoth wrote:
       | 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.
        
         | IshKebab wrote:
         | 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...
        
           | denisw wrote:
           | 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
        
             | IshKebab wrote:
             | 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/snapsh
             | o...
             | 
             | You'll find it matches the file I linked. Search for
             | "POSIX" or "errno".
        
         | syrusakbary wrote:
         | We are working on the poll for Windows in Wasmer... stay tuned!
        
       | brundolf wrote:
       | 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
       | 
       | Maybe I'll take it for a spin
        
       | ur-whale wrote:
       | 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?
        
         | callahad wrote:
         | 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.
        
         | bbatchelder wrote:
         | 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 wrote:
           | The idea is as old as UNCOL (1958).
           | 
           | https://en.m.wikipedia.org/wiki/UNCOL
        
         | schemescape wrote:
         | 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.
        
       | eins1234 wrote:
       | 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?
        
         | phickey wrote:
         | 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.
        
           | eins1234 wrote:
           | Nice, the fact that Fastly is comfortable betting on
           | Spidermonkey.wasm is the vote of confidence I needed to dig
           | in! Also really love seeing how much Fastly is giving back to
           | open source!
        
           | azakai wrote:
           | > We have found it [spidermonkey.wasm] to be faster than
           | QuickJS
           | 
           | Interesting!
           | 
           | Do you have numbers for code size and memory usage perhaps?
        
         | ctvo wrote:
         | > - 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
         | 
         | - https://suborbital.dev/
         | 
         | - 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.
        
           | eins1234 wrote:
           | This is super helpful. Thank you so much! Will start digging
           | into these right away.
        
           | callahad wrote:
           | > > _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._
           | 
           | For a real world example of someone using Suborbital's
           | platform for exactly that, see https://avenue.so/blog/avenue-
           | launches-custom-filters-transf...
           | 
           | It is indeed early days, but we're pretty confident that the
           | opportunity is real. Take webhooks. With webhooks, your
           | customers have to bring and manage their own infrastructure.
           | That's a pain in the ass. Everywhere that supports webhooks
           | should also support Just Running My Damn Code. Like with
           | GitHub Actions.
           | 
           | How does GitHub do it? Simple: They're owned by Microsoft.
           | GitHub can bury the problem in an ungodly deluge of cheap
           | virtual machines from their sister company, Azure.
           | 
           | You aren't owned by Microsoft, so how will you Just Run Some
           | Code? You're going to use WebAssembly. Specifically, in a
           | year or two, you're going to integrate some sort of off-the-
           | shelf commodity product that's powered by WebAssembly.
           | 
           | Suborbital is one shot at what that future might look like.
           | We'll be talking more about this in the next few weeks. And
           | it's not just us: a lot of the serverside WebAssembly folks
           | will be at Cloud Native WASM Day at KubeCon next month... say
           | hello if you're there!
        
       ___________________________________________________________________
       (page generated 2022-09-20 23:00 UTC)