Universal Binaries Using WASM

https://github.com/wasmerio/wasmer

by grey-area • 7 years ago

335 229 7 years ago

github.com

spease• 7 years ago

Very impressive. Is this compatible with any WASM-compliant language, or just the ones listed? EG AssemblyScript:

https://github.com/AssemblyScript/assemblyscript

I'm looking forward to seeing some benchmarks comparing native binaries with the same program run via wasmer.

mkl3• 7 years ago

It says it runs compiled .wasm binaries, which should mean any language. I think the listed languages are those targeted for interoperability.

syrusakbary2• 7 years ago

That's right.

Wasmer executes any wasm binary, including AssemblyScript generated ones :)

maxgraey2• 7 years ago

Guys from NEAR Protocol using AssemblyScript and Wasmer together in production

yami• 7 years ago

Amazing! It's like we could write once and run everywaaaait a moment...

bryanrasmussen• 7 years ago

yeah but Windows support is highly experimental - hmm, wonder why.

oblio• 7 years ago

Tech is rarely about tech (same as for most things in life: X is rarely about X). It's about money and power/control.

Java was proprietary for a long time and even now it's basically controlled by Oracle.

Also, due to various issues, it doesn't really run on Android and it doesn't run at all on iOS (I know about Codename One, I mean the OpenJDK).

WASM is a truly open standard. And it's quite likely to be present on all platforms, even though for obvious reasons platform vendors will drag their feet regarding WASM.

aaaaaaaaaaab3• 7 years ago

WASM is a truly open standard

I guess in practice this means "open" like HTTP and HTML, for which Google decides what does/doesn't go into the standard.

sacado22• 7 years ago

But now you can choose your own programming language. The JVM is very Java centric, for obvious reasons.

pjmlp22• 7 years ago

Just like the CLR and LLVM.

kuschku• 7 years ago

You mean, like with TruffleRuby and JRuby, and TrufflePython and Jython, which both already run faster on the JVM than their "native" implementations of Ruby and Python do otherwise?

shellac• 7 years ago

Obviously its purpose was to support Java, but a number of languages - most prominently Scala, Kotlin, Clojure, Groovy and Ruby - run on the JVM. With perhaps the exception of Kotlin, these are not especially Java-like.

There is an interesting degree of independence. A lot of Java semantics is not baked into the JVM, and in the case of invokedynamic there was for a time a significant JVM feature that java didn't use.

The JVM is a pretty decent target for languages with garbage collection, objects (of some form), and methods / functions. Those facilities are useful for most languages these days, and provide a large degree of interoperability. I don't have to really thing about ruby calling java and back again, no calling conventions or issues with garbage.

It will be interesting to see whether WASM will support those kinds of features.

aaaaaaaaaaab3• 7 years ago

Can’t wait to have popups on my desktop telling me to update my WASM runtime to the latest version!

marmaduke2• 7 years ago

And each app shipping its own copy

kozak• 7 years ago

Electron apps already do.

ndnxhs• 7 years ago

Browsers already auto update

mkl3• 7 years ago

Embedding in other applications seems useful - imagine using it as a general plugin system. It's a bit strange that security and sandboxing aren't mentioned; that seems like WASM's primary value proposition here.

pavlov• 7 years ago

Those plugins still need an API in some language to interface with the host. A natural choice would be JavaScript: it's the world's most popular programming language, relatively easy to embed, and runtimes are available in every operating system.

At that point, you don't need WASM separately — just execute JavaScript and allow plugin writers to embed WASM modules for high performance, just like browsers do.

mkl3• 7 years ago

Well, if you were doing that, I don't think you'd need wasmer. V8 alone would be enough. Wasmer seems like an attempt to get away from Javascript and interface more directly with WASM.

plq3• 7 years ago

This is one of the logical next steps towards mass WASM-adoption. Another was Cloudflare's Isolates [1].

There needs to be official OS support from vendors (MacOS, Windows and Linux distros) in order to avoid the stinking pile of non-shared shared library mess that is electron.

[1] https://blog.cloudflare.com/cloud-computing-without-containe...

manigandham• 7 years ago

Mass adoption in what way?

jacobush• 7 years ago

So, we are officially campaigning for Javascript as the default language for everything now? :-(

degurechaff• 7 years ago

WASM is not javascript

baq• 7 years ago

actually, the exact opposite

thefounder8• 7 years ago

This is supposed to kill javascript(hopefully)

syrusakbary2• 7 years ago

We are working towards that. There are two ABIs (sets of syscalls, such as read a file or opening a socket) that we believe would help to bring universality between platforms: * CloudABI * PWSIX

We wrote more about it here: https://medium.com/wasmer/webassembly-cloudabi-b573047fd0a9

plq3• 7 years ago

What about packaging & distribution? Unless I missed something, it's up to us to package & ship our app complete with assets.

I firmly believe that this project is incomplete without a standard like .war (Web ARchive, from the Java ecosystem).

Of course, you could just use what's out there eg. .app (macos) or .appimage (gnu/linux) but there has to be a well-defined and clearly endorsed way of distributing wasmer'd apps.

steveklabnik10• 7 years ago

Small nit, the product is Cloudflare Workers. https://workers.dev/

Isolates are a V8 feature that is used to implement Workers: https://v8docs.nodesource.com/node-0.8/d5/dda/classv8_1_1_is...

titanix2• 7 years ago

Build Once, Run Anywhere.

Build once, run where the runtime in available.

ubercow13• 7 years ago

Kind of like Java

thefounder8• 7 years ago

Java is slow(to start) and memory hungry. That's why it failed so badly. Compare that with JavaScript/Electron.

sagartewari01• 7 years ago

*Build once, run almost Anywhere

krapp5• 7 years ago

Build once, run where the runtime in available.

To be fair, that's true of everything. We only take for granted that some runtimes are more common than others.

The only reason the web is a "universal" runtime is that browser vendors ship to every conceivable platform and more or less agree on standards.

adrianN• 7 years ago

This talk was really prophetic https://www.destroyallsoftware.com/talks/the-birth-and-death...

ForHackernews• 7 years ago

the text format defined by the WebAssembly reference interpreter (.wat)

https://www.destroyallsoftware.com/talks/wat

maliker• 7 years ago

I like to share this talk with new junior devs instead of ranting about strangely defined behavior in javascript. Saves time, and it's more fun.

IshKebab• 7 years ago

Maybe prophetic in the sense of "people really wanted this for years and it has finally been implemented". People have been talking about it since at least when NaCl debuted in 2011.

dijit• 7 years ago

“If I had asked people what they wanted, they would have said faster horses.” - Henry Ford

JavaScript by itself is not a “nice” language, I would ask what the root of your request is: an easy garbage collected language that is ubiquitous?

aaaaaaaaaaab3• 7 years ago

If by "people" you mean "a vocal minority", then sure.

ahupp• 7 years ago

A lot longer than that. There was a standard calls ANDF in 1989 (architecture neutral distribution format) trying to solve the same problem. I'm curious why it didn't work out, but I imagine part of the problem was that it had to support both many different flavors of Unix as well as cpu arch.

https://en.wikipedia.org/wiki/Architecture_Neutral_Distribut...

chubot• 7 years ago

It looks like that talk is from 2014. Ideas like that had been talked about for many years -- that is, moving all of computing to the browser.

July 2007:

Atwood's Law: any application that can be written in JavaScript, will eventually be written in JavaScript.

https://blog.codinghorror.com/the-principle-of-least-power/

JSLinux by Fabrice Bellard in 2011:

https://bellard.org/jslinux/

As far as I remember, the addition of Typed arrays to JavaScript made this feasible.

In typical Bellard fashion, he didn't really talk about it -- he just demonstrated it!

kgraves• 7 years ago

Fantastic! This makes me extremely excited about WASM! (Bonus points for Rust)

hypfer2• 7 years ago

Its literally Java all over again.

Don't. Just. Don't.

guiriduro• 7 years ago

The JVM, the .Net CLR: mature, stable, secure - why do we need another alpha-level VM thing that was devised to make Javascript faster that can awkwardly run slow(er than native) bytecode? How is that progress?

johncolanduoni2• 7 years ago

Because it’s not “devised to make JavaScript faster”. WASM is first and foremost designed as a compilation target for languages that work with a simple linear memory and don’t use a garbage collector, like C/C++/Rust (extensions to interact directly with the JavaScript GC are in progress, but quite a ways off). The progress it enables is the ability to run performance sensitive code written in these languages in a software-sandboxed environment at anywhere near native speed, as opposed to multiple times slower.

Also neither the JVM nor the CLR even seriously attempt to offer the security when executing untrusted code that WASM does. WASM has been deployed for over a year in all the major browsers, making vulnerabilities in its implementations very valuable. Yet we haven’t seen some huge explosion of CVEs due to its addition, unlike the early history of the JVM and CLR’s attempts to implement robust software sandboxes (before they both threw up their hands and stopped trying to market their sandboxing features as suitable for running untrusted code).

FridgeSeal5• 7 years ago

Because it’s not another shitty language runtime like JVM or CLR, it’s a machine-code level target.

You can take your Java/Rust/.Net/Haskell/etc/etc apps and compile them down to WASM, much like you would if you were using LLVM to compile down to assembly.

lazyjones3• 7 years ago

Or p-code. This is my knee-jerk reaction too, can't wait till someone implements a portable browser in wasm like it's 1997. If someone actually builds a working and useful portable OS and UI layer around wasm, I might stop joking about it.

CyberDildonics2• 7 years ago

Most people don't have a p-code or java interpreter on their computer already, but 80% can already use webasm.

https://caniuse.com/#feat=wasm

rkangel3• 7 years ago

Why not? A single cross-platform compilation target seems like a great idea.

Java got caught up with some proprietary stuff thanks to Oracle, but there's a useful goal there. In the same way that the web is a useful target for cross-platform UI applications.

pjmlp22• 7 years ago

As if under Sun it was all flowers and such.

Hywan• 7 years ago

No, it's not :-), see https://words.steveklabnik.com/is-webassembly-the-return-of-...

hypfer2• 7 years ago

So he's basically stating that Wasm is better at doing what Java/Shockwave/Flash did. Thats most likely correct but also beside the point. The concept of "That one Layer which enables Cross-Platform applications" is just something which has failed, does fail and will fail in the future. Idc if its better at being Java since its still trying to be java.

int_19h10• 7 years ago

It's literally not. You can't compile C into efficient JVM bytecode, but you can with WASM.

pjmlp22• 7 years ago

Graal project has other point of view.

https://github.com/oracle/graal/tree/master/sulong

richardwhiuk2• 7 years ago

What problem is this possibly solving? Why wouldn't you just compile your Rust/Go to a native binary?

thefounder8• 7 years ago

A portable binary like wasm makes deployment easier and potentially makes it more secure/easier to sandbox.

richardwhiuk2• 7 years ago

Makes deployment harder surely? Now you need to both ship the wasm runner and the compiled code of the executable?

rkangel3• 7 years ago

You can, if you've written it in Rust/Go. If you write in a another language, then you don't have to have a compiler (or VM) that supports multiple platforms, you just compile to WASM, and this would sort it out.

vkaku2• 7 years ago

Except the Web part, it looks good. The portable object that nobody agreed upon now happens to be a eloquent JS representation Sigh

ZenPsycho• 7 years ago

that isn’t what wasm is.

vkaku2• 7 years ago

I remember running good old text WebAssembly about 7 years ago, which is admittedly cool - I was even waiting for Chrome to support it before I gave up on that. I remember how people had to ship a gzip-ed Unreal engine on the web for the first version;

My quip is how the C++ community miserably failed to ship a portable object that could have been used for module based compilation / linking without the AST generation overhead.

Unless wasm really becomes the package/intermediate standard for code, I wouldn't really regard it as useful yet. It would be another Java for me.

pjmlp22• 7 years ago

Ah, Pascal UCSD!

seanwilson• 7 years ago

Why is this post generating so many low effort joke comments? Is the project idea really that bad or are people missing the point?

It's sad to see people wailing on a project that (I'm assuming) people have put a lot of time into without trying to understand what it is and what it isn't.

kowdermeister• 7 years ago

I think because it's very easy to see it as something familiar. People are always skeptical about new stuff plus that familiar thing was shit so this must be shit too.

So no critical thinking leads to lame jokes and "OMG NO JAVA" style comments.

arendtio• 7 years ago

Well, the concept is arguably very close to what Java was marketed for. So I think it is quite natural to respond with some kind of Java association.

Nevertheless, I think this is a very interesting project.

willvarfar• 7 years ago

What's the strategy with dealing with 32-bit vs 64-bit machines?

Historic attempts at using LLVM IR as a universal binary have stumbled on that issue, and typically have ended up deciding to support the lowest-common-denominator machines i.e. 32-bit, meaning that it hasn't been viable to use them for server-style software.

maxmcd• 7 years ago

Wasm is split between wasm32 and wasm64 they are separate https://github.com/WebAssembly/design/blob/master/FutureFeat...

So yes, we're at the lowest common denominator for addressing memory. You would need to explicitly build for wasm64 in the future.

Within wasmer wasm is compiled into a different IR through cranelift. That generally compiles for 64 bit systems but can compile to 32: https://github.com/CraneStation/wasmtime/pull/44

Not sure if this entirely answers your question. Seems like there are still a handful for decisions wasmer would need to make in terms of what exactly is supported.

tambourine_man• 7 years ago

Is anyone working on something like a POSIX layer on top of it? And maybe, someday, a GUI? We have universal binaries now, but what APIs will we call?

kostaw• 7 years ago

For those thinking that this is just Java and Flash all over again: Here's the relevant blog post from Steve Klabnik explaining why this is _very_ different:

https://words.steveklabnik.com/is-webassembly-the-return-of-...

acqq• 7 years ago

The post is not about this implementation (the link of the original post) though. This implementation is not about the browsers.

userbinator• 7 years ago

There’s another reason Wasm succeeded: it’s tiny.

I'll agree with him that Java is very much not tiny, but I disagree about Flash. The last time I remember setting it up, the browser plugin was a single binary of a few MB (and I'm sure that could be made smaller.) SWF files are also a great example of a well-designed space-optimised vector graphics format --- remember that it was designed close to 20 years ago for the computers of the time.

Edit: care to explain, downvoters?

afiori11• 7 years ago

But flash was not an option for similar purposes because of its terrible security.

vorpalhex• 7 years ago

Flash runtime was several hundreds MBs. Sure the actual applets were a few mb of mostly animations and resources, but the runtime was another thing.

icedchai• 7 years ago

20 years ago, indeed, Java wasn't tiny. That was on "high end" desktop computers with roughly 64 to 128 megs of RAM. Today, in the days of browsers taking up gigabytes of memory, it's hardly a concern. That applet JVM would start lightning fast.

leshow• 7 years ago

pepperflash plugin, the flash runtime that chrome includes, is about 20mb.

hackcasual2• 7 years ago

It's not tiny in the sense of file size, it's tiny in the sense of scope. It doesn't even have a standard library, let alone offer everything flash and Java did. At it's heart it's just a compact, efficient representation of a subset of JavaScript

kitd• 7 years ago

I'm not wholly convinced.

I'm quite happy that Wasm is a great step forward, but I think that is more by accident of history. Javascript was already in the browser so JS/Wasm was low-hanging fruit. Using it to claim "Wasm succeeded" is premature.

repolfx• 7 years ago

That is a weird, unconvincing post.

His first point about why it's different is "Wasm won"? Really? Back in the day Java applets were everywhere. They had "won". They disappeared because browser makers kicked them out along with Flash, which had also "won". He then tries to redefine plugins, which were created by Netscape, had a standard cross platform API and their own HTML tags as somehow "not a part of the web platform".

Then he says that's "in some senses the final point", as if being forced into the platform by de-facto execution of all competitors says all you need to know about why WebAssembly is good.

But still, he does go on to make other points too. Firstly he picks up on loading screens, presumably claiming WebAssembly doesn't have loading screens. Well, no, the web platform makes you implement your own. But the reason apps like Gmail have loading screens is because it's waiting whilst the browser downloads, parses and initialises megabytes of JavaScript and WASM (maybe, assuming Gmail uses some). To the extent it's faster it's only because hardware is faster, not due to any fundamental difference in technology. Not having a standardised splash doesn't seem like an actual win.

He then goes on to argue:

These platforms never gained the ability to interact with the rest of the platform provided by your browser. Well, technically they might have, but that’s not how these technologies were used in practice.

So he makes a false claim - that applets and flash couldn't interact with the hosting web page - and then immediately admits it's false, but that "this isn't how the tech was used in practice". But I remember quite a few Java and Flash applets that interacted with the host page and changed the HTML, most obviously in things like the original Google Talk. And to the extent Java applets rarely did, that's because HTML sucked in that era. Arguably it still does. The primary reason people were writing Java applets was to escape the woeful inadequacy of the web platform, so no big surprise not many applets rendered their UI using "the benefits of HTML and CSS".

And users ended up solidly rejecting it. Outside of games, users hated Flash. Java Applets were heavy and slow.

Users didn't reject Flash. Flash went everywhere. It was the de-facto video streaming solution, the de-facto cross platform lightweight games solution, it was in every Gmail page, it was the standard way to make attractive animated websites. Site authors adopted it en-masse and users loved those sites, which were often doing things HTML users couldn't even begin to do.

And of course Java applets were "heavy and slow" in an era when the web itself was so heavy and slow, that people didn't even try to do the same things with it. The crime of Java applets was mostly that they raised developer expectations to unreasonable levels and devs ended up blowing their hardware budgets. The web was crippled and limited, so people didn't even try to make sophisticated UIs or modular software, and it ended up staying within the envelope of what slow internet connections could manage more effectively.

WebAssembly, on the other hand, is much closer to JavaScript. It doesn’t inherently require taking over a part of your screen. It doesn’t expect to be its own little closed off world. Via JavaScript today, and on its own in the future, it’s able to interact with the surrounding environment. It just… fits.

Here he's just repeating an argument he already admitted himself is wrong. Flash applets and Java applets could both be invisible and could both "fit" with the surrounding environment. And he already knows that.

I have to admit I stopped reading at this point. WebAssembly is a poor re-implementation of the JVM, 20+ years later, and its primary selling point is that browser makers control it so they are forcing people to use it in the same way they did for JavaScript. The advocates for it know their own comparisons with prior tech are bogus but make them anyway. It's depressing to see.

jokoon• 7 years ago

Any real, simple c++ toolchain compiling directly to .WASM?

Emscripten is not really user friendly.

Time is passing, WASM is here but I can't see decent toolchains available to work with it.

flohofwoe2• 7 years ago

Depends on how you define "user friendly". IMHO emscripten does what a gcc-compatible C/C++ toolchain is supposed to do:

emcc hello.c -o hello.html

...which gives you a complete WebAssembly application runnable in the browser.

With VSCode as IDE it's possible to build a fairly nice edit-compile-test workflow with Intellisense and error squiggles.

BUT:

What's really missing is proper debugging support (can mostly be worked around by debugging a platform-native executable compiled from the same source, but working source-level debugging for WASM blobs would be nice).

pjmlp22• 7 years ago

Yes, cheerp

https://www.leaningtech.com/cheerp/

steveklabnik10• 7 years ago

Cheerp and emscripten are the only two choices for C++, as far as I know.

That said, the Rust team has been putting a ton of work into a real, simple toolchain for exactly these reasons: tools matter for adoption. We'll see if the pain of the toolchain is less or greater than the pain of a different language...

appcypher• 7 years ago

You can use the LLVM toolchain directly if you know your way around it. I believe the GCC folks were working on a wasm target a while ago but I don't know the ETA for that.

If you are looking for an easy setup of LLVM's own wasm-target (which Emscripten will be switching to eventually), try this tool: https://github.com/appcypher/wasabi

bluejekyll2• 7 years ago

Ok, strawman using Rust (pick your favorite WASM capable language): I write in Rust, that is alreasdy a decently portable language. Most likely WASM will be on many of the platforms the LLVM allows Rust to target. Most Rust libs are cross platform capable (Linux, macOS, Windows, etc).

Now, when I target WASM I get one obvious thing, compile once deliver everywhere, with some overhead hit. Versus produce binaries for everything and distribute.

Is gaining the universal binary (with WASM runtime) enough? The reason I’m excited about the Web target for WASM is that I gain the entire web platform from my favorite language.

I’m 50% excited and also baffled by this. Now, as an embeddable language runtime in other software, that’s interesting...

steveklabnik10• 7 years ago

Maybe, maybe not, in this specific scenario.

But it's not the only scenario. Imagine, for a moment, that you're not distributing your own binaries; you're in the business of running them, possibly from untrusted sources. And that's just one other scenario.

bluejekyll2• 7 years ago

So the Cloudflare perspective. Yes, it’s interesting.

youareawesome6• 7 years ago

This project has been known to copy code from other projects without respecting licenses. The founder of ethereum pointed this out a few weeks ago.

https://twitter.com/gavofyork/status/1094597005333151745 https://twitter.com/Sunfishcode/status/1075486397824327681

The extent to which the people in this project took "inspiration" from wasmjit has been questioned as well https://github.com/wasmerio/wasmer/commit/a81500e047fdd321b3...

justinclift2• 7 years ago

Looks like they made a mistake, apologised, and have added attribution since?

youareawesome6• 7 years ago

When they were called out privately, no mistake was admitted and no action was taken. The attribution was only added after they were called out publicly.

lachlan-sneff• 7 years ago

Hi, thanks for bringing this to our attention!

We think we've resolved this issue here (https://twitter.com/syrusakbary/status/1094635228457426944), but our response was definitely later than it should have been. If you feel that we need to rectify further, feel free to email me at lachlan@wasmer.io.

jayd163• 7 years ago

This is neat but it has me thinking. Is there a similar project that allows linking wasm libraries into your LLVM language of choice? Seems like that could allow for shared libraries across languages. The lib would take some perf hit but your core project perf could be unaffected.

stcredzero3• 7 years ago

We should bring back a platform like TAOS.

The TAOS operating system (1991) had a virtual Instruction Set Architecture (ISA). Except for a small kernel, the entire OS was compiled to the virtual ISA, then assembled into actual machine code Just In Time as fast as the executable was being read off disk.

This resulted in an operating system that could run with decent speeds (80-90% of native) on seemingly any hardware, which could be ported to a new platform in just 3 days.

https://news.ycombinator.com/item?id=9806607

runeks• 7 years ago

How is this different from compiling Linux from C to LLVM to native code?

And why would I ever want to generate native code for an OS at runtime?

pjmlp22• 7 years ago

Not necessarily at runtime.

OS/360 (IBM z nowadays) and OS/400 (IBM i nowadays) work kind of this way.

The whole userspace is based on binaries deployed in a bytecode format.

They are than AOT compiled into native code at installation time, or anything there are system relevant changes, via a kernel JIT service.

Whole mainframe hardware migrations are possible without changing a single thing on the userspace, just doing a system refresh.

stcredzero3• 7 years ago

And why would I ever want to generate native code for an OS at runtime?

Why? To get write once, run everywhere. If you can do the generation at the speed the data comes off the disk, you're paying nothing for the feature.

If you do things right, the abstract memory model can even be bit-identical. Even though there are differences in the underlying hardware, like endianess, all of the virtual ISAs can still implement the same virtual memory model. Smalltalk also does this, and it absolutely works across 100's of combinations of ISA and OS.

pm215• 7 years ago

Speaking as somebody who actually ported it (or at least the second-generation "intent/elate") to new platforms, it took more than three days (though you could probably get to "hello world" in three days or so if you were in a hurry and you only needed to handle new hardware or a new host OS, not a whole new CPU architecture).

skybrian• 7 years ago

The hard part will be coming up with portable API's that can do the things that native apps can do.

Consider that browser standards include an enormous amount of functionality and new web API's are getting added all the time, and yet, many people claim that web apps can't compete with native apps on phones or desktop. Also, even if you just pick one of these, there have been many attempts to come up with a portable way to write apps for both iOS and Android, and it's getting better (see Flutter for example), but it's still a lot of work for the implementers.

Docker got around this by standardizing on Linux (including the filesystem), but the client side is much harder.

So I suspect that for a "universal" file format based on WebAssembly to get anywhere, it will have to succeed in some niche not served well by web browsers, Docker, or Unity.

WebAssembly itself is useful in the way a fast interpreter for a scripting language is useful - as an embedded component of some larger runtime. Its potential customers are teams that would otherwise need a scripting language and choose WebAssembly instead.

flohofwoe2• 7 years ago

One realistic use case that comes to mind for WebAssembly modules outside the browser is extension plugins for tools like Maya, 3DSMax or Photoshop. For such cases it's usually ok to provide a restricted set of APIs, but you gain binary compatibility across platforms and performance that's much better than (for instance) Python or Lua scripting.

int_19h10• 7 years ago

On the bright side - since this is a brand new thing built from bottom up, we're not limited by past API design choices.

In particular, I hope that this time we can get a standardized ABI that goes well above what C (the current de facto standard) had to offer. Language evolution went far beyond where things were back in 1980s, and the set of common features across various languages has also increased substantially - and that should be reflected in the ABI.

Speaking of which: https://github.com/Microsoft/xlang

decafbad• 7 years ago

I'm guessing that's the point everyone should see. WASM is going to be the new bytecode that works everywhere. If that's not the reason of even Golang started to support Webassembly, I would love to hear your your conjecture.

dmitrygr• 7 years ago

  > curl https://get.wasmer.io -sSfL | sh

Why do people still do this? What happens when owner of the domain forgets to renew it and someone else buys it, and puts up a copy of this site, with the binary replaced? Or if the owner sells it to someone malicious who does that? Or someone messes with your DNS server to serve that?

Please please please never do this.

Oh, and SERIOUSLY question the ability of anyone who suggests doing this to at all reason in a secure fashion.

kevin_b_er• 7 years ago

http://troubles.md/posts/wasm-is-not-a-stack-machine/ wasm is already tainted by the legacy of javascript. It was intended as a replacement for asm.js and carries the burden of being too intended to be with javascript and as a way to get "faster javascript" due to how poor javascript is at executing efficiently.

The result is what I'd consider a poor mans java bytecode. The legacy of java was bloat connected to the runtime and its massive standard library coupled with nasty Sun then Oracle burden. And Oracle again being Oracle with what feels like more more lawyers than engineers to threaten.

So we tossed out a standard library and made a poor man's java virtual machine model.

This is java again, it just has massive hype because its better than javascript at actually running efficiently. But it can still be worse than any given other virtual machines out there.

klunger• 7 years ago

If you are having trouble wrapping your head around WASM (it is a bit funny -- almost but not quite analogous to several more familiar paradigms), I highly recommend this series of posts: https://hacks.mozilla.org/category/code-cartoons/a-cartoon-i...

unnouinceput• 7 years ago

So ActiveX / Java applets, then Flash and now this. Yeah just another fad. It will pass, and next generation of developers will think something else to make the "holy grail" that is cross-platform everywhere with native speed. And so on and so forth.

Universal Binaries Using WASM

Related Stories