8 ms·

Increasingly I’m becoming convinced that something like this may become the backbone of future computing. Imagine truly cross platform code that performs well,

Increasingly I’m becoming convinced that something like this may become the backbone of future computing. Imagine truly cross platform code that performs well, and can be written in whatever language you care for. The web illustrated certain advantages to developing software that can be easily delivered and run on other systems. However, the learnings of the web were always coupled to the browser. WebAssembly, through projects like this, may soon be able to empower cross platform code that delivers small, well performing programs on whatever platform a user desires to use.

zimablue 8y ago
Genuinely ignorant question, what's the difference with C from this perspective? I thought the whole point of C was to be a common language.
- kodablah 8y ago
  Nasal demons
- naasking 8y ago
  Binary compatibility across architectures, no undefined behaviours are the primary ones.
  - quickben 8y ago
    Yes of course, here is an example of a well defined, no ub, == overloads. https://slikts.github.io/js-equality-game/ https://slikts.github.io/js-equality-game/ It is all bound to make JS kernel programing a Pilar of OS Stability.
    - kanox 8y ago
      Does that apply to web assembly?
    - tomjakubowski 8y ago
      None of that applies to web assembly, as I'm sure you know.
    - rictic 8y ago
      You're confusing JS with wasm and undefined behavior with confusing behavior. JS and wasm are strongly defined and the specifications consider undefined behavior a bug.
- kettlecorn 8y ago
  C has to be recompiled per platform. The advantage to something like using WebAssembly is you could write a program in C, compile it to WebAssembly, and then it could be run on anything that supports WebAssembly. This could enable a future where you write one program that can run in a web browser, as a phone app, as a desktop program. All with only tweaking the UI. Additionally the divide between a “web app” and a desktop app from a user perspective increasingly comes down to: do I need this to run fast (as a native program), or do I want it to be convenient to use (as a web app)? WebAssembly may very well become fast enough that it is fast and convenient for all but the absolute most demanding of applications.
- akiselev 8y ago
  WebAssembly's closest analog would be LLVM's IR, which many compilers like clang (for C/C++) or rustc output so that they can use LLVM's existing codegen. In WebAsm's case, however, the backend would be the different browsers and their sandboxes. The C ABI describes a common calling convention and a few other details to allow different compilers to use each other's binaries, but C is hardly a common language in the way WebAssembly is meant to be.
ummonk 8y ago
Well, the JVM was supposed to be this, but turned out to be too closely tied to the Java language, as well as too heavyweight for a lot of webpages (getting replaced by HTML5 instead). It's interesting to see us coming full circle with WebAssembly, albeit with a much more language neutral, multi-vendor framework.
- kettlecorn 8y ago
  I was going to bring up the JVM because it definitely was an attempt at the same goal. I think the obstacles this time around will be very similar for WASM, but it stands a far better chance due to its language and vendor neutrality, as you mentioned. For user facing applications there remains the question of what sort of cross platform UI framework could accompany WASM. Or should WASM just remain coupled to the Web? Java’s UI solutions were often received very poorly and led to Java’s bad reputation amongst consumer software. Analyzing the desires and goals of the big players (Google, Microsoft, Apple) with regards to how Wasm might develop is interesting.
- kodablah 8y ago
  > Well, the JVM was supposed to be this, but turned out to be too closely tied to the Java language, as well as too heavyweight for a lot of webpages Agreed, but want to add wrt tied to Java the language, that stdlib it carries around is a large burden too. WASM will need a stdlib one day or suffer portability, so here's to hoping whichever one is adopted is small and simple (no, posix is not good enough like emscripten and this lib work with).
  - thrower123 8y ago
    As we've seen with JS, an anemic standard library is also a big problem. Hopefully npm-isms dont infect WebAssembly, but I don't hold out much hope.
    - krapp 8y ago
      Why does WebAssembly need its own standard library? No one is going to be writing code directly in it, any more than they would write Java bytecode by hand.
dfox 8y ago
Both Burroughs/Unisys and IBM had same idea about future of computing in the late 70's and then went to build AS/400 and Burroughs large systems, which are both based on kernel-space JIT compiled "bytecode" (with significant difference in granularity of the thing that gets compiled on first use and how the compilation results are cached, which for IBM i5/OS essentially means that it is on-demand AOT compiler), which is the reason that these systems are currently based on commodity hardware (ie. Power and Xeon).
- snaky 8y ago
  And the AS/400 used to be the huge success.
nwmcsween 8y ago
Operating systems don't work like that, you could program something high level but in the non-web world you need ensure data is written to storage and syscalls which are not portable even between architectures.
- kettlecorn 8y ago
  For WebAssembly programs to work syscalls and storage stuff would have to be wrapped so that each platform has its own implementation with the same interface. This isn't that strange of a concept, it's how stuff like Java has worked, but for it to truly feel native the companies that control the platforms would have to coordinate on it and integrate it. Unfortunately I don't see that happening quickly, but perhaps eventually.
  - nwmcsween 8y ago
    Would never work, how do you emulate real capabilities on say Linux or IOCP, etc.
jokoon 8y ago
I agree 120%. It's weird nobody seems to really complain about platform lock in, which is the main problem created by software companies, that create so much pain for developers. Even if one looks at the software market, I really doubts that lock in really works at all. Developers quickly figure out ways to do things run on multiplatform. It's no surprise JavaScript grew to be so popular, because it was just 100% multi platform. It's quite sad to realize js has so many drawbacks.
- kettlecorn 8y ago
  Attempts at lock-in just seem to delay the inevitable and make software worse in the meantime. For companies like Microsoft and Apple those delays have been enormously profitable, but long term there may be a hefty cost from their avoidance of truly great crossplatform software development tools.
pjmlp 8y ago
We are going in circles here, this is how mainframes started in the early 60's, bytecode with microcoded CPUS. Notable examples, Burroughs B5500, Xerox PARC workstations, ETHZ Oberon/Modula-2 workstations, UCSD Pascal, ..., iOS bitcode, Android DEX and UWP MSIL.

zimablue 8y ago

Genuinely ignorant question, what's the difference with C from this perspective? I thought the whole point of C was to be a common language.

kodablah 8y ago
Nasal demons
naasking 8y ago
Binary compatibility across architectures, no undefined behaviours are the primary ones.
- quickben 8y ago
  Yes of course, here is an example of a well defined, no ub, == overloads. https://slikts.github.io/js-equality-game/ https://slikts.github.io/js-equality-game/ It is all bound to make JS kernel programing a Pilar of OS Stability.
  - kanox 8y ago
    Does that apply to web assembly?
  - tomjakubowski 8y ago
    None of that applies to web assembly, as I'm sure you know.
  - rictic 8y ago
    You're confusing JS with wasm and undefined behavior with confusing behavior. JS and wasm are strongly defined and the specifications consider undefined behavior a bug.
kettlecorn 8y ago
C has to be recompiled per platform. The advantage to something like using WebAssembly is you could write a program in C, compile it to WebAssembly, and then it could be run on anything that supports WebAssembly. This could enable a future where you write one program that can run in a web browser, as a phone app, as a desktop program. All with only tweaking the UI. Additionally the divide between a “web app” and a desktop app from a user perspective increasingly comes down to: do I need this to run fast (as a native program), or do I want it to be convenient to use (as a web app)? WebAssembly may very well become fast enough that it is fast and convenient for all but the absolute most demanding of applications.
akiselev 8y ago
WebAssembly's closest analog would be LLVM's IR, which many compilers like clang (for C/C++) or rustc output so that they can use LLVM's existing codegen. In WebAsm's case, however, the backend would be the different browsers and their sandboxes. The C ABI describes a common calling convention and a few other details to allow different compilers to use each other's binaries, but C is hardly a common language in the way WebAssembly is meant to be.

ummonk 8y ago

Well, the JVM was supposed to be this, but turned out to be too closely tied to the Java language, as well as too heavyweight for a lot of webpages (getting replaced by HTML5 instead). It's interesting to see us coming full circle with WebAssembly, albeit with a much more language neutral, multi-vendor framework.

kettlecorn 8y ago
I was going to bring up the JVM because it definitely was an attempt at the same goal. I think the obstacles this time around will be very similar for WASM, but it stands a far better chance due to its language and vendor neutrality, as you mentioned. For user facing applications there remains the question of what sort of cross platform UI framework could accompany WASM. Or should WASM just remain coupled to the Web? Java’s UI solutions were often received very poorly and led to Java’s bad reputation amongst consumer software. Analyzing the desires and goals of the big players (Google, Microsoft, Apple) with regards to how Wasm might develop is interesting.
kodablah 8y ago
> Well, the JVM was supposed to be this, but turned out to be too closely tied to the Java language, as well as too heavyweight for a lot of webpages Agreed, but want to add wrt tied to Java the language, that stdlib it carries around is a large burden too. WASM will need a stdlib one day or suffer portability, so here's to hoping whichever one is adopted is small and simple (no, posix is not good enough like emscripten and this lib work with).
- thrower123 8y ago
  As we've seen with JS, an anemic standard library is also a big problem. Hopefully npm-isms dont infect WebAssembly, but I don't hold out much hope.
  - krapp 8y ago
    Why does WebAssembly need its own standard library? No one is going to be writing code directly in it, any more than they would write Java bytecode by hand.

dfox 8y ago

Both Burroughs/Unisys and IBM had same idea about future of computing in the late 70's and then went to build AS/400 and Burroughs large systems, which are both based on kernel-space JIT compiled "bytecode" (with significant difference in granularity of the thing that gets compiled on first use and how the compilation results are cached, which for IBM i5/OS essentially means that it is on-demand AOT compiler), which is the reason that these systems are currently based on commodity hardware (ie. Power and Xeon).

snaky 8y ago
And the AS/400 used to be the huge success.

nwmcsween 8y ago

Operating systems don't work like that, you could program something high level but in the non-web world you need ensure data is written to storage and syscalls which are not portable even between architectures.

kettlecorn 8y ago
For WebAssembly programs to work syscalls and storage stuff would have to be wrapped so that each platform has its own implementation with the same interface. This isn't that strange of a concept, it's how stuff like Java has worked, but for it to truly feel native the companies that control the platforms would have to coordinate on it and integrate it. Unfortunately I don't see that happening quickly, but perhaps eventually.
- nwmcsween 8y ago
  Would never work, how do you emulate real capabilities on say Linux or IOCP, etc.

jokoon 8y ago

I agree 120%. It's weird nobody seems to really complain about platform lock in, which is the main problem created by software companies, that create so much pain for developers. Even if one looks at the software market, I really doubts that lock in really works at all. Developers quickly figure out ways to do things run on multiplatform. It's no surprise JavaScript grew to be so popular, because it was just 100% multi platform. It's quite sad to realize js has so many drawbacks.

kettlecorn 8y ago
Attempts at lock-in just seem to delay the inevitable and make software worse in the meantime. For companies like Microsoft and Apple those delays have been enormously profitable, but long term there may be a hefty cost from their avoidance of truly great crossplatform software development tools.

pjmlp 8y ago

We are going in circles here, this is how mainframes started in the early 60's, bytecode with microcoded CPUS. Notable examples, Burroughs B5500, Xerox PARC workstations, ETHZ Oberon/Modula-2 workstations, UCSD Pascal, ..., iOS bitcode, Android DEX and UWP MSIL.