5 ms·

This reminds me of the classic owl meme. Draw two circles, then draw the rest of the damn owl. Writing a hello world does not make WebAssembly easy. I can write

This reminds me of the classic owl meme. Draw two circles, then draw the rest of the damn owl. Writing a hello world does not make WebAssembly easy. I can write a hello world in Rust or in Haskell trivially. That doesn't mean I understand borrow checking or monads. Besides the author doesn't even go over printing hello world. In fact there's quite a lot that's inaccurate with this short article. WebAssembly is not really close to Assembly. It offers quite a lot more structure, including control flow and even a concept of functions with types. Also refactoring performance critical code in WebAssembly is not the greatest idea since there's a massive interop overhead. Not to mention hand writing WASM is incredibly tedious.

sp332 7y ago
There is a good reason why we are not attempting to print a string. Yeah, there's a good reason printing "Hello, World!" is the test. If you can't even get that far, you're going to have a hard time doing anything useful at all.
- everdev 7y ago
  Is that really a good "test"? Printing a string isn't hard in any non-hobby language.
  - deleted 7y ago
    [deleted]
  - herbstein 7y ago
    The idea is that it's the most basic example (in most instances) of ensuring your whole pipeline is setup correctly. It's the software equivalent of a smoke test.
  - kragen 7y ago
    It's hard until you have the toolchain and I/O working. That's what it's a test of. The rest of WebAssembly doesn't seem like an obstacle at all to me. For me the big unknown is how to get a wasm program running at all and communicating with something on my screen.
  - SkyBelow 7y ago
    It is a test that you can go from written code to an output that is human readable. This is the basic steps to allow us to use printf debugging. Until you get to this point, it can be hard to be sure your code is actually working or even compiling or if you have established a way to report errors. As other poster's have commented, for most languages the code for this is trivial but the importance is that it tests the entire compile/link/execute tool chain which may not be as trivial to setup.
smitty1e 7y ago
"Everything is easy, when you know how to do it. It's that learning curve. . ."--me
- ngold 7y ago
  >You only feel dumb until you understand it.
  - hinkley 7y ago
    UX issues being a big exception to that rule. Several tools I'm pretty deeply familiar with still make me feel dumb because they are user-hostile.
  - macjohnmcc 7y ago
    or you do understand it but mess still mess up somehow.
msla 7y ago
There's the TPK Algorithm, but it still doesn't show off certain parts of the language, such as dynamic memory allocation or passing around references/pointers. Of course, not every language has those things, and it was invented to demonstrate precisely the kinds of languages which don't, such as Eisenhower-era FORTRAN. It does have user input as well as output, plus iteration and conditionals. https://en.wikipedia.org/wiki/TPK_algorithm https://en.wikipedia.org/wiki/TPK_algorithm
swsieber 7y ago
> refactoring performance critical code in WebAssembly is not the greatest idea since there's a massive interop overhead You are right. But if done judiciously, it can bring large benifits. The massive interop overhead has also shrunk quite a bit. Here's a fun article about shrinking the overhead: https://hacks.mozilla.org/2018/10/calls-between-javascript-and-webassembly-are-finally-fast-%F0%9F%8E%89/ https://hacks.mozilla.org/2018/10/calls-between-javascript-a... - IIRC, chrome as added similar optimizations. And here's a fun article about gaining performance through rewriting in WebAssembly: https://hacks.mozilla.org/2018/01/oxidizing-source-maps-with-rust-and-webassembly/ https://hacks.mozilla.org/2018/01/oxidizing-source-maps-with... To be fair, I've written a fair amount of Rust. I haven't really gotten the borrow checker, or at least I've only fought it once or twice, and most of my data structures don't need lifetimes. And from my experience, algorithmic things generally don't require you fight it (except graphs and linked structures), which is what I would think you'd try to optimize. ---- Edit: I agree though that it's not as easy as the author makes it out to be.

sp332 7y ago

There is a good reason why we are not attempting to print a string. Yeah, there's a good reason printing "Hello, World!" is the test. If you can't even get that far, you're going to have a hard time doing anything useful at all.

everdev 7y ago
Is that really a good "test"? Printing a string isn't hard in any non-hobby language.
- deleted 7y ago
  [deleted]
- herbstein 7y ago
  The idea is that it's the most basic example (in most instances) of ensuring your whole pipeline is setup correctly. It's the software equivalent of a smoke test.
- kragen 7y ago
  It's hard until you have the toolchain and I/O working. That's what it's a test of. The rest of WebAssembly doesn't seem like an obstacle at all to me. For me the big unknown is how to get a wasm program running at all and communicating with something on my screen.
- SkyBelow 7y ago
  It is a test that you can go from written code to an output that is human readable. This is the basic steps to allow us to use printf debugging. Until you get to this point, it can be hard to be sure your code is actually working or even compiling or if you have established a way to report errors. As other poster's have commented, for most languages the code for this is trivial but the importance is that it tests the entire compile/link/execute tool chain which may not be as trivial to setup.

smitty1e 7y ago

"Everything is easy, when you know how to do it. It's that learning curve. . ."--me

ngold 7y ago
>You only feel dumb until you understand it.
- hinkley 7y ago
  UX issues being a big exception to that rule. Several tools I'm pretty deeply familiar with still make me feel dumb because they are user-hostile.
- macjohnmcc 7y ago
  or you do understand it but mess still mess up somehow.

msla 7y ago

There's the TPK Algorithm, but it still doesn't show off certain parts of the language, such as dynamic memory allocation or passing around references/pointers. Of course, not every language has those things, and it was invented to demonstrate precisely the kinds of languages which don't, such as Eisenhower-era FORTRAN. It does have user input as well as output, plus iteration and conditionals. https://en.wikipedia.org/wiki/TPK_algorithm https://en.wikipedia.org/wiki/TPK_algorithm

swsieber 7y ago

> refactoring performance critical code in WebAssembly is not the greatest idea since there's a massive interop overhead You are right. But if done judiciously, it can bring large benifits. The massive interop overhead has also shrunk quite a bit. Here's a fun article about shrinking the overhead: https://hacks.mozilla.org/2018/10/calls-between-javascript-and-webassembly-are-finally-fast-%F0%9F%8E%89/ https://hacks.mozilla.org/2018/10/calls-between-javascript-a... - IIRC, chrome as added similar optimizations. And here's a fun article about gaining performance through rewriting in WebAssembly: https://hacks.mozilla.org/2018/01/oxidizing-source-maps-with-rust-and-webassembly/ https://hacks.mozilla.org/2018/01/oxidizing-source-maps-with... To be fair, I've written a fair amount of Rust. I haven't really gotten the borrow checker, or at least I've only fought it once or twice, and most of my data structures don't need lifetimes. And from my experience, algorithmic things generally don't require you fight it (except graphs and linked structures), which is what I would think you'd try to optimize. ---- Edit: I agree though that it's not as easy as the author makes it out to be.