[HN Gopher] Wasmer - The Universal WebAssembly Runtime
       ___________________________________________________________________
        
       Wasmer - The Universal WebAssembly Runtime
        
       Author : thunderbong
       Score  : 79 points
       Date   : 2022-06-16 17:51 UTC (5 hours ago)
        
 (HTM) web link (wasmer.io)
 (TXT) w3m dump (wasmer.io)
        
       | mwaitjmp wrote:
       | Slightly off topic what would people recommend to use to compile
       | Java to wasm? Is what's currently available still fairly
       | experimental?
        
         | dagipflihax0r wrote:
         | That would require garbage collection support, no? To me (very
         | limited) knowledge, supporting gc in WASM is being worked on
         | but not there yet.
        
         | szundi wrote:
         | I would love to save our swing app to the browser haha
        
           | easrng wrote:
           | Cheerpj can do that, though it's slow and I'm not sure what
           | the license is.
        
         | yarg wrote:
         | Graal has an LLVM back-end:
         | 
         | https://www.graalvm.org/22.1/reference-manual/native-image/L...
         | 
         | Then use the WASM back-end for LLVM.
         | 
         | Probably won't work though.
        
         | kaba0 wrote:
         | I believe both TeaVM and Google's J2CL library have
         | experimental support for targeting wasm.
        
       | drunner wrote:
       | Its been a while since I looked at using webassembly as a
       | scripting language for modules in a larger program.
       | 
       | Has support been added for:                 1) types other than
       | int, for example strings and what not without the hacks of
       | passing string lengths and addresses?            2) sharing of
       | data.  That is can I declare a struct of some sort in the main
       | program, pass that to the webassembly script, operate on it, and
       | return it?  Last I looked at that the only thing I could come up
       | with was passing it back and forth as a (pick your format here)
       | json string.
        
         | MaulingMonkey wrote:
         | > types other than int
         | 
         | Floating point values are also supported.
         | 
         | > for example strings and what not without the hacks of passing
         | string lengths and addresses?
         | 
         | That's not so much a "hack" per se, so much as it is
         | fundamentally how string types are represented when broken down
         | into their basic components. ARM, x64, etc. interact with
         | strings in similar ways. Tools like wasm-bindgen[1] generate JS
         | wrappers around the raw WASM calls, which wrap the
         | address+length APIs in string accepting ones. For non-JS hosts,
         | you might have to roll your own boilerplate or boilerplate
         | generators, but that's straightforward.
         | 
         | > sharing of data. That is can I declare a struct of some sort
         | in the main program, pass that to the webassembly script,
         | operate on it, and return it? Last I looked at that the only
         | thing I could come up with was passing it back and forth as a
         | (pick your format here) json string.
         | 
         | Multiple WASM instances can share a single memory instance
         | without copying data. A non-wasm host will typically
         | copy/serialize data into/out-of WASM memory for
         | simplicitly/convenience/durability, but there are APIs[2][3]
         | that let you directly manipulate WASM memory - and there's
         | nothing stopping you from generating identical structures on
         | both ends and directly using them without copying.
         | 
         | [1]: https://github.com/rustwasm/wasm-bindgen
         | 
         | [2]:
         | https://docs.rs/wasmer/latest/wasmer/struct.Memory.html#meth...
         | 
         | [3]: https://developer.mozilla.org/en-
         | US/docs/Web/JavaScript/Refe...
        
         | afiori wrote:
         | for 1) WASI [0][1] makes it nicer and acts sort of like a FFI
         | 
         | for 2) there are reference types, which allow wasm to receive
         | opaque objects similarly to how userland processes receive
         | handles from the kernel. In this way you could pass an object
         | to wasm and let it call host functions to modify it.
         | 
         | If you want to have the same datatype both in wasm and in the
         | host you simply a compiler that supports it.
         | 
         | [0] https://hacks.mozilla.org/2019/03/standardizing-wasi-a-
         | webas... [1]
         | https://github.com/bytecodealliance/wasmtime/blob/main/docs/...
        
       | lofatdairy wrote:
       | Note that this company in the past attempted to trademark
       | WebAssembly [^1]. Maybe their product is still solid despite
       | this, but I can't help but distrust the intentions of their upper
       | leadership.
       | 
       | [^1]: https://news.ycombinator.com/item?id=30758651
        
         | MR4D wrote:
         | Given all the other trademarks in open source [1], can you tell
         | me why this is even relevant?
         | 
         | [1] -https://en.wikipedia.org/wiki/List_of_trademarked_open-
         | sourc...
        
           | echelon wrote:
           | These trademarks appear to be owned by the body that created
           | the software in question.
           | 
           | Web assembly isn't just Wasmer. This move is like trying to
           | trademark "internet" or "hyperlink" or "metaverse".
        
           | lofatdairy wrote:
           | Typically the trademarks are held by the
           | collation/organization behind the OSS or the open standard.
           | Either that, or held by the person/org who created the
           | software and released it. Here, wasmer is not the inventor of
           | WebAssembly, and the group behind webassembly (the w3c
           | community group and w3c working group) [^1] probably would be
           | the ones you'd expect to own the trademark.
           | 
           | It seems part of the motivation for Wasmer to apply for the
           | trademark was because they felt snubbed by the Bytecode
           | alliance [^2] and wanted to start their own foundation (with
           | blackjack and hookers, presumably). The Bytecode alliance
           | doesn't own any of the trademarks either, and seems to be
           | more of a collaborative effort, but is worth mentioning as
           | part of the overall story.
           | 
           | [^1]: Groups listed here: https://webassembly.org/. and
           | members here: https://www.w3.org/Consortium/Member/List and
           | https://www.w3.org/community/webassembly/participants. Note
           | that a few Wasmer employees (the CEO, for one) belong to the
           | community group, but don't chair it.
           | 
           | [^2]: https://bytecodealliance.org/ and
           | https://wasmer.io/posts/wasmer-and-trademarks
        
         | ignoramous wrote:
         | This has been discussed to death here and elsewhere. It isn't
         | like wasmer doesn't have credible competition from companies
         | well-funded than them, way bigger in size.
         | 
         | I'd wish folks focused on the _incredible_ amount of
         | engineering that has gone into wasmer. The breadth of its
         | offering is astonishing for a team of its size. Sad that the
         | engineering team couldn 't be together for longer, but the
         | runtime is impressive nevertheless.
         | 
         | I look at wasmer's various OSS repos from time to time to
         | understand how it was put together. It has been very rewarding
         | to say the least.
         | 
         | (yes, I am also aware of the fallout between Syrus, the
         | founder, and a few ex wasmer engs, but let's also focus on the
         | good parts too, folks!)
        
           | lofatdairy wrote:
           | Right, by no means do I want to disparage the product (which
           | is open source anyways) nor derail the conversation. I just
           | think it's important to bring up since this post is just the
           | company's landing, which would obviously be positive about
           | the product and company, especially in case someone missed
           | those discussions. Right now I don't see any paid offerings,
           | but things like attempts to hijack an entire language would
           | hopefully come into consideration before paying them.
           | 
           | That said, trademarking WebAssembly seems to spit in the face
           | of the engineering and technical design work that went into
           | WebAssembly before even Wasmer arrived. Perhaps not as sleek
           | and polished as a VC-backed startup, but we can praise Wasmer
           | for what it has accomplished while also expressing
           | reservations regarding the people who stand to profit from
           | its success.
        
         | synergy20 wrote:
         | Thanks for the info, that's unbelievable to even have that odd
         | idea.
        
         | krapp wrote:
         | Their product is open source and MIT licensed, so their
         | intentions shouldn't be relevant.
        
           | croes wrote:
           | Who cares about the license of their products if you get sued
           | for using the word WebAssembly
        
             | krapp wrote:
             | I mean, they _lost_ the case, they 're not _going_ to be
             | able to successfully sue anyone for using the word
             | WebAssembly, which they could have done regardless of
             | whether or not they trademarked it, so that 's a moot
             | point. Nevertheless, people seem to have no problems
             | forking Firefox and not literally calling it Firefox. Other
             | open source companies own trademarks, and no one is
             | implicitly suspicious of their motives. In the darkest of
             | timelines when Wasmer owns a trademark over the word
             | WebAssembly _just use another word in your brand._
             | 
             | It seems like people are specifically interested in
             | spreading FUD about Wasmer and I can't see the
             | justification for it.
        
               | afiori wrote:
               | filing to trademark the name of technology invented by
               | someone else is still a dick move.
               | 
               | It is as if Nodejs tried to trademark V8
        
               | krapp wrote:
               | Sure, but as dick moves by software projects go, it's far
               | from the dickest.
        
               | reitzensteinm wrote:
               | They're creating a platform, and that's a risky thing to
               | build on if you can't trust the company.
               | 
               | Sure it's open source, but unless you're at a scale where
               | you actually can take it over and maintain it, that's not
               | some magical escape hatch.
               | 
               | This isn't a theoretical thing for me. I've got a project
               | in mind that wasmer would be a candidate for, and I ruled
               | it out for this reason.
        
           | lumost wrote:
           | Ultimately their intention does matter, even open source
           | projects tend to die once the financial interest in their
           | success is gone. Most open source libraries you interact with
           | are created in the course of building apps internally at a
           | company, created by consultants and free lancers to support
           | their consulting work, or are created as monetizable products
           | in their own right.
           | 
           | Software is a hard and complex thing to build, people don't
           | tend to work full-time on projects which they can't earn a
           | living from.
        
             | hunterb123 wrote:
             | > Ultimately their intention does matter, even open source
             | projects tend to die once the financial interest in their
             | success is gone.
             | 
             | > Software is a hard and complex thing to build, people
             | don't tend to work full-time on projects which they can't
             | earn a living from.
             | 
             | Wouldn't these be positive points towards how Wasmer is
             | running the company? They are trying to keep their open
             | source product alive by marketing and finding a way to
             | build revenue, to continue to fund development.
             | 
             | In the end, if they fail, it's all open source, someone can
             | fork and continue it if the demand is there. Until then,
             | they are the ones doing it, and doing it well imo.
        
               | croes wrote:
               | If they fail the IP is bought by a parent troll and
               | everybody is sued using the term WebAssembly.
        
       | loudmax wrote:
       | The Wasmer main page is splashy but not particularly informative.
       | 
       | There's a lot more information on their github page here:
       | https://github.com/wasmerio/wasmer
        
       | synergy20 wrote:
       | https://github.com/appcypher/awesome-wasm-runtimes
       | 
       | quite a list, it is becoming a new JVM that runs all different
       | languages.
        
         | idle_zealot wrote:
         | That is a list of WASM runtimes, analogous to JVM
         | implementations, and not languages that run on WASM runtimes.
        
           | synergy20 wrote:
           | exactly, wasmer is also a runtime itself, but might be the
           | most popular one for now.
        
             | Jyaif wrote:
             | The most popular one is the one in Chromium by far,
             | followed by Safari and Firefox.
        
               | synergy20 wrote:
               | I think we're leaning towards the outside-browser runtime
               | here, that is to use webassembly _everywhere_, is it?
               | does chromium's runtime run out side of chromium, e.g.
               | wasm my.wasm?
        
       | potsandpans wrote:
       | I just simply don't trust Wasmer the company. The trademarking
       | and bytecode alliance drama coupled with the over-the-top
       | marketing splash pages and reaching claims ("THE" universal
       | runtime) and attemps to sockpuppet discussions on hn and reddit
       | along with bizarre pr stunts.
       | 
       | The product may be good, but the company stinks.
        
         | hunterb123 wrote:
         | > I just simply don't trust Wasmer the company
         | 
         | You don't trust them with what? Their core products are open
         | source.
        
       | vcryan wrote:
       | What does this have to do with Blockchain?
        
       | Conlectus wrote:
       | Given my experience, I would not recommend using Wasmer over an
       | alternative like Wasmtime for several reasons.
       | 
       | 1. Lack of support for `externref`, AKA opaque references to host
       | data. Sure, the Wasmer 2.0 blog post _claims_ they added support
       | for it, but that amounts to allowing you to read the type
       | signature in an existing module, but not actually use the feature
       | yourself. With some digging, my educated guess is they wanted
       | this to be their headlining 2.0 feature but weren't able to get
       | it working, so they just pretended in their blog post and left
       | the incomplete version behind a development flag.
       | 
       | 2. An awkward context API for host calls. All host data
       | associated with an instance must be `Send` + `Sync`. In practice
       | I've found this leads to wrapping your entire context object in a
       | `Arc<RefCell<T>>`, even if your data could otherwise live on the
       | stack. Wasmtime does not have this limitation, so it's not a hard
       | technical requirement.
       | 
       | 3. It took me about 2 weeks of development to run into a use-
       | after-free bug bubbling up into Rust.
       | 
       | 4. The performance, at least for my use case, was not
       | meaningfully better than Wasmtime. This may not be true if you're
       | doing a lot of intense number crunching.
       | 
       | 5. Lack of support for instance resource allocation pools.
       | Wasmtime allows you to pre-allocate / reuse the resources
       | associated with an instance, whereas you would have to roll this
       | on your own with Wasmer.
       | 
       | 6. Lack of support for the module linking proposal. This proposal
       | may be incomplete, but it is still helpful ahead of its
       | replacement.
       | 
       | This is on top of, as others have mentioned, their questionable
       | business practices[1][2].
       | 
       | All of this may improve, but as things currently exist, Wasmtime
       | should give you everything you would want from Wasmer in a more
       | stable, more complete and more ergonomic package.
       | 
       | [1]: https://mnt.io/2021/10/04/i-leave-wasmer/
       | 
       | [2]: https://wasmer.io/posts/wasmer-and-trademarks
        
         | syrusakbary wrote:
         | Hey Conlectus, thanks for the detailed technical review. Let me
         | address some of your comments (note: I work at Wasmer)
         | 
         | Edit: I made this comment when the parent comment was only
         | questioning technical things. I don't know why the author
         | decided to edit their comment with an extra "questionable
         | business practices" afterwards (as it seems the author is
         | looking for reasons to not use Wasmer rather than the
         | opposite). In any case, I left my technical replies for future
         | reference.
         | 
         | > 1. Lack of support for `externref`, AKA opaque references to
         | host data.
         | 
         | We do support `externrefs`, but had to partially disable it due
         | to big impacts on performance due to how we did the initial
         | implementation. We are refactoring this in Wasmer 3.0 and this
         | shall be completely addressed in the Wasmer 3.0 release.
         | 
         | > 2. An awkward context API for host calls.
         | 
         | This is probably the point I agree most with. This is already
         | being worked on. Please take a look on this PR if you are
         | interested on knowing how things will look like for Wasmer 3.0
         | [1]
         | 
         | > 3. It took me about 2 weeks of development to run into a use-
         | after-free bug bubbling up into Rust.
         | 
         | Sorry to hear that! We are working hard make sure there are no
         | such leaks/bugs in Wasmer
         | 
         | > 4. The performance, at least for my use case, was not
         | meaningfully better than Wasmtime
         | 
         | In general, being able to have to have a pluggable compiler
         | infrastructure I think makes the runtime infrastructure way
         | more resilient and with almost zero effort we should be able to
         | support more chipsets (such as RISC-V). In the case of Wasmtime
         | they are using the partially-optimized compiler Cranelift, but
         | they only support for x86_64 and aarch64. They are doing super
         | interesting things such as the ISLE initiative but IMHO they
         | are far from having the robustness that projects like LLVM
         | already have. Which is why Wasmer chose a pluggable compiler
         | infrastructure rather than tying itself to only one.
         | 
         | > 5. Lack of support for instance resource allocation pools.
         | 
         | Yup, this is on our plans!
         | 
         | > 6. Lack of support for the module linking proposal
         | 
         | This have been very intentional. IMHO module linking is an
         | over-engineered solution that can be solved more easily with a
         | static spec definition outside of Wasm. I personally think it's
         | unlikely that it will reach broad adoption. But I can assure
         | you that Wasmer will implement this once browsers do (if they
         | ever do, of course)
         | 
         | [1]: https://github.com/wasmerio/wasmer/pull/2892
        
       | gycom wrote:
       | Y'know what I want? A wasm runtime for microcontrollers. It would
       | be super awesome to be able to write code for a microcontroller
       | in any language I want.
        
         | gycom wrote:
         | Scratch that, apparently such things exist. What a world we
         | live in!
        
         | danellis wrote:
         | Which language do you want to use? You already have a choice.
        
         | saidinesh5 wrote:
         | You might want to look at:
         | 
         | https://github.com/wasm3/wasm3
         | 
         | Out of curiosity, what kind of use cases would you want to
         | target with microcontrollers running wasm binaries?
        
       | clpm4j wrote:
       | YC (S19) company
        
       ___________________________________________________________________
       (page generated 2022-06-16 23:00 UTC)