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

Goodbye PNaCl, Hello WebAssembly

blog.chromium.org

Post reply on HN
Print view View original

311–320 of 352 posts

Re: Goodbye PNaCl, Hello WebAssembly

#311

Post by lmm »

pcwalton wrote: post #309
lmm wrote: post #299

Earlier quoted context omitted.

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, assumi…

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

There are plenty of CPU capabilities that languages don't exploit fully (e.g. most languages won't give you direct access to the carry flag) or only allow you to access via a specialized interface rather than making them a first-class part of the language (e.g. SIMD instructions). This seems entirely normal.

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

I don't really see how this works (pointer arithmetic, not that one should be doing it at all, would generally involve adding or subtracting small offsets to pointers, I can't see any use case where you would want to multiply a pointer?), but in any case it doesn't apply equally well to 64-bit in any practical sense? If you happen to need an amount of memory between 2GB and 4GB or between 8EB and 16EB then maybe using unsigned pointers lets you use a smaller pointer, but that seems like a pretty narrow use case.

Re: Goodbye PNaCl, Hello WebAssembly

#312

Post by willvarfar »

hashhar wrote: post #292
smitherfield wrote: post #208

Earlier quoted context omitted.

It executes (sandboxed) native code directly, instead of requiring JIT compilation to native.

That won't be platform independent though I think. WebAsm can run on ARM as well as x86 and even PPC.

The p in pNaCL stands for "portable".

The basic tech behind it is LLVM IR, which is the same tech Apple Store now uses to target the Watch and future devices.

Re: Goodbye PNaCl, Hello WebAssembly

#313

Post by hisyam »

Vinnl wrote: post #284
hisyam wrote: post #260

Earlier quoted context omitted.

Some devs want to develop js apps without paying/maintaining a server.

Since they're just static files, that should be pretty easy to do :)

Some js apps need to work with database.

eg: I'd like to build an expense tracker with html/css/js/sqlite but I want it to be offline and the user can choose to save their db file in their dropbox/gdrive folder.

Re: Goodbye PNaCl, Hello WebAssembly

#314

Post by lloeki »

cat199 wrote: post #288
afarrell wrote: post #207

Earlier quoted context omitted.

Yes, but the existence of ssh on chrome makes it much much easier to teach a windows user how to try out the linux command line. PuTTY is annoying as hell to help a new person get working and they might not have enough space for vagrant+virtualbox.

PuTTY is annoying as hell to help a new person get working Seriously? There are like 12389127381789 how to guides about how to do it, and it is literally like 3 steps. Do you really think the person who has problems starting putty is going to thrive in a CLI environment?

PuTTY's UI is an ass-backward mess (and that's mildly put) and the fact that you're used to put up with it or that there exists five Knuth's arrows worth of guides doesn't change that. In fact the latter is probably a testimony of it all. I've used it for years, know it by heart, still hate it, and am pretty well served by and versed in the unix terminal universe, TY. PuTTY has been useful for sure but that was by scarcity as there was basically no alternative on Windows for a decade or more.

Re: Goodbye PNaCl, Hello WebAssembly

#315

Post by bzbarsky »

johncolanduoni wrote: post #297
_0w8t wrote: post #261

Earlier quoted context omitted.

I am curious what made it necessary to run NaCl in a different process? I thought the main idea behind NaCl was to allow the same-process native sandboxes.

Probably for the same reason Chrome runs V8 in a different process: planning for inevitable vulnerabilities in the implementation.

Chrome doesn't run V8 in a different process from the page DOM. That's the difference: NaCl/PNaCl _does_ run in a different process from the page DOM, so interacting with the DOM gets complicated.

Re: Goodbye PNaCl, Hello WebAssembly

#316

Post by etatoby »

willvarfar wrote: post #270
traverseda wrote: post #262

Earlier quoted context omitted.

Have you seen the "the birth and death of javascript"? More interestingly it could vastly reduce the cost of interprocess communication to the point where the idea of a process starts to look a bit weird. Want to query a database? Upload a function you wrote yourself for complicated queries like GIS, or let the SQL parser generate the raw wasm on your behalf. Want to authenticate your users, but don't want to deal wi…

cough java was supposed to do all that, right?

Yes, this is my feeling too: Java all over again

Re: Goodbye PNaCl, Hello WebAssembly

#317

Post by sangnoir »

roca wrote: post #271
sangnoir wrote: post #265

Earlier quoted context omitted.

> Why not try to help create a standard instead? They do that as well, it's not one or the other. Google had employees working on WebAssembly (along with Mozilla, Apple and Microsoft). Standards take time to be developed and finalized.

Google had a lot of people working on NaCl and PNaCl for a long time before they started working on WebAssembly.

> Google had a lot of people working on NaCl and PNaCl for a long time before they started working on WebAssembly

That's probably because NaCl(2011) and PNaCl predate WebAssembly (announced 2015). Google was optimizing Chrome for asm.js as far back as Chrome 28 (July 2013) - less than 5 months after asm.js was announced.

Re: Goodbye PNaCl, Hello WebAssembly

#318

Post by traverseda »

willvarfar wrote: post #270
traverseda wrote: post #262

Earlier quoted context omitted.

Have you seen the "the birth and death of javascript"? More interestingly it could vastly reduce the cost of interprocess communication to the point where the idea of a process starts to look a bit weird. Want to query a database? Upload a function you wrote yourself for complicated queries like GIS, or let the SQL parser generate the raw wasm on your behalf. Want to authenticate your users, but don't want to deal wi…

cough java was supposed to do all that, right?

It seems like a lot of people were simply unwilling to support java. Bundling the execution enviroment with such an un-fun language was probably a mistake. Not to mention the patents and oracle in general.

It was before my time, but I don't imagine the open source community was ever going to really embace it.

Re: Goodbye PNaCl, Hello WebAssembly

#319

Post by sangnoir »

roca wrote: post #213
sangnoir wrote: post #212

Earlier quoted context omitted.

> Google wasted huge resources on an approach which it was obvious from the beginning would never lead to a Web standard Google has been doing this for a long time, I doubt it's unintentional. If there is functionality that they want which is not standardized, they go ahead and implement it. When a workable standard is ready or detailed enough, they switch over to it. The earliest instance of this that I can recall w…

Sure but the asm.js/Wasm approach was always an option. They didn't have to go down the path they did.

NaCl predates asm.js/Wasm by 2 years: it wasn't always an option

Here's a timeline:

  2011-10-16: Native client released
  2013-03-21: asm.js released
  2013-06-25: Firefox 22 released with asm.js support
  2013-07-17: Chrome 28 released with optimizations for asm.js
  2015-06-17: WebAssembly released
  2017-06-30: Google announces switch to Wasm.
When do you think was a Good time for Google to switch tracks?

Re: Goodbye PNaCl, Hello WebAssembly

#320

Post by pcwalton »

lmm wrote: post #311
pcwalton wrote: post #309

Earlier quoted context omitted.

> 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, assumi…

> You call it "distorting the language", I call it "exposing the capabilities of every single CPU manufactured in the last 15 years". There are plenty of CPU capabilities that languages don't exploit fully (e.g. most languages won't give you direct access to the carry flag) or only allow you to access via a specialized interface rather than making them a first-class part of the language (e.g. SIMD instructions). This…

> There are plenty of CPU capabilities that languages don't exploit fully (e.g. most languages won't give you direct access to the carry flag)

Sure they do: the carry flag is the > operator.

> or only allow you to access via a specialized interface rather than making them a first-class part of the language (e.g. SIMD instructions). This seems entirely normal.

So if you want to argue that unsigned multiplication/division should be encoded as a magic intrinsic (as Java 8 does) instead of as a primitive operation, then I still think it's a bit silly to make such common operations require such verbose encodings, but I could be convinced either way.

> pointer arithmetic, not that one should be doing it at all

The point of wasm is to be a compilation target for languages like C and C++. So pointer arithmetic is very important here.

Post reply on HN