19 ms·

Universal Binaries Using WASM

335 points by grey-area 8y ago

deleted 8y ago
[deleted]
spease 8y ago
Very impressive. Is this compatible with any WASM-compliant language, or just the ones listed? EG AssemblyScript: https://github.com/AssemblyScript/assemblyscript https://github.com/AssemblyScript/assemblyscript I'm looking forward to seeing some benchmarks comparing native binaries with the same program run via wasmer.
- mkl 8y ago
  It says it runs compiled .wasm binaries, which should mean any language. I think the listed languages are those targeted for interoperability.
  - syrusakbary 8y ago
    That's right. Wasmer executes any wasm binary, including AssemblyScript generated ones :)
- maxgraey 8y ago
  Guys from NEAR Protocol using AssemblyScript and Wasmer together in production
yami 8y ago
Amazing! It's like we could write once and run everywaaaait a moment...
- bryanrasmussen 8y ago
  yeah but Windows support is highly experimental - hmm, wonder why.
- oblio 8y 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.
  - aaaaaaaaaaab 8y 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.
    - deleted 8y ago
      [deleted]
    - moocowtruck 8y ago
      precisely what I was thinking...they have their hands in all these standards and most times seem to push the direction. But I will say this.. I'd rather them work on these "open" standards, then go ahead and keep to their own.. so i guess gotta take some bad with the good
    - rcxdude 8y ago
      WASM has been developed mostly outside of google (mozilla mainly) and is actually counter to a lot of the attempts google made to get similar features (e.g. NaCl). It's quite hard to claim google has had undue influence on its development.
- sacado2 8y ago
  But now you can choose your own programming language. The JVM is very Java centric, for obvious reasons.
  - pjmlp 8y ago
    Just like the CLR and LLVM.
    - sacado2 8y ago
      I've never been very fond of CLR outside of Windows platforms. As for LLVM, sandboxing has never been a core feature (AFAIK).
      - pjmlp 8y ago
        It was called PNaCl. WebAssembly only exists because Mozilla went with asm.js instead.
  - kuschku 8y 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 8y 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.
aaaaaaaaaaab 8y ago
Can’t wait to have popups on my desktop telling me to update my WASM runtime to the latest version!
- marmaduke 8y ago
  And each app shipping its own copy
  - kozak 8y ago
    Electron apps already do.
    - avichalp 8y ago
      So, with this you can make `main process` in electron, obsolete?
    - marmaduke 8y ago
      Indeed my comment was a variant on the electron meme to this effect
- ndnxhs 8y ago
  Browsers already auto update
mkl 8y 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 8y 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.
  - mkl 8y 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.
plq 8y 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-containers/ https://blog.cloudflare.com/cloud-computing-without-containe...
- manigandham 8y ago
  Mass adoption in what way?
- jacobush 8y ago
  So, we are officially campaigning for Javascript as the default language for everything now? :-(
  - degurechaff 8y ago
    WASM is not javascript
    - AnIdiotOnTheNet 8y ago
      Funny, I hear often that "WASM is just javascript" whenever I compare it to Flash and Java, as a defense for why it is different this time and totally won't have any of the problems of those other runtimes.
      - afiori 8y ago
        Because wasm runs on the same javascript and not as a separate plugin. It will be a major feature of the browser and be automatically updated with it. (also it allows for feature discovery) It has no relation to ecmascript, but you could say that it is integrated in (but independent from) javascript. People say that it is not javascript because you can use ALL of the wasm toolchain without any trace of javascript.
      - CyberDildonics 8y ago
titanix2 8y ago
> Build Once, Run Anywhere. Build once, run where the runtime in available.
- ubercow13 8y ago
  Kind of like Java
  - thefounder 8y ago
    Java is slow(to start) and memory hungry. That's why it failed so badly. Compare that with JavaScript/Electron.
    - protomyth 8y ago
      Please explain how Java “failed so badly”?
      - thefounder 8y ago
        It failed so badly "on the web/in browser".
    - krapp 8y ago
      >Compare that with JavaScript/Electron. Electron is heavier and even more memory hungry.
      - StavrosK 8y ago
        I don't know what the GP was thinking. Hopefully exactly that.
    - fetbaffe 8y ago
      Build once, eat memory anywhere.
- sagartewari01 8y ago
  *Build once, run almost Anywhere
pjmlp 8y ago
Ah, Pascal UCSD!
adrianN 8y ago
This talk was really prophetic https://www.destroyallsoftware.com/talks/the-birth-and-death-of-javascript https://www.destroyallsoftware.com/talks/the-birth-and-death...
- ForHackernews 8y ago
  > the text format defined by the WebAssembly reference interpreter (.wat) https://www.destroyallsoftware.com/talks/wat https://www.destroyallsoftware.com/talks/wat
  - maliker 8y 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 8y 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 8y 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?
    - AsyncAwait 8y ago
      > I would ask what the root of your request is: an easy garbage collected language that is ubiquitous? Honestly, I just want to be able to write the stuff I have to in JS today in my favorite language.
    - derefr 8y ago
      This "long-held fervor" that culminated in WASM started back before Node.js existed, so back then, "Javascript" was just a thing browsers did (except for, say, Windows Scripting Host's support of it.) The fervor back then wasn't really driven by a desire for a ubiquitous anything; it was driven specifically by people thinking about browsers, and what is required to program web-apps in browsers. What people have wished for, since... oh, 2001 or so, is the ability to write web-app frontends without needing to grok and deal with the awful runtime semantics of Javascript—the way you do when you write Javascript, yes, but also the way you do when you write in a language that directly transpiles to Javascript, like TypeScript or ClojureScript. Languages like TypeScript may add semantics on top of the JS runtime's semantics, but they can't get away from the fact that the JS runtime is the "abstract machine" they program, any more than e.g. Clojure can get away from the fact that the JVM is the abstract machine it programs. That's why none of these languages were ever seen as a "saving grace" from the "problem of Javascript", the way WASM is. WASM has its own abstract machine (which runs efficiently in browsers), which finally frees people from the tyranny of the Javascript-runtime-as-abstract-machine. It's great that it's also now replacing the Javascript-runtime-abstract-machine in other contexts (e.g. Node-like server-side usage, plain-V8-like embedded usage) but that was never really "the thing" that anyone cared about. --- Mind you, the NaCl fervor was for a ubiquitous VM—but the NaCl fervor wasn't nearly as large, and isn't really what's propelling WASM to prominence right now. Even then, it wasn't about "an easy garbage collected language that is ubiquitous", no. The goal of it was to be able to take code that you already have—native code, written to run fast, like a AAA game—and put it in a browser-strength sandbox, such that it can be zero-installed just by visiting a URL, with full performance. You know, like ActiveX was supposed to be. But better. NaCl didn't really get us there, because it happened right as the architectural split between x86 and ARM really started heating up, and NaCl's solution to that split—PNaCl, a.k.a. sandboxed LLVM IR—was both too late and not really efficient-enough at the time to fully supplant the "Native" NaCl in NaCl messaging. (LLVM IR works well-enough now for Apple to rely on it for being a "unified intermediate" of both x86 and ARM target object code, but that shift only began with ~8 additional years of LLVM development after the version of LLVM that PNaCl's IR came from.) WASM seems to get us there. But do we care any more? Everyone already has other solutions to this problem. ChromeOS can run Android apps; Ubuntu Snappy packages can expose GUIs to Wayland; Windows has a Linux ABI to run Docker containers. Ubiquity is a lot easier now than it was back then, for any particular use-case you might want. On the embedded-scripting side of things, everyone has seemingly settled on embedding LuaJIT or V8. Do people even need embedded scripts to be fast, in a way that "WASM as compilation target" would help with? Maybe for the more esoteric use-cases like CouchDB's "design documents" or the Ethereum VM (https://medium.com/coinmonks/ewasm-web-assembly-for-ethereum-54719ece2042. https://medium.com/coinmonks/ewasm-web-assembly-for-ethereum...) But I doubt WASM will hit ubiquity here. Why would OpenResty switch? Why would Redis? Etc. You're not writing-and-compiling native code for any of these in the first place, so adding WASM here would only break existing workflows.
kgraves 8y ago
Fantastic! This makes me extremely excited about WASM! (Bonus points for Rust)
hypfer 8y ago
Its literally Java all over again. Don't. Just. Don't.
- guiriduro 8y 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?
  - johncolanduoni 8y 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).
    - lazyjones 8y ago
      > 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). Is this a fair comparison? JVM and CLR allow general purpose programming and syscalls across several platforms. What can you do with WASM today? Only whatever is allowed by browsers.
      - 8y ago
richardwhiuk 8y ago
What problem is this possibly solving? Why wouldn't you just compile your Rust/Go to a native binary?
- thefounder 8y ago
  A portable binary like wasm makes deployment easier and potentially makes it more secure/easier to sandbox.
  - richardwhiuk 8y ago
    Makes deployment harder surely? Now you need to both ship the wasm runner and the compiled code of the executable?
    - amelius 8y ago
      You can still ship your native code. So you have two options instead of one.
    - thefounder 8y ago
      The host is supposed to support wasm and most hosts will do.
      - mr_toad 8y ago
        With about 50% of corporate desktops still using Windows 7 with IE11 as the default browser - it’s going to take a while before wasm is truely ubiquitous.
        maxgraey 8y ago
        That's not true: https://bit.ly/2GMbAN3 https://bit.ly/2GMbAN3
    - int_19h 8y ago
      Projects like this one are the first step towards native wasm support on OS level across major platforms. It'll happen, the only question is how soon.
vkaku 8y 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 8y ago
  that isn’t what wasm is.
  - vkaku 8y 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.
seanwilson 8y 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 8y 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 8y 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.
    - afiori 8y ago
      It is close in the wording but very different in almost every other sense. wasm pushes for many indipendent implementation, it is meant to be very minimal and importantly it is made to be embeddable. In a sense it is closer to lua than Java.
      - runako 8y ago
        At the risk of jumping into this, Java was intended to be small (small enough to run on processors that were below PC-class in the 1990s) and embeddable. https://www.javaworld.com/article/2073700/mobile-java/mobile-java-java-everywhere-is-for-world-domination.html https://www.javaworld.com/article/2073700/mobile-java/mobile... The idea of Java running on devices goes back AFAICR to the very beginning of the language. I remember the "Java everywhere" slogan and initiatives to put Java into every device. Java Card was a version of Java designed to run on smart cards. If memory serves, these were all design goals of the Java platform in the early 90s. (Remarkably, this was all well before Linux really took off, before the Internet was ubiquitous, and when the most sophisticated electronics most households owned was a VHS player.) https://en.wikipedia.org/wiki/Java_Card https://en.wikipedia.org/wiki/Java_Card
willvarfar 8y 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 8y ago
  Wasm is split between wasm32 and wasm64 they are separate https://github.com/WebAssembly/design/blob/master/FutureFeatures.md#linear-memory-bigger-than-4-gib 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 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 8y 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 8y 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-java-applets-flash https://words.steveklabnik.com/is-webassembly-the-return-of-...
- acqq 8y ago
  The post is not about this implementation (the link of the original post) though. This implementation is not about the browsers.
- userbinator 8y 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?
  - afiori 8y ago
    But flash was not an option for similar purposes because of its terrible security.
  - vorpalhex 8y 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.
    - deleted 8y ago
      [deleted]
    - aepiepaey 8y ago
      The runtime is ~15MB, far from hundreds of MBs.
jokoon 8y 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.
- flohofwoe 8y 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).
- pjmlp 8y ago
  Yes, cheerp https://www.leaningtech.com/cheerp/ https://www.leaningtech.com/cheerp/
- steveklabnik 8y 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 8y 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 https://github.com/appcypher/wasabi
bluejekyll 8y 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...
- steveklabnik 8y 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.
  - bluejekyll 8y ago
    So the Cloudflare perspective. Yes, it’s interesting.
    - steveklabnik 8y ago
      Or the “script my application with wasm” perspective, or the “smart contracts for blockchain” perspective, yeah. Think “docker”, in some ways.
youareawesome 8y 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/gavofyork/status/1094597005333151745 https://twitter.com/Sunfishcode/status/1075486397824327681 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/a81500e047fdd321b3dd3f9fabb87fecbd2d7792#diff-9c2f6a65948817d0ab677942d577d2d0 https://github.com/wasmerio/wasmer/commit/a81500e047fdd321b3...
- justinclift 8y ago
  Looks like they made a mistake, apologised, and have added attribution since?
  - youareawesome 8y 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.
    - ozzmotik 8y ago
      a problem fixed under less ideal situations is still a fixed problem regardless.
      - youareawesome 8y ago
        Do you think they would they have fixed the problem if they weren't called out publicly?
        ozzmotik 8y ago
        i don't think it matters because they __did__ fix the problem. maybe that would have been a problem in the past before the problem became acknowledged, but the thing is, that isn't the case anymore and so to me it really doesn't matter. but even if it did matter, i still probably wouldn't care. sometimes people need convincing to do a thing and when it comes to presenting a consistent and positive image to others, i think it's quite a generally good thing if someone is responsive to the criticism of others and actually acts on it. maybe they should have fixed it before of their own accord. but maybe before they didn't see the issue that others saw. people aren't perfect any they make mistakes. constantly.
jayd16 8y 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.
stcredzero 8y 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 https://news.ycombinator.com/item?id=9806607
- runeks 8y 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?
  - pjmlp 8y 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.
  - stcredzero 8y 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 8y 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 8y 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.
- flohofwoe 8y 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_19h 8y 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 https://github.com/Microsoft/xlang
decafbad 8y 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 8y 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 8y ago
http://troubles.md/posts/wasm-is-not-a-stack-machine/ 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 8y 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-intro-to-webassembly/ https://hacks.mozilla.org/category/code-cartoons/a-cartoon-i...
unnouinceput 8y 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.

335 points by grey-area 8y ago

deleted 8y ago

[deleted]

Very impressive. Is this compatible with any WASM-compliant language, or just the ones listed? EG AssemblyScript: https://github.com/AssemblyScript/assemblyscript https://github.com/AssemblyScript/assemblyscript I'm looking forward to seeing some benchmarks comparing native binaries with the same program run via wasmer.

mkl 8y ago
It says it runs compiled .wasm binaries, which should mean any language. I think the listed languages are those targeted for interoperability.
- syrusakbary 8y ago
  That's right. Wasmer executes any wasm binary, including AssemblyScript generated ones :)
maxgraey 8y ago
Guys from NEAR Protocol using AssemblyScript and Wasmer together in production

yami 8y ago

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

bryanrasmussen 8y ago
yeah but Windows support is highly experimental - hmm, wonder why.
oblio 8y 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.
- aaaaaaaaaaab 8y 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.
  - deleted 8y ago
    [deleted]
  - moocowtruck 8y ago
    precisely what I was thinking...they have their hands in all these standards and most times seem to push the direction. But I will say this.. I'd rather them work on these "open" standards, then go ahead and keep to their own.. so i guess gotta take some bad with the good
  - rcxdude 8y ago
    WASM has been developed mostly outside of google (mozilla mainly) and is actually counter to a lot of the attempts google made to get similar features (e.g. NaCl). It's quite hard to claim google has had undue influence on its development.
sacado2 8y ago
But now you can choose your own programming language. The JVM is very Java centric, for obvious reasons.
- pjmlp 8y ago
  Just like the CLR and LLVM.
  - sacado2 8y ago
    I've never been very fond of CLR outside of Windows platforms. As for LLVM, sandboxing has never been a core feature (AFAIK).
    - pjmlp 8y ago
      It was called PNaCl. WebAssembly only exists because Mozilla went with asm.js instead.
- kuschku 8y 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 8y 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.

aaaaaaaaaaab 8y ago

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

marmaduke 8y ago
And each app shipping its own copy
- kozak 8y ago
  Electron apps already do.
  - avichalp 8y ago
    So, with this you can make `main process` in electron, obsolete?
  - marmaduke 8y ago
    Indeed my comment was a variant on the electron meme to this effect
ndnxhs 8y ago
Browsers already auto update

mkl 8y 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 8y 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.
- mkl 8y 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.

plq 8y 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-containers/ https://blog.cloudflare.com/cloud-computing-without-containe...

manigandham 8y ago
Mass adoption in what way?
jacobush 8y ago
So, we are officially campaigning for Javascript as the default language for everything now? :-(
- degurechaff 8y ago
  WASM is not javascript
  - AnIdiotOnTheNet 8y ago
    Funny, I hear often that "WASM is just javascript" whenever I compare it to Flash and Java, as a defense for why it is different this time and totally won't have any of the problems of those other runtimes.
    - afiori 8y ago
      Because wasm runs on the same javascript and not as a separate plugin. It will be a major feature of the browser and be automatically updated with it. (also it allows for feature discovery) It has no relation to ecmascript, but you could say that it is integrated in (but independent from) javascript. People say that it is not javascript because you can use ALL of the wasm toolchain without any trace of javascript.
    - CyberDildonics 8y ago

titanix2 8y ago

> Build Once, Run Anywhere. Build once, run where the runtime in available.

ubercow13 8y ago
Kind of like Java
- thefounder 8y ago
  Java is slow(to start) and memory hungry. That's why it failed so badly. Compare that with JavaScript/Electron.
  - protomyth 8y ago
    Please explain how Java “failed so badly”?
    - thefounder 8y ago
      It failed so badly "on the web/in browser".
  - krapp 8y ago
    >Compare that with JavaScript/Electron. Electron is heavier and even more memory hungry.
    - StavrosK 8y ago
      I don't know what the GP was thinking. Hopefully exactly that.
  - fetbaffe 8y ago
    Build once, eat memory anywhere.
sagartewari01 8y ago
*Build once, run almost Anywhere

pjmlp 8y ago

Ah, Pascal UCSD!

adrianN 8y ago

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

ForHackernews 8y ago
> the text format defined by the WebAssembly reference interpreter (.wat) https://www.destroyallsoftware.com/talks/wat https://www.destroyallsoftware.com/talks/wat
- maliker 8y 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 8y 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 8y 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?
  - AsyncAwait 8y ago
    > I would ask what the root of your request is: an easy garbage collected language that is ubiquitous? Honestly, I just want to be able to write the stuff I have to in JS today in my favorite language.
  - derefr 8y ago
    This "long-held fervor" that culminated in WASM started back before Node.js existed, so back then, "Javascript" was just a thing browsers did (except for, say, Windows Scripting Host's support of it.) The fervor back then wasn't really driven by a desire for a ubiquitous anything; it was driven specifically by people thinking about browsers, and what is required to program web-apps in browsers. What people have wished for, since... oh, 2001 or so, is the ability to write web-app frontends without needing to grok and deal with the awful runtime semantics of Javascript—the way you do when you write Javascript, yes, but also the way you do when you write in a language that directly transpiles to Javascript, like TypeScript or ClojureScript. Languages like TypeScript may add semantics on top of the JS runtime's semantics, but they can't get away from the fact that the JS runtime is the "abstract machine" they program, any more than e.g. Clojure can get away from the fact that the JVM is the abstract machine it programs. That's why none of these languages were ever seen as a "saving grace" from the "problem of Javascript", the way WASM is. WASM has its own abstract machine (which runs efficiently in browsers), which finally frees people from the tyranny of the Javascript-runtime-as-abstract-machine. It's great that it's also now replacing the Javascript-runtime-abstract-machine in other contexts (e.g. Node-like server-side usage, plain-V8-like embedded usage) but that was never really "the thing" that anyone cared about. --- Mind you, the NaCl fervor was for a ubiquitous VM—but the NaCl fervor wasn't nearly as large, and isn't really what's propelling WASM to prominence right now. Even then, it wasn't about "an easy garbage collected language that is ubiquitous", no. The goal of it was to be able to take code that you already have—native code, written to run fast, like a AAA game—and put it in a browser-strength sandbox, such that it can be zero-installed just by visiting a URL, with full performance. You know, like ActiveX was supposed to be. But better. NaCl didn't really get us there, because it happened right as the architectural split between x86 and ARM really started heating up, and NaCl's solution to that split—PNaCl, a.k.a. sandboxed LLVM IR—was both too late and not really efficient-enough at the time to fully supplant the "Native" NaCl in NaCl messaging. (LLVM IR works well-enough now for Apple to rely on it for being a "unified intermediate" of both x86 and ARM target object code, but that shift only began with ~8 additional years of LLVM development after the version of LLVM that PNaCl's IR came from.) WASM seems to get us there. But do we care any more? Everyone already has other solutions to this problem. ChromeOS can run Android apps; Ubuntu Snappy packages can expose GUIs to Wayland; Windows has a Linux ABI to run Docker containers. Ubiquity is a lot easier now than it was back then, for any particular use-case you might want. On the embedded-scripting side of things, everyone has seemingly settled on embedding LuaJIT or V8. Do people even need embedded scripts to be fast, in a way that "WASM as compilation target" would help with? Maybe for the more esoteric use-cases like CouchDB's "design documents" or the Ethereum VM (https://medium.com/coinmonks/ewasm-web-assembly-for-ethereum-54719ece2042. https://medium.com/coinmonks/ewasm-web-assembly-for-ethereum...) But I doubt WASM will hit ubiquity here. Why would OpenResty switch? Why would Redis? Etc. You're not writing-and-compiling native code for any of these in the first place, so adding WASM here would only break existing workflows.

kgraves 8y ago

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

hypfer 8y ago

Its literally Java all over again. Don't. Just. Don't.

guiriduro 8y 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?
- johncolanduoni 8y 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).
  - lazyjones 8y ago
    > 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). Is this a fair comparison? JVM and CLR allow general purpose programming and syscalls across several platforms. What can you do with WASM today? Only whatever is allowed by browsers.
    - 8y ago

richardwhiuk 8y ago

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

thefounder 8y ago
A portable binary like wasm makes deployment easier and potentially makes it more secure/easier to sandbox.
- richardwhiuk 8y ago
  Makes deployment harder surely? Now you need to both ship the wasm runner and the compiled code of the executable?
  - amelius 8y ago
    You can still ship your native code. So you have two options instead of one.
  - thefounder 8y ago
    The host is supposed to support wasm and most hosts will do.
    - mr_toad 8y ago
      With about 50% of corporate desktops still using Windows 7 with IE11 as the default browser - it’s going to take a while before wasm is truely ubiquitous.
      - maxgraey 8y ago
        That's not true: https://bit.ly/2GMbAN3 https://bit.ly/2GMbAN3
  - int_19h 8y ago
    Projects like this one are the first step towards native wasm support on OS level across major platforms. It'll happen, the only question is how soon.

vkaku 8y 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 8y ago
that isn’t what wasm is.
- vkaku 8y 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.

seanwilson 8y 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 8y 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 8y 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.
  - afiori 8y ago
    It is close in the wording but very different in almost every other sense. wasm pushes for many indipendent implementation, it is meant to be very minimal and importantly it is made to be embeddable. In a sense it is closer to lua than Java.
    - runako 8y ago
      At the risk of jumping into this, Java was intended to be small (small enough to run on processors that were below PC-class in the 1990s) and embeddable. https://www.javaworld.com/article/2073700/mobile-java/mobile-java-java-everywhere-is-for-world-domination.html https://www.javaworld.com/article/2073700/mobile-java/mobile... The idea of Java running on devices goes back AFAICR to the very beginning of the language. I remember the "Java everywhere" slogan and initiatives to put Java into every device. Java Card was a version of Java designed to run on smart cards. If memory serves, these were all design goals of the Java platform in the early 90s. (Remarkably, this was all well before Linux really took off, before the Internet was ubiquitous, and when the most sophisticated electronics most households owned was a VHS player.) https://en.wikipedia.org/wiki/Java_Card https://en.wikipedia.org/wiki/Java_Card

willvarfar 8y 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 8y ago
Wasm is split between wasm32 and wasm64 they are separate https://github.com/WebAssembly/design/blob/master/FutureFeatures.md#linear-memory-bigger-than-4-gib 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 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 8y 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 8y 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-java-applets-flash https://words.steveklabnik.com/is-webassembly-the-return-of-...

acqq 8y ago
The post is not about this implementation (the link of the original post) though. This implementation is not about the browsers.
userbinator 8y 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?
- afiori 8y ago
  But flash was not an option for similar purposes because of its terrible security.
- vorpalhex 8y 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.
  - deleted 8y ago
    [deleted]
  - aepiepaey 8y ago
    The runtime is ~15MB, far from hundreds of MBs.

jokoon 8y 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.

flohofwoe 8y 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).
pjmlp 8y ago
Yes, cheerp https://www.leaningtech.com/cheerp/ https://www.leaningtech.com/cheerp/
steveklabnik 8y 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 8y 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 https://github.com/appcypher/wasabi

bluejekyll 8y 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...

steveklabnik 8y 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.
- bluejekyll 8y ago
  So the Cloudflare perspective. Yes, it’s interesting.
  - steveklabnik 8y ago
    Or the “script my application with wasm” perspective, or the “smart contracts for blockchain” perspective, yeah. Think “docker”, in some ways.

youareawesome 8y 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/gavofyork/status/1094597005333151745 https://twitter.com/Sunfishcode/status/1075486397824327681 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/a81500e047fdd321b3dd3f9fabb87fecbd2d7792#diff-9c2f6a65948817d0ab677942d577d2d0 https://github.com/wasmerio/wasmer/commit/a81500e047fdd321b3...

justinclift 8y ago
Looks like they made a mistake, apologised, and have added attribution since?
- youareawesome 8y 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.
  - ozzmotik 8y ago
    a problem fixed under less ideal situations is still a fixed problem regardless.
    - youareawesome 8y ago
      Do you think they would they have fixed the problem if they weren't called out publicly?
      - ozzmotik 8y ago
        i don't think it matters because they __did__ fix the problem. maybe that would have been a problem in the past before the problem became acknowledged, but the thing is, that isn't the case anymore and so to me it really doesn't matter. but even if it did matter, i still probably wouldn't care. sometimes people need convincing to do a thing and when it comes to presenting a consistent and positive image to others, i think it's quite a generally good thing if someone is responsive to the criticism of others and actually acts on it. maybe they should have fixed it before of their own accord. but maybe before they didn't see the issue that others saw. people aren't perfect any they make mistakes. constantly.

jayd16 8y 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.

stcredzero 8y 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 https://news.ycombinator.com/item?id=9806607

runeks 8y 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?
- pjmlp 8y 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.
- stcredzero 8y 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 8y 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 8y 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.

flohofwoe 8y 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_19h 8y 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 https://github.com/Microsoft/xlang

decafbad 8y 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 8y 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 8y ago

http://troubles.md/posts/wasm-is-not-a-stack-machine/ 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 8y 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-intro-to-webassembly/ https://hacks.mozilla.org/category/code-cartoons/a-cartoon-i...

unnouinceput 8y 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.