Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

WebAssembly 101: A developer’s first steps

blog.openbloc.fr

Post reply on HN
Print view View original

91–100 of 153 posts

Re: WebAssembly 101: A developer’s first steps

#91

Post by dullgiulio »

Klathmon wrote: post #56
dullgiulio wrote: post #54

Earlier quoted context omitted.

Thank you for the link, you too had a very nice discussion. However I find unsetting how Eich ends up defending WASM by hoping it's not too successful (used only in some hot pathes, not full blob apps.) That's frankly quite ridiculous: I predict a full apps adoption pretty soon. Just wait for more mainstream languages to support it. The open web in the sense the OP meant has been dead for a while, WASM is just anothe…

You'll notice that basically everyone involved with WASM agrees that it won't be used for full applications any time soon if ever. It's only people who aren't as involved who are calling for it. WASM is not a replacement for javascript, and it's not trying to be. You won't be writing entire applications in whatever you compile to WASM, it's not how it's designed, it's not how it's meant to run, and it's worse in most…

Nothing is harder to predict than the future. ;)

I can also run objdump against Microsoft Office. Does it make it open?

Re: WebAssembly 101: A developer’s first steps

#92

Post by smitherfield »

johngruber wrote: post #39

This can probably only be expected to get better and better. While JS engines are squeezing hard to get some extra performance, WASM is just beginning its life. It'd be great if someone would make (when it's technological feasible) a way to integrate this natively in node, something like: const wasm = require('wasm-native'); (async () => { const mymodule = await wasm('mymodule.c'); // use mymodule here })();

Why not just write a native extension?

Re: WebAssembly 101: A developer’s first steps

#93

Post by kllrnohj »

BenoitEssiambre wrote: post #59

I wonder where the world is going with this. At first glance it looks like webassembly is a potential faster replacement for javascript in the browser. However, javascript is an increasingly popular language everywhere. I'm not sure people will want to move away from it for most development. The part that is actually causing performance problems with web application is the HTML/CSS/DOM layer which was not designed as…

I honestly find it a bit crazy that we have webasm before viable multitasking in JavaScript. webworkers being multi-process not multi-threading, and also extremely slow, limited, and needlessly RAM intensive. Multi-process could have worked if they would have at least had fast messaging (~1ms communication overhead is absurd), some form of shared data (at least let me share immutable ArrayBuffers! it's immutable! that's safe!), and some form of move operation instead of copy to allow for cheap handoffs of data structures. That'd still all be safe, no risk of memory corruption, etc...

But no, let's port assembly to the browser instead! Then you get that extra bit out of that one already-overloaded core instead of tapping in to the potentially 15+ other cores on the device!

I'd put forth that that's a far bigger issue to web app performance than HTML/CSS/DOM is. It is for the very heavy web app I've worked on, anyway.

WebAsm's most intriguing aspect as a result is that it has plans to actually add threading along with things like SharedArrayBuffer. That would make locally-intensive & offline webapps vastly more viable.

Re: WebAssembly 101: A developer’s first steps

#94

Post by kazinator »

smitherfield wrote: post #90
jswny wrote: post #84

Earlier quoted context omitted.

I mean, I agree with you but that's not even that bad of an example. I would expect many languages to do something similar. Something like this might be a better example: "\t\r\n" == 0 → true "\t\r\n 16 \t\r\n" == 16 → true "\t\r\n 16 \t\r\n" == "16" → false

> I would expect many languages to do something similar. Of the common dynamic languages I can think of, the only ones that do something similar are Perl/Perl6 and PHP, and even they are still saner than JS. $ $((1+\2)) bash: 1+\2: syntax error: operand expected (error token is "\2") $ $((1-\2)) bash: 1-\2: syntax error: operand expected (error token is "\2") $ ruby -e"1+'2'" -e:1:in `+': String can't be coerced into…

In the awk macro of TXR Lisp, I wanted to provide some of the convenience of the "duck typing" in Awk, whereby a string which looks like a number can be used like one. Instead of supporting such a thing directly (which I consider a computer science flunk job in language design) I came up with a field conversion facility that has a succinct syntax: clear and unobtrusive.

http://www.nongnu.org/txr/txr-manpage.html#N-018CCE37

This demonstrates some of it:

  1> (awk (t (fconv i) (prinl f)))
  1 2 3 4 5
  (1 "2" "3" "4" "5")
  nil
  2> (awk (t (fconv i : r) (prinl f)))
  1 2 3 4 5
  (1 2.0 3.0 4.0 5.0)
  nil
  3> (awk (t (fconv : i : r) (prinl f)))
  1 2 3 4 5
  (1 2 3 4 5.0)
  nil
  4> (awk (t (fconv i : r : i) (prinl f)))
  1 2 3 4 5
  (1 2.0 3.0 4.0 5)
There are more conversion specifiers than just r and i. There can be any number in a row before the first colon, in the middle, or after the last colon. Conversions are matched with fields and applied. If a colon occurs, conversions after the colon are repeatedly applied to the remaining fields in cyclic repetition. If two colons occur, conversions after the second colon are applied to the trailing fields. There is intelligent prioritizing when these rules overlap.

There are conversions with a z suffix which treat junk as zero:

  8> (awk (t (fconv : iz) (prinl f)))
  a b c 1 2 3
  (0 0 0 1 2 3)
Without this, you get nil which will blow up if used as a number -- but you can test for it and handle the situation rather than getting a silent zero:

  9> (awk (t (fconv : i) (prinl f)))
  a b c 1 2 3
  (nil nil nil 1 2 3)
Basically the whole "anything can be used as a number, and junk makes zero" nonsense can be avoided with only a small reduction in code golfing. Textual duck typing is a wrongheaded solution for an ergonomic problem, which sacrifices correctness and clarify of data representation for the sake of absolutely minimizing the program character count.

Re: WebAssembly 101: A developer’s first steps

#95

Post by AriaMinaei »

I wonder how it would be, had capability-based system architectures taken off and become mainstream. I guess we wouldn't need WebAssembly to run untrusted code safely, because in such a system, all objects – from whole programs to an object as small as the number 4 – would be safe and sealed off from each other on a hardware level.

I'm reading Capability-Based Computer Systems [0] by Henry M. Levy (1984), motivated by wanting to learn about the Burroughs B5000 that Alan Kay has praised multiple times. I've only started to learn about these things and I don't understand the implications, but if I'm reading it correctly, such architectures would obviate the need for web-style safety measures such as process-sandboxing ala Chrome, shader sanitizing ala WebGL, etc, because everything in the system would be safe that way.

[0] https://books.google.de/books/about/Capability_Based_Compute...

More about this: https://en.wikipedia.org/wiki/Capability-based_security and https://en.wikipedia.org/wiki/Capability-based_addressing

Re: WebAssembly 101: A developer’s first steps

#96

Post by flavio81 »

madrafi wrote: post #82

So now I have to write C code ? XD

No, you can write in many other languages. For example there are many compilers out there that will compile into LLVM bytecode.

And then you can translate such LLVM bytecode into Webassembly using a tool like Emscripten.

Thus you can compile to Webassembly!

Re: WebAssembly 101: A developer’s first steps

#97

Post by flavio81 »

madrafi wrote: post #83
madrafi wrote: post #82

So now I have to write C code ? XD

One thing though How is taking the whole C in the browser approach ressource wise ?

It is not C in the browser. It is a sort-of-virtual machine in the browsers.

Browsers (i.e. Chrome) are already doing this to execute Javascript, for example. Webassembly, to put it in a simplified way, allows you to "bypass" the javascript layer and target directly the virtual-machine. And done in a compatible, well-documented way.

So you can gain in performance, and flexiblity.

Re: WebAssembly 101: A developer’s first steps

#98

Post by z3t4 »

jakelazaroff wrote: post #49
jordigh wrote: post #29

Remember when you could hit "View Source" to see how the web was built? I don't like where this is going. Minification was bad enough, now we're going to be getting more non-free blobs shoved into our browsers and this is being touted as a great new feature for us. It will end up being a tool of control and surveillance like always. This guy says it a bit more eloquently than I can: https://lobste.rs/s/wjtu7c/webasse…

What I don't understand about this viewpoint is, don't all of these caveats also apply to native apps?

Would you be OK with having every website you visit run native byte-code on your computer !? At least for me, it takes some trust to install a native app. I don't trust some companies and would never let them run a binary blob on my computer, still I sometimes visit their web sites, with JavaScript turned off of course. Some sites require JavaScript though, but I can turn on selective parts (using NoScript plugin) and then investigate all the nasty stuff with the browser's built in debugger.

Re: WebAssembly 101: A developer’s first steps

#99

Post by z3t4 »

lixquid wrote: post #62
BenoitEssiambre wrote: post #59

I wonder where the world is going with this. At first glance it looks like webassembly is a potential faster replacement for javascript in the browser. However, javascript is an increasingly popular language everywhere. I'm not sure people will want to move away from it for most development. The part that is actually causing performance problems with web application is the HTML/CSS/DOM layer which was not designed as…

I'd wager a lot of this popularity is correlation, not causation. A lot of its popularity stems from being the dominant browser scripting language. This causes it to be popular with back-end frameworks for code re-use and shared developer skill. This causes it to be popular with, say, database engines that are used by the back-end, and so on and so forth. WebAssembly is the first steps to truly breaking that chokehol…

JavaScript is easy to debug and test, its relative safe, and closures makes it easy to write async programs. Compared to C or C++ you'll have a huge productivity boost with a very small performance penalty. It's also easy to learn compared to other languages. It also doesn't have a standard library which makes it easy to integrate into any platform. For example in Windows OS and other Microsoft products you've been able to use JavaScript as a scripting language for a very long time. So JavaScript is not a language that has only been available in browsers. There are actually people out there that prefer JavaScript and write in it voluntarily.

Re: WebAssembly 101: A developer’s first steps

#100

Post by z3t4 »

snarfy wrote: post #69
BenoitEssiambre wrote: post #59

I wonder where the world is going with this. At first glance it looks like webassembly is a potential faster replacement for javascript in the browser. However, javascript is an increasingly popular language everywhere. I'm not sure people will want to move away from it for most development. The part that is actually causing performance problems with web application is the HTML/CSS/DOM layer which was not designed as…

> I'm not sure people will want to move away from it for most development. x = 1 + '2' //12 x = 1 - '2' //-1 Oh yes, yes we do.

That is really for convenience, you can still be explicit:

  if(foo === 1 || foo === "1" || foo === true) { ...
Post reply on HN