4 ms·

WASM is not a startup, it's a very niche tech and pushing it to other niches as a "platform" needs a lot of investment and buy in from professionals and managem

WASM is not a startup, it's a very niche tech and pushing it to other niches as a "platform" needs a lot of investment and buy in from professionals and management working in those niches. Not that the idea itself of an intermediate representation is bad, it's just WASM is not necessarily good and the odds are definitely against it. HN top comment on dropbox wasn't really wrong either. Triviality proved to be a valid point. Plenty of companies made similar software once they saw there was a need for it. I mean who still uses dropbox today?

afiori 7y ago
I surely am missing something, because I have no idea why you think wasm is niche. It is niche today the same way javascript-rich interfaces where niche during the reign of PHP. I don't know how to answer the rest of your comment... I don't think we have enough common ground to understand each other.
- zzzcpan 7y ago
  There are maybe a few hundred people on earth who are in a position to embed wasm into something, how is that not niche?
  - afiori 7y ago
    here embedding can mean just plugins. This very article is about a framework for robotics. Another extremely plausible option is simply to sandbox mods for games. There are even projects for allowing userspace modules to run safely inside the kernel similarly to EBPF. This last one in particular is something entirely new. Without even considering the obvious application of allowing photo editing in web interfaces with reasonable performance. Or on the other side of legality many people will try and use the new performance to have better cryptomining botnets. Just by considering plugins (with dynamical loading and safety) and number crunching in-browser I would say that 'few hundreds' becomes a significant understatement.
    - zzzcpan 7y ago
      I'm not talking about potential applications of things that may or may not embed wasm and provide high level interfaces, libraries, compilers, tools. It's irrelevant whether high level stuff uses wasm underneath, application developers won't be touching it directly. I'm talking about actually doing all that work to enable application development. These are the people wasm targets and there are very few of such people on earth. It's very niche tech. I was considering wasm for myself too, read the spec, articles, played with their ocaml implementation, parsed a bit of bytecode, but concluded that it's not a good tech, too browser specific to use elsewhere and waste time on it.
      - afiori 7y ago
        If I understand correctly you are talking about stuff like a debugger for an opaque wasm binary. The kind of tooling a system administrator could want to manage various wasm programs running on their servers. I will assume so :) There was a nice article detailing how for many application usage wasm today is less safe (under certain aspects) of x86, specifically due to the high quality level of tooling available for x86 and due to the fact that today debugging/inspection support of wasm is very low. Other than that I would say that it is specific to the constraints you have in a browser. Two of which are the ability to run on minimal implementations requirement (as new optional features might be missing and might be running in a variety of environments) and the ability to safely run arbitrary untrusted code. If you do not care about these then wasm does not offer much to you. On the other hand it is perfect as a compilation target for plugins. > application developers won't be touching it directly. On the web it is meant to replace asm.js, it is not meant to be written by hand (unless you are a compiler developer). The whole point of the article in this case is that it is a perfect interface for plugins over a specific and limited interface that allows running untrusted and opaque binaries. For this specific usage only high-level languages where a viable choice up to now (two common choices were js and lua). wasm is comparatively closer to C than javascript/lua, but it is still safe to arbitrarily embed without using OS-level mechanisms. It is a very specific use case, but also a relatively common one in applications. One of the big sponsors (Fastly) in investing a lot in it due to the usefulness for them regarding lightweight sandboxing (for this reason they are also developing a debugger for wasm [1]). On the other hand it is essentially useless if your application is something like a unix utility. [1] I am not sure it is in this episode, but here the CTO of fastly explain why it is useful for their use case: https://softwareengineeringdaily.com/2019/09/25/webassembly-isolation-with-tyler-mcmullen/ https://softwareengineeringdaily.com/2019/09/25/webassembly-...

afiori 7y ago

I surely am missing something, because I have no idea why you think wasm is niche. It is niche today the same way javascript-rich interfaces where niche during the reign of PHP. I don't know how to answer the rest of your comment... I don't think we have enough common ground to understand each other.

zzzcpan 7y ago
There are maybe a few hundred people on earth who are in a position to embed wasm into something, how is that not niche?
- afiori 7y ago
  here embedding can mean just plugins. This very article is about a framework for robotics. Another extremely plausible option is simply to sandbox mods for games. There are even projects for allowing userspace modules to run safely inside the kernel similarly to EBPF. This last one in particular is something entirely new. Without even considering the obvious application of allowing photo editing in web interfaces with reasonable performance. Or on the other side of legality many people will try and use the new performance to have better cryptomining botnets. Just by considering plugins (with dynamical loading and safety) and number crunching in-browser I would say that 'few hundreds' becomes a significant understatement.
  - zzzcpan 7y ago
    I'm not talking about potential applications of things that may or may not embed wasm and provide high level interfaces, libraries, compilers, tools. It's irrelevant whether high level stuff uses wasm underneath, application developers won't be touching it directly. I'm talking about actually doing all that work to enable application development. These are the people wasm targets and there are very few of such people on earth. It's very niche tech. I was considering wasm for myself too, read the spec, articles, played with their ocaml implementation, parsed a bit of bytecode, but concluded that it's not a good tech, too browser specific to use elsewhere and waste time on it.
    - afiori 7y ago
      If I understand correctly you are talking about stuff like a debugger for an opaque wasm binary. The kind of tooling a system administrator could want to manage various wasm programs running on their servers. I will assume so :) There was a nice article detailing how for many application usage wasm today is less safe (under certain aspects) of x86, specifically due to the high quality level of tooling available for x86 and due to the fact that today debugging/inspection support of wasm is very low. Other than that I would say that it is specific to the constraints you have in a browser. Two of which are the ability to run on minimal implementations requirement (as new optional features might be missing and might be running in a variety of environments) and the ability to safely run arbitrary untrusted code. If you do not care about these then wasm does not offer much to you. On the other hand it is perfect as a compilation target for plugins. > application developers won't be touching it directly. On the web it is meant to replace asm.js, it is not meant to be written by hand (unless you are a compiler developer). The whole point of the article in this case is that it is a perfect interface for plugins over a specific and limited interface that allows running untrusted and opaque binaries. For this specific usage only high-level languages where a viable choice up to now (two common choices were js and lua). wasm is comparatively closer to C than javascript/lua, but it is still safe to arbitrarily embed without using OS-level mechanisms. It is a very specific use case, but also a relatively common one in applications. One of the big sponsors (Fastly) in investing a lot in it due to the usefulness for them regarding lightweight sandboxing (for this reason they are also developing a debugger for wasm [1]). On the other hand it is essentially useless if your application is something like a unix utility. [1] I am not sure it is in this episode, but here the CTO of fastly explain why it is useful for their use case: https://softwareengineeringdaily.com/2019/09/25/webassembly-isolation-with-tyler-mcmullen/ https://softwareengineeringdaily.com/2019/09/25/webassembly-...