Live data from Hacker News

Goodbye PNaCl, Hello WebAssembly

blog.chromium.org

301–310 of 352 posts

Re: Goodbye PNaCl, Hello WebAssembly

#301

Earlier quoted context omitted.

Can you open a socket or write to the file system with WASM ?

You can only do what the browser sandbox provides, no direct access to the underlying operating system, only to HTML/JS APIs.

Notably JavaScript embedders that give more access (e.g. ChromeOS apps) do provide such interfaces.

Re: Goodbye PNaCl, Hello WebAssembly

#302
post #277
post #223

Earlier quoted context omitted.

I don't know enough about ssh for Chrome and bash for Windows to get your point. Isn't bash for Windows (as part of WSL?) free? What is it that costs more than $5 using bash for windows but is free with ssh for Chrome? Genuinely interested, I'm on OSX mostly but I'm WSL curious.

I interpreted that as them not having access to a Windows machine and wanting to try out the experience for themselves before attempting to teach someone else.

I suppose you could run a modern.ie image and use WSL in that.

Re: Goodbye PNaCl, Hello WebAssembly

#303
post #276
post #170

Earlier quoted context omitted.

Their fans running at max (or a very warm device) would let them know. This has been the experience among the non/less-technical users in my company.

You must have been working with at least quite young people or something. My experience goes the other way. I've seen people who bought a new computer because their fans were running at max and the reason for that was that they were full with dust and dog hair.

I "fixed" someone's computer that would regularly crash a few minutes after starting it by vacuuming the dust out. :)

Re: Goodbye PNaCl, Hello WebAssembly

#304
post #285

Can somebody ELI 5 what is the benefit of WebAssembly vs Asm.js?

It's a format designed to be a target for static languages that do manual memory management (like C/C++) instead of JavaScript that some engines know how to recognize and optimize. The binaries are smaller and much faster to parse and the sandbox model results in much less overhead.

For a concrete example, at least two JavaScript engines (those of Chrome and Firefox) need to emit almost no range checks on regular memory accesses with WebAssembly on 64-bit computers. (For those interested in going past ELI5, they do this by allocating a large chunk of virtual address space, such that any out of range pointers will land somewhere in that space (WebAssembly currently only has 32-bit pointers). Some of the space is filled with memory, and the rest causes a controlled signal/exception so the engine can safely terminate the instance.)

Re: Goodbye PNaCl, Hello WebAssembly

#305
post #282

Earlier quoted context omitted.

You shouldn't have to deal with C++ directly unless you really want to, it's more likely that there will be 'precompiled' WebAssembly modules of existing C/C++ libs which solve computation-heavy tasks (like physics engines, image manipulation, 3d rendering frameworks etc)... and which would offer a Javascript API. The workflow for JS devs would be the same as using a minified Javascript framework now, but instead of…

Without finalizers in JavaScript, WASM Libraries don't work out well, as you need to do manual memory management in your JavaScript code then, as you won't be able to hook the native destructors into the Garbage Collector of JavaScript. So until those are a thing, it'll be extremely ugly to work with WASM Libraries in JavaScript.

I think emscripten does this by keeping dictionaries on the Javascript side which map numeric "ids" (used on the asm.js/wasm side) to JS objects. This is how mapping a GLuint 'texture id' to WebGL objects works for instance. The JS object won't be garbage collected as long as it 'pinned' in the lookup dictionary, but as soon as the asm.js/wasm side manually release the handle, the JS object will be GC'd. Future APIs (like the a WebGL successor) will hopefully provide 'garbage free' APIs so that they don't require keeping such helper structures around.

Re: Goodbye PNaCl, Hello WebAssembly

#306
post #267

>We will remove support for PNaCl in the first quarter of 2018 While the new Google Earth with PNaCl was just introduced, a large engineering cost for a semester-lived technology! Too bad

The code base is almost certainly in C or C++. The parts that use the APIs will need to be changed, but it won't need anywhere close to a full rewrite.

Re: Goodbye PNaCl, Hello WebAssembly

#307

Earlier quoted context omitted.

Incredibly interested in the answer to that question as well. Go will not have a future in regards to web development if they don't find a solution for the GC issue in wasm. I assume (and hope) that's a bigger topic compiler-team internally as well currently.

FYI, https://go.googlesource.com/gollvm/

Interesting, thanks

Re: Goodbye PNaCl, Hello WebAssembly

#308

Earlier quoted context omitted.

It's reinventing the good part of the JVM (the JIT and the bytecode), better than the JVM (unsigned ints and value types are supported), without the bad parts of the JVM on the Web (the libraries, including the slow graphics stack, etc.) What's not to like?

What's not to like? Why couldn't we just create a system compatible with Java bytecode, and just replace the APIs over which it interacts withthe system (as Android has done)? That'd make it even possible to reuse old applets with just a tiny shim around them. And it'd keep compatibility with a huge environment of libraries and languages.

> Why couldn't we just create a system compatible with Java bytecode

Because Java bytecode is not a good target for many languages, such as C and C++, for one. It lacks unsigned and value types.

> just replace the APIs over which it interacts withthe system (as Android has done)?

That still leaves a whole bunch of APIs that are duplicated.

> That'd make it even possible to reuse old applets with just a tiny shim around them.

The number of people who want to do that is far, far less than the number of people who want to compile existing C++ codebases.

> And it'd keep compatibility with a huge environment of libraries and languages.

While sacrificing compatibility with the even huger existing JS environment.

Re: Goodbye PNaCl, Hello WebAssembly

#309
post #299

Earlier quoted context omitted.

Without unsigned types you have to use the next larger type and mask. It's ugly, a pain, and slower. You run into this problem a lot when dealing with binary data.

You're begging the question, assuming you have to represent a particular unsigned type to start with. What's the problem that you're trying to solve? I appreciate that e.g. particular image formats are defined in terms of unsigned integers of particular sizes, but parsing binary formats seems like a specialized use case that's not worth distorting the whole language over (and it already involves fiddling with endiann…

> parsing binary formats seems like a specialized use case that's not worth distorting the whole language over (and it already involves fiddling with endianness, so you can't directly use the "standard" version of a given-sized integer when parsing).

You call it "distorting the language", I call it "exposing the capabilities of every single CPU manufactured in the last 15 years".

> You're begging the question, assuming you have to represent a particular unsigned type to start with. What's the problem that you're trying to solve?

1. Compiling existing C++ codebases.

2. Multiplication and division are not identical for unsigned and signed values. Say I have a memory address on 32-bit (note that this applies equally well to 64-bit) and I'm doing pointer arithmetic. I'd better not be doing a signed multiply, or else values above 2GB will be corrupted!

Re: Goodbye PNaCl, Hello WebAssembly

#310
post #239

Earlier quoted context omitted.

It's reinventing the good part of the JVM (the JIT and the bytecode), better than the JVM (unsigned ints and value types are supported), without the bad parts of the JVM on the Web (the libraries, including the slow graphics stack, etc.) What's not to like?

What do unsigned ints bring to the table? I'd use them in C to avoid undefined behaviour, but that's not a problem on the JVM. Value types sure, I guess, but they don't seem super important. Can't we just make DOM bindings for the JVM and reuse the huge existing library base?

> Can't we just make DOM bindings for the JVM and reuse the huge existing library base?

Almost nobody is asking for this, compared to the huge number of people asking to compile C++ codebases.

Post reply on HN