Show HN: Wasmer – A Go library for executing WebAssembly binaries(github.com)
github.com
Show HN: Wasmer – A Go library for executing WebAssembly binaries
https://github.com/wasmerio/go-ext-wasm
18 comments
> "I'd love to hear about some actual use case for this"
I use WebAssembly for non security critical but fun in browser Augmented Reality experiences. We have an ever improving 10 year old fully tested C++ SDK which has bindings to iOS, Android, Windows (DLL, Electron forms), and macOS. We use Emscripten to transpile our code to ASM.JS and WebAssembly for the JavaScript in browser version.
From a company perspective it is great to reuse well tested code on another platform without investing time rewriting it.
From a developer perspective it allows my R&D engineers to write what they love in the language of their choice. Not fighting a new language each time.
From a user perspective the speed of WASM is significantly faster than pure JS and even ASM.js. This increases the experience frame rate from ~30 to 60+.
So all in all I am a huge fan of WebAssembly experiences. The only major problem encountered was when Spectre / Meltdown appeared we had issues around SharedArrayBuffer which resulted in temporarily moving clients from WASM to ASM.JS, but we have found solutions for this since.
I use WebAssembly for non security critical but fun in browser Augmented Reality experiences. We have an ever improving 10 year old fully tested C++ SDK which has bindings to iOS, Android, Windows (DLL, Electron forms), and macOS. We use Emscripten to transpile our code to ASM.JS and WebAssembly for the JavaScript in browser version.
From a company perspective it is great to reuse well tested code on another platform without investing time rewriting it.
From a developer perspective it allows my R&D engineers to write what they love in the language of their choice. Not fighting a new language each time.
From a user perspective the speed of WASM is significantly faster than pure JS and even ASM.js. This increases the experience frame rate from ~30 to 60+.
So all in all I am a huge fan of WebAssembly experiences. The only major problem encountered was when Spectre / Meltdown appeared we had issues around SharedArrayBuffer which resulted in temporarily moving clients from WASM to ASM.JS, but we have found solutions for this since.
Sure, but this is off-topic.
My question was about why one would want to call WebAssembly functions from Go or PHP.
My question was about why one would want to call WebAssembly functions from Go or PHP.
You can use wasm as a lingua franca between languages if you have some good libraries or programs that you want to share.
Like... a shared library?
I have a single libmysql.so file installed on my system, and it's used by Python, Ruby, C and PHP.
Why should I replace libmysql.so with libmysql.wasm?
I have a single libmysql.so file installed on my system, and it's used by Python, Ruby, C and PHP.
Why should I replace libmysql.so with libmysql.wasm?
Because libmysql.wasm runs on any platform whereas libmysql.so has to be replaced with libmysql.dll on windows.
Just like libmysql.dll, that libmysql.wasm will only run on Windows, if there is a Windows application that knows what to do with it.
Yea, that's generally how code works - no?
This is simply an abstraction "everyone" has agreed on. Conceptually no different than if everyone had agreed on Java, or Python, or Brainfuck.
This is simply an abstraction "everyone" has agreed on. Conceptually no different than if everyone had agreed on Java, or Python, or Brainfuck.
Exactly, and neither the first not the last at it.
But that's not a bad thing. To me it appears better than previous attempts, I heavily look forward to it.
The HN drama around WASM and cries of the days of Java always leave me perplexed. Makes me wish Java didn't suck so bad so these convos could end haha.
The HN drama around WASM and cries of the days of Java always leave me perplexed. Makes me wish Java didn't suck so bad so these convos could end haha.
All previous attempts, starting all way the back to UNCOL in 1958?
WASM only exists due to political reasons of Mozilla not embracing PNaCL.
If Chrome already had the current market share back then, we wouldn't be seeing such adoration, as if no one ever done it before.
WASM only exists due to political reasons of Mozilla not embracing PNaCL.
If Chrome already had the current market share back then, we wouldn't be seeing such adoration, as if no one ever done it before.
And if Java managed to get a hold we'd be asking why this is better than Java (which doesn't exist with these features in this manner).
That's the point. It's seemingly good, and available. Why the pushback? I don't get your (or anyones) objections.
> If Chrome already had the current market share back then, we wouldn't be seeing such adoration, as if no one ever done it before.
I think you misunderstand the adoration. It's not as if this has never been done before. It's that this isn't done now. What else can I use? Nothing. I remember 10 years ago dying for a way to run Python in the browser and having no reasonable options for general web.
Even now, what other option do I have? ASM.js is the only thing that comes to mind, which has significant downsides.
It feels like the dislike/complaints are pointed in the wrong direction. If you're upset that this isn't Java (not that you are), complain about why Java can't be used right now like WASM can. Complain that Java didn't manage to hold favor 10 years ago.
That's the point. It's seemingly good, and available. Why the pushback? I don't get your (or anyones) objections.
> If Chrome already had the current market share back then, we wouldn't be seeing such adoration, as if no one ever done it before.
I think you misunderstand the adoration. It's not as if this has never been done before. It's that this isn't done now. What else can I use? Nothing. I remember 10 years ago dying for a way to run Python in the browser and having no reasonable options for general web.
Even now, what other option do I have? ASM.js is the only thing that comes to mind, which has significant downsides.
It feels like the dislike/complaints are pointed in the wrong direction. If you're upset that this isn't Java (not that you are), complain about why Java can't be used right now like WASM can. Complain that Java didn't manage to hold favor 10 years ago.
A shared library isn’t really shareable across OSes or platforms. The neat thing about a WASM library is you can load it in your browser, in your native app or in your Python script.
Just like we used to do with Pascal P-Code interpreters back in the day.
This seems a bit confusing since "Wasmer" is also the name of the umbrella project.
Thanks for the ping! We decided to use the same name (Wasmer) for the language embeddings as for the standalone runtime as we thought it could be easier for people to find related resources for the runtime. Hopefully is not too confusing! :)
The more usual solution would be to use a longer name containing "Wasmer". So, "Wasmer Go Library" or "Wasmer for Go" or something like that.
Very cool! Could you add "native" to the benchmark so that we get a better idea of the scale?
That being said, and while it's cool to be able to run WebAssembly code from PHP, Ruby, Python or Go, I'd love to hear about some actual use case for this.
Being able to reuse code across multiple languages is nice, but that's already doable, and usually easier and faster, by building a shared library and using a FFI interface.
Is it only about the debatable security of WebAssembly's linear memory model?