jfbastien

10 ms·

61.
by jfbastien 11y ago
JS isn't going anywhere. wasm and JS are a dynamic duo, complement each other.
62.
by jfbastien 11y ago
C Python and Ruby should "just work" because you can compile their GC into you wasm module. More general-purpose GC will be supported, but not in the initial release: https://github.com/WebAssembly/design&#x2F
63.
by jfbastien 11y ago
Everyone on V8 would disagree with you :-) Type tracing in particular is the big win, and with a dynamic languages you simply can't prove enough to do it ahead of time. There's also startup time that you're paying with AOT an
64.
by jfbastien 11y ago
"ridiculously easy": https://github.com/rust-lang/rfcs/issues/604
65.
by jfbastien 11y ago
Transpiling some dynamic languages to JS is still sensible. WebAssembly is initially for static languages, and eventually (with JIT and GC support) it'll be usable as a building block to host dynamic language VMs.
66.
by jfbastien 11y ago
It should "just work", but we're still at the experimental stage right now so it may break randomly. It's not production quality yet, but mobile is a first-class platform for launch.
67.
by jfbastien 11y ago
WebAssembly has its own semantics, similar to asm.js (statically typed) but much cleaner because it doesn't need to map onto JavaScript.
68.
by jfbastien 11y ago
Correct, though we're working on dynamic linking to ease the pain, and improving compilers such as LLVM so that the generated code is smaller.
69.
by jfbastien 11y ago
Python is just another language VM. C Python should work just fine in WebAssembly, and bridging the APIs to the web (e.g. filesystem, etc) is already possible through Emscripten. We don't plan to do things for WebAssembly, we plan to m
70.
by jfbastien 11y ago
When WebAssembly is further along the capabilities of PNaCl should be polyfillable to WebAssembly, and it would then make sense to ship one fewer VM. Otherwise NaCl and PNaCl have a solid track record of running code near native speed in an
71.
by jfbastien 11y ago
Software isn't free because you can see its source. JavaScript is no free-er, and no more view-source-able when minified, than WebAssembly is. View-source is an explicit goal of WebAssembly's first launch: https://git
72.
by jfbastien 11y ago
"In development": https://webkit.org/status/#specification-webassembly
73.
by jfbastien 11y ago
Right: direct hardware support can't be beat. Once WebAssembly has solid SIMD support and memory management that allows zero-copy then it should be* as good as it gets without direct hardware support. * Assuming we're smart about
74.
by jfbastien 11y ago
There are a lot of papers to follow, unfortunately. Listed here: http://open-std.org/jtc1/sc22/wg21/docs/papers/2014/ http://open-std.org/jtc1/sc22/wg21/doc
75.
by jfbastien 11y ago
You're thinking of C++'s "executor", which is currently being discussed for addition to the standard. The parallel STL will use the executors once they're added to a technical specification. There's agreement o
76.
by jfbastien 12y ago
I discussed this with Alon on IRC: you wouldn't use pepper to do this. NaCl doesn't imply pepper, you can expose a subset of syscalls into the trusted code base. I understand the feeling about DRM, but given that sandboxed DRM is
77.
by jfbastien 12y ago
Sorry, I don't check HN often. As we discussed on Twitter & IRC: It's just an OS sandbox currently. pdfium previously worked with NaCl, with a non-V8 JS VM (work done by Bill Budge). V8-on-NaCl used to work, I think it may hav
78.
by jfbastien 12y ago
The DRM sandbox is yet another attack surface, isn't it? Wouldn't it make sense to use NaCl for DRM sandboxing, and then the option is open to use the same sandbox for PDF viewing, and pdf.js can still work, giving users choice. C
79.
by jfbastien 13y ago
Oh I see your point on being a proper fit. It's not much of an argument then, since you're just saying that making it work when it wasn't quite designed for that use is hard, but we did make it work. So I agree :-) I also wis
80.
by jfbastien 13y ago
I think quoting Dan's email repeatedly is entirely unhelpful, I'd appreciate it if you wouldn't to that. We've actually addressed every single point in Dan's email, talked to Dan repeatedly, and gone beyond what he
81.
by jfbastien 13y ago
I think you're conflating frontend and back end. As they currently exist both asm.js and PNaCl frontends are LLVM, if just because it's a good C/C++ solution to parse and optimize. The backend is indeed an LLVM subset as of t