[HN Gopher] Wasmer 3.0
___________________________________________________________________
Wasmer 3.0
Author : syrusakbary
Score : 168 points
Date : 2022-11-23 17:01 UTC (5 hours ago)
(HTM) web link (wasmer.io)
(TXT) w3m dump (wasmer.io)
| tlarkworthy wrote:
| Off topic but is there a good way of running wasi on browser?
| syrusakbary wrote:
| There are multiple ways! I'd recommend `@wasmer/wasi` since it
| uses the same WASI implementation as Wasmer (compiled from Rust
| to Wasm using wasm-bindgen):
|
| https://www.npmjs.com/package/@wasmer/wasi
| williamstein wrote:
| wasi-js is another one I'm actively supporting that is in
| pure JavaScript (hence small and easily hackable):
| https://www.npmjs.com/package/wasi-js
|
| This is based on what wasmer used to provide for wasi in the
| browser before they did their major rewrite in rust mentioned
| above. I personally find the JavaScript version more useful
| for my projects so I revived their old project and am
| maintaining it.
| DustinBrett wrote:
| Thanks for this info! I have a terminal on my website that
| was still using the old version and I've been wanting to
| upgrade it and get better input/blocking support. I will
| give this a try.
| williamstein wrote:
| I have added some new ad hoc hooks for blocking io. You
| can see how they are used in https://CoWasm.org and
| https://CoWasm.sh
| nycticorax wrote:
| Can someone ELI5 what problem this solves? I think of WebAssembly
| as being a tool for getting code written in <random language> to
| run in a web client. Can't I already run code written in <random
| language> on a server that I control? Heck, PG went on at some
| length in one of his early essays about how that was one of the
| great things about the Web: you could use any language you wanted
| on the server. Even Common Lisp...
| brundolf wrote:
| - Running code on a server you don't control
|
| - Running code you don't fully trust on a server you do control
|
| WASM comes with powerful sandboxing, and if you combine that
| with static linking you can pretty much drop Docker for your
| PaaS (and all the overhead/complexity/insecurity that comes
| with it). This is what Cloudflare Workers do
| duped wrote:
| WASM is JVM with lessons learned
| flohofwoe wrote:
| WASM is also useful for distributing a single binary blob that
| runs on different Operating Systems and CPU architectures,
| instead of 'stamping out' NxM native executables. This area
| overlaps more with Java and .NET (but with more/different
| language options) than 'an alternative to JS in the browser'.
|
| For instance I have a C++ shader compiler which includes some
| massive 3rd party libraries (glslangValidator, SPIRVTools and
| SPIRVCross) which takes _forever_ to compile, so distributing
| in source code form is not really an option, and the only
| alternative is to ship precompiled binaries for each supported
| OS /CPU combination. Currently I do this via GH Actions, which
| kinda works, but just building a single WASM blob and shipping
| that to users (who then would need to install one of the WASM
| runtimes though) sounds kinda interesting.
|
| PS: WASM may also be useful as universal plugin format. For
| instance the new Microsoft flight sim uses WASM instead of
| scripting or native DLLs for modding:
|
| https://docs.flightsimulator.com/html/Programming_Tools/WASM...
| kaba0 wrote:
| Java's GraalVM can do plenty of languages, on top of running
| managed ones much faster. I don't see novelty here.
| flohofwoe wrote:
| If I compile a C or Rust program to run in GraalVM, will
| the LLVM bitcode be converted to some sort of universal
| bytecode, or does Graal attempt to run the bitcode directly
| via a plugin? (e.g. do I distribute GraalVM bytecode or
| LLVM bitcode to the user?).
|
| The documentation is a bit unclear about this, but there's
| this weird blurb at the end:
|
| > Note: LLVM bitcode is platform-dependent. The program
| must be compiled to bitcode for an appropriate platform.
|
| ...why would this detail even matter if LLVM bitcode is
| converted to 'GraalVM bytecode'? In any case, it doesn't
| sound much like "write once run everywhere" ;)
|
| See: https://www.graalvm.org/22.2/reference-manual/llvm/
| kaba0 wrote:
| Graal's truffle runtime works basically as an AST
| interpreter, so you have to ship the LLVM bitcode.
|
| I have yet to get my feet wet with sulong, but my guess
| would be that LLVM will produce different bitcode on
| different platforms, and thus the execution can
| potentially be different - also note that llvm bitcode is
| not a stable format. But I don't think that interpreting
| it on a different platform than it was compiled on would
| have a fundamental reason not to work (after all, it is
| just java code) - perhaps it uses the platform llvm libs
| for some parsing, which is not platform-agnostic?
| coldtea wrote:
| Well, the point is not in some novelty, but that it does a
| similar thing as an open standard, with more than one
| vendor and community behind it for runtimes, tooling, etc.,
| that it doesn't come from Oracle (which is an extra bonus),
| and with compatibility with the web and bigger boost behind
| it than Graal ever achieved thus far to boot.
| kaba0 wrote:
| Java bytecode is an open standard with more completely
| independent implementations than wasm, but it is slightly
| higher level. Graal (truffle) uses ASTs mapping to Java
| language primitives as a basis (in a way sorta similar to
| wasm, as that is not really a byte code).
| iknowstuff wrote:
| It lets you run untrusted code. Great for exposing a plugin
| API.
| rglullis wrote:
| "dumb clients" don't exist anymore. Why run things on the
| server and have to deal with scaling issues, if I can just
| distribute super complex applications easily and as reliably as
| publishing a web page?
| satvikpendem wrote:
| Next.js' (and others') server side rendering exists and React
| Server Components exist as well. We're seeing a reversion
| back to the server due to SEO and performance concerns.
| Sodman wrote:
| Being able to add arbitrary logic to an otherwise static binary
| has a lot of interesting use cases. For example Envoy Proxy
| supports hot-loading arbitrary HTTP filters compiled to WASM
| into its filter-chain. This allows users to extend the feature
| set of Envoy, by adding custom logic to request parsing,
| reporting custom metrics, calling out to other services before
| forwarding the request, etc etc.
|
| This allows their unique custom use-case-specific code to be
| managed separately to Envoy, so it can be ported across
| upgrades etc. It also means that if there's a very particular
| feature you want that's unique to your business, and wouldn't
| make sense to contribute to the upstream OSS project, you can
| write a WASM module for it.
|
| It's somewhat niche, because anything built in this way which
| is generally useful to many users, will probably just be made a
| native feature of the host platform. Conversely, anything that
| does something significantly complex and custom should probably
| live as it's own stand-alone microservice somewhere. There's
| still a lot of room for value between the two extremes though!
| FooBarWidget wrote:
| And can someone ELI5 why WebAssembly is useful, given that
| there are already a myriad of other virtual machines out there
| (JVM, CLR, BEAM, etc)?
|
| And why could/did those other virtual machines not evolve to
| fulfill the need that WebAssembly fulfills? Why is a new
| machine language and new virtual machine necessary?
| IshKebab wrote:
| Webassembly can be targeted by C/C++ and Rust. It's also
| designed with security in mind. The JVM is not a reliable
| sandbox.
| hahnchen wrote:
| I think it's meant to make it easier to use. They also have
| their whole package manager to use
| jasonwatkinspdx wrote:
| WASM has an OS abstraction API that ends up being pretty good.
| There's work in progress on cross language resource sharing,
| interface types, etc. It's early days yet but this is
| generating excitement for WASM as a sort of very lightweight
| cross language container/vm.
|
| It's also useful in "plugin" scenarios, like say filtering code
| in a network proxy. Or if you wanted to make your own Function
| as a Service system.
| cheriot wrote:
| Plugins for desktop apps would be safer if the plugin is run
| with WASM.
| clscott wrote:
| It's also valuable for running code written in <random
| language> to be executed in <another random language>.
|
| Write a library in Rust and compile it to WASM, theoretically
| any language with WASM bindings could run it.
|
| This could really make niche languages more easily adopted if
| their execution environment supported libraries in WASM.
|
| Imagine using Java's JDBC from something like Nim. Nim could
| take advantage of a 30 year old mature and fast database access
| framework without haveing to envest that ime and effort
| themselves.
|
| Or even something more modern like the polars dataframe
| library.
| cpeterso wrote:
| Firefox uses this approach to create a lightweight, in-
| process sandbox (called "RLBox") for some third-party
| libraries. The library is compiled from C/C++ to wasm and
| then wasm is transpiled _back_ to C++, all at Firefox compile
| time so no wasm compilation is needed at Firefox run time.
|
| https://hacks.mozilla.org/2021/12/webassembly-and-back-
| again...
| ptx wrote:
| > _Imagine using Java 's JDBC from something like Nim._
|
| You can already do this with JNI. How does WASM improve
| things? In both cases (WASM or native code) you get the
| overhead of two runtimes and the hassle of converting data
| types, don't you?
| kaba0 wrote:
| GraalVM's polyglot execution does solve this problem, it
| can even optimize across language barriers. (But it runs
| native languages as LLVM "bitcode" basically, not natively)
| merb wrote:
| GraalVM will Not succeed, because every language needs
| Tour be reimplemented in graal, in wasm every language
| just needs a wasm Target. Also Java is really slow Boy
| adding a wasm Target. Most languages have a way to run on
| a wasm engine.
| kaba0 wrote:
| They have to be implemented as interpreters only though.
|
| > Most languages have a way to run on a wasm engine
|
| But it is basically useless for managed languages that as
| of yet has to bring their runtimes as well.
| paulgb wrote:
| Even if the feature set were limited to what's possible
| with Java/JNI, the fact that Oracle does not own any piece
| of it is a feature in its own right.
| fschuett wrote:
| WASM is executable from every language to every language,
| you wouldn't have to write code specifically targeting the
| JNI for example. Say you want to use a PDF library from
| Java, a web server from C# and some scripts someone wrote
| in Python, and for whatever reason your preferred language
| of the day is Haskell. In the normal case you'd have to
| rely on someone to maintain Java -> Haskell, C# -> Haskell
| and Python -> Haskell glue code. But with wasm, you just
| pull in csharp.wasm, python.wasm and java.wasm, so it's
| just one binding layer, not three.
|
| It's often the case that people choose languages based on
| the availability of the libraries written in those
| languages. The goal of non-browser WASM is to get rid of
| that and to minimize the friction of inter-language
| communication, so you don't have to rewrite it in
| $language. WASM is not tied to any language (like the JNI).
| return_to_monke wrote:
| That does look pretty awesome - wouldn't it hurt the
| performance tho? Especially with the DB Example, a
| database usually needs to be fast.
| clscott wrote:
| Sure, maybe it's not as fast to execute as another
| implementation, but having ANY implementation is far more
| useful than none at all.
|
| Here's an example where performance wouldn't matter as
| much:
|
| Let's say I'm the author of a programming language and I
| want to add a db layer to my standard lib.
|
| Via WASM I can use a working backend while I'm protyping
| the API for my db layer. If the performance isn't fast
| enough I can start implementing my own "native" version
| with feature parity.
|
| I can then use some of the tests from the original
| library (via WASM) to make sure my implementation has
| feature parity to the original.
| fschuett wrote:
| In the short term, you wouldn't want to run databases in
| WASM. You could, but it's not really worth the effort, as
| long as the WASM runtime allows TCP connections, you can
| just connect to any hosted DB as usual.
|
| For performance, we ship three compiler backends: LLVM
| (fast execution, but slowest compilation), cranelift and
| singlepass (our own compiler, very fast compilation and
| you can compile untrusted code - but slowest execution).
| There is a slowdown, but the goal is to keep that at a
| minimum (proper performance tracking is on the bucket
| list). We are pre-compiling the python.wasm (which was
| already pre-optimized when the compilation to WASM
| happened) with LLVM, so you should get assembly that is
| very close to the native execution, with the exception of
| the necessary VM overhead. The goal is to make it so that
| the interoperability gains are worth the performance hit.
| comex wrote:
| > But with wasm, you just pull in csharp.wasm,
| python.wasm and java.wasm, so it's just one binding
| layer, not three.
|
| A bit of a rant, but there's nothing specific to
| WebAssembly about this.
|
| Whether you're using WebAssembly or native code:
|
| - The basic interface you get between caller and callee
| is a low-level calling convention, where essentially all
| you have are integers (which can be pointers), and any
| higher-level data structures need to be built out of
| that.
|
| - A slightly higher-level interface is the C ABI; many
| languages support exporting and consuming APIs using the
| C ABI, but it can be frustratingly low-level.
|
| - To provide an even higher-level interface, there are
| bindings generators, which could in principle either be
| designed as direct language-to-language bridges, or as a
| single common standard that any language can provide and
| consume APIs for.
|
| The WebAssembly Component Model standard and the wit-
| bindgen tool are an example of the latter. They happen to
| be defined specifically for WebAssembly rather than
| generically for any architecture. If they become
| ubiquitous at some point in the future like they're
| supposed to, then WebAssembly will have an advantage when
| it comes to high-level bindings, not because of any
| fundamental technical aspect of WebAssembly itself, but
| just because people building these bindings on top of
| WebAssembly have more motivation and more consensus.
| (WebAssembly does have a technical advantage when it
| comes to sandboxing between components, but this is
| relatively unimportant for most use cases.)
|
| But for now, wit-bindgen isn't ubiquitous, and most of
| those languages don't even work in WebAssembly yet...
| MuffinFlavored wrote:
| > Write a library in Rust and compile it to WASM
|
| this misses the fact that (unless I'm wrong), WASM by itself
| can't really do anything like file system/network operations
|
| I know that's not the main usecase of where to put WASM logic
| that needs to be performant (it's the opposite really)
|
| I just think it's worth calling out that a WASM library
| really can't do much from what I understand. Like... basic
| math? You have to supply it (through a WASM runtime) interop
| to other functions it can call... I think?
|
| Would love to be taught/proven wrong.
| nateabele wrote:
| This is where WASI (WebAssembly System Interface) comes in.
| TobyTheDog123 wrote:
| But isn't WASI considered harmful?
|
| I absolutely disagree with ASC's stance on this, but it
| seems that the AssemblyScript project at least wants
| nothing to do with that kind of thing:
|
| [1] https://devclass.com/2022/09/08/assemblyscript-
| project-wasi-...
|
| [2] https://www.assemblyscript.org/standards-
| objections.html
|
| [3] https://github.com/WebAssembly/WASI/issues/401
| codeflo wrote:
| It's my understanding that WASI is using Unix-like
| abstractions, because they also target native execution,
| while the AssemblyScript would prefer web-like
| abstractions, because they exclusively target the
| browser. From your second link at least, this seems like
| the main technical complaint:
|
| > Languages that would naturally fit the Web platform not
| only are overlooked, but WASI's self-imposed abstinence
| of Web concepts undermines other languages'
| interoperability potential with JS and the Web platform
| specifically.
|
| The problem is that objectively, the web platform is
| garbage. Half-baked, weirdly incomplete abstractions,
| most of can only be rationally explained as either
| historical accidents or the aftermath of political fights
| on standards committees. Why would anyone base a new
| abstraction around those if they don't strictly have to?
| initplus wrote:
| I have a hard time taking this seriously, it's the
| objections of one individual who seems to be seeing
| ulterior motives behind WASI... I don't think their
| objections are really as strong as they make out. Big red
| "In violation" labels are a bit much.
|
| WASI is trying to be a cross language API for use by
| multiple languages that target WASM. But the author wants
| this API to more closely follow existing JS conventions?
| Sure that's useful to JS/Web, but it's not useful for
| anyone else trying to target WASM with a language that's
| not JS. And if you want to target Web API's with JS,
| can't you already just write native JS?
|
| Bikeshedding over string encoding for example and
| objecting to WASI's promotion of UTF-8 because it doesn't
| match the encoding used by JS.
| [deleted]
| MuffinFlavored wrote:
| https://www.npmjs.com/package/as-fetch
|
| this has 7 weekly downloads... I would expect more?
| zrail wrote:
| I'm not sure if it's mainstream but my thoughts on server-side
| WASM always run to user-provided logic. WASM provides a helpful
| building block for a generic user-provided logic sandboxed
| runtime.
|
| Think about a workflow engine embedded in a marketing product.
| Usually there's some kind of GUI builder which generates an AST
| to be interpreted directly at runtime. What if instead the GUI
| generated a WASM artifact to be run on sandboxed runtimes?
|
| What if, furthermore, you offered advanced users the
| opportunity to upload WASM binaries where they could implement
| arbitrarily complex logic to be executed in the sandbox?
|
| I think this is a super powerful concept, although of course
| making a business case for implementing it is the trick.
| fwsgonzo wrote:
| I don't think a server-side sandbox makes sense for anything
| that is JIT-based (or even binary translation). We already
| have KVM which is actual native performance, and it can run
| anything you would ever want, and then some. WASM is bytecode
| working on a 2GB linear arena, and it fits OK in a browser.
| azakai wrote:
| The 2GB limit was a temporary browser limitation. Modern
| browers mostly support 4GB now. And wasm64 is testable
| today, which supports 64-bit pointers and more than 4GB.
| zrail wrote:
| I don't think that's really the use case I'm describing.
| Maybe I'm doing a bad job, I dunno.
|
| The use case is essentially user logic for event stream
| processing, where the events are things like "received an
| email" or "clicked a link" or "3 days have passed". You're
| not going to spin up a KVM for every contact on a 2 million
| member email list even if you're using Firecracker, but
| executing a WASM blob for every event might be feasible.
| moralestapia wrote:
| wasm is a specification for a VM (VM as in Java, not as in
| AWS/docker).
|
| wasm gives you the bare minimum to run, other projects fill the
| gaps between that and what you would normally expect for an
| execution environment (ABIs, file system access, stacks,
| etc...). wasmer is one of such projects.
| trh0awayman wrote:
| WASM is basically a misnomer at this point. People are using it
| as a universal virtual machine/runtime. Whether that makes any
| sense is still an open question.
| kbaker wrote:
| In your view, why does it not make sense? It certainly seems
| appealing as a universal runtime, and lives up to its claims
| as long as things like WASI get standardized.
| CharlesW wrote:
| > _WASM is basically a misnomer at this point._
|
| Web standards/technologies are in wide use outside of
| browsers (via things like Electron), so you may find that the
| name makes more sense when viewed through that lens.
| nuc1e0n wrote:
| Does the exe generation need any runtime like vb needed vbrun.dll
| back in the day?
| fschuett wrote:
| No, it's a standalone binary. It compiles the wasm file to
| native assembly (depending on target), then uses zig build-exe
| to link libc and libunwind into a final exe file.
|
| $ wasmer create-exe --target x86_64-windows-gnu qjs.wasm -o
| ./js.exe && llvm-objdump -p ./js.exe | grep DLL
| DLL Name: KERNEL32.dll DLL Name: msvcrt.dll DLL
| Name: WS2_32.dll DLL Name: ADVAPI32.dll DLL
| Name: USERENV.dll DLL Name: bcrypt.dll
| lijogdfljk wrote:
| The `create-exe` subcommand is interesting!
|
| For any language with decent cross compiling capability, is there
| a use case for `create-exe`? Eg i use Rust these days.. and i
| wonder if there's any use case for me to cross compile via wasmer
| instead of natively. My project(s) do work on WASM as a target
| (for browser reasons), maybe it would be easier to setup cross
| compiling via wasmer and not manage the release pipelines i have?
|
| Though for some of my performance critical applications i may not
| want to bother with it. Simply because i'd suspect wasmer might
| not have the same platform specific optimizations that natively
| compiling would give me.
| williamstein wrote:
| Wasm provides very extensive sandboxing capabilities that are
| extremely valuable for certain applications (plugins, real-time
| collaboration, multi tenant hosting), and pointless for others.
| You can leverage that by using wasm and create-exe.
| gary_0 wrote:
| The docs.wasmer.io page could use some work (it looks nice,
| though!) For instance, under the C/C++ section, the MinGW link at
| the bottom leads to a hijacked domain, and the "Wasmer C API"
| link in the sidebar leads to a 404.
| samtheprogram wrote:
| Running WASM outside of a web browser? Obligatory Gary Bernhardt,
| "The Birth and Death of JavaScript":
| https://www.destroyallsoftware.com/talks/the-birth-and-death...
| Jaxkr wrote:
| > support for multi-value functions
|
| Link to example for this? Tried Wasmer about a year ago and had
| too much trouble passing multiple non-int args with a Rust host
| (so no JS bindgen)
| syrusakbary wrote:
| This test might be useful (although it might be a bit hard to
| read because of the usage of macros) [1]. We will create a
| simple example of multivalue to showcase how it can be used
|
| [1]:
| https://github.com/wasmerio/wasmer/blob/master/tests/compile...
| kthakore wrote:
| Great work Wasmer team :)
| tracker1 wrote:
| One annoyance, on the wapm website, seems you can't click on
| search results to open in a new tab. :-/
|
| Wasmer seems pretty cool, and may in fact be a future for micro-
| services.
| tromp wrote:
| Can this be compared to something like actually pdrtable
| executable [1], that makes a single executable run on Linux,
| MacOS, Windows, FreeBSD, OpenBSD, and NetBSD?
|
| While wasmer seems to support more source languages, it requires
| running the executable under a WASM virtual machine. Are there
| other important differences?
|
| [1] https://justine.lol/ape.html
| brundolf wrote:
| WASM also gives you sandboxing
| gary_0 wrote:
| And it works the same regardless of the host CPU
| architecture, whereas APE is built around x86_64.
| TobyTheDog123 wrote:
| While I'm glad to see WASM get more attention, iirc wasmer has
| had some behavioral issues / drama in the past.
|
| However, it seems they're making far more progress than wasmtime,
| so taking the bad with the good I guess.
| lioeters wrote:
| Cross-compiling to different targets with `create-exe` command is
| a very intriguing idea.
|
| > In Wasmer 3.0 we used the power of Zig for doing cross-
| compilation from the C glue code into other machines.
|
| > This made almost trivial to generate a [binary] for macOS from
| Linux (as an example).
|
| > So by default, if you are cross-compiling we try to use zig cc
| instead of cc so we can easily cross compile from one machine to
| the other with no extra dependencies.
|
| https://wasmer.io/posts/wasm-as-universal-binary-format-part...
|
| > Using the wasmer compiler we compile all WASI packages
| published to WAPM to a native executable for all available
| platforms, so that you don't need to ship a complete WASM runtime
| to run your wasm files.
|
| https://wasmer.io/posts/wasm-as-universal-binary-format-part...
| h4x0rr wrote:
| one thing to note is that the performance is still on the level
| of normal wasmer exexution and thus inferior to natively
| compiled code in most instances
| coder543 wrote:
| > thus inferior to natively compiled code in most instances
|
| Do you have a source for this claim? Using a JIT with AOT
| binaries (which is what this seems to be) can sometimes be
| very beneficial. It's like doing PGO without the manual work
| of doing PGO properly.
|
| I'm sure the JIT can make poor decisions sometimes, but I
| would want to see a comprehensive set of benchmarks, like The
| Benchmarks Game and TechEmpower showing this. Benchmarks
| aren't always reflective of reality, but good ones are
| usually more insightful than random opinions.
|
| The only Wasmer benchmarks I could readily find were from
| three years ago, and that was before Wasmer 1.0, let alone
| 3.0.
|
| EDIT: Reading more... maybe `create-exe` doesn't include the
| JIT at all, so it is just making an AOT binary from the
| source WASM? In which case, benchmarks are _just as
| necessary_ to understand how it affects performance compared
| to a normally-compiled native binary.
| grose wrote:
| Here is an extremely unscientific benchmark using the
| Takeuchi function and Trealla Prolog: $
| make wasm $ wasmer create-exe tpl.wasm -o tpl-wasm
| $ time ./tpl-wasm --consult < tak.pl -g 'time(run)' --ns
| '<https://josd.github.io/eye/ns#tak>'([34,13,8],13).
| % Time elapsed 1.39s real 0m1.403s user
| 0m1.333s sys 0m0.070s $ time tpl
| tak.pl -g 'time(run)' --ns
| '<https://josd.github.io/eye/ns#tak>'([34,13,8],13).
| % Time elapsed 0.448s real 0m0.473s user
| 0m0.463s sys 0m0.010s
|
| WASM is about 3x slower. In general I've found it to be
| 2-3x slower, at least for my use cases. I also tried the
| LLVM compiler instead of Cranelift but it was slightly
| slower.
| coder543 wrote:
| Certainly interesting, but I'm not sure how well the
| performance of a prolog interpreter maps to other use
| cases.
|
| That benchmark looks too short to be a useful measure of
| how JIT influences performance, otherwise I would ask how
| the regular Wasmer does in that benchmark too (since it
| seems like create-exe doesn't include a JIT).
| riquito wrote:
| I guess it's safe to assume that if they're not providing
| benchmarks claiming it's faster than native, then it's
| slower (and that's ok)
| coder543 wrote:
| I don't commonly see mainstream programming languages,
| compilers, or runtimes providing comparative benchmarks
| for themselves these days, so I don't consider that a
| safe assumption at all. It would certainly be nice if
| Wasmer did provide some benchmarks.
| _joel wrote:
| There are lies, damn lies, statistics and benchmarks, but
| I do take you point. It does give an idea but is the main
| goal of the project speed or portability (genuine
| question)?
| coder543 wrote:
| The usefulness of portability is generally less the more
| it sacrifices performance.
|
| I also think of WASM as a tool that could provide a
| useful security boundary.
| karmasimida wrote:
| I have a use case in mind
|
| I have a piece of library written in rust that i need to run on
| multiple different hosting environment due to business reasons,
| like java/js. They will all call this library to validate part of
| the logic at the same time do something else
|
| Could wasmer help in this case for me to write once and have
| consistent behavior everywhere ?
| devops3 wrote:
| Cool! Does this support compiling of games to WASM, with
| deployment at the edge?
| fschuett wrote:
| It does, using the wasm4 console target:
| https://itch.io/jam/wasm4-v2
___________________________________________________________________
(page generated 2022-11-23 23:00 UTC)