3 ms·

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 irrel

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

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-...