111–120 of 238 posts
On one hand, I'm excited about performance improvements. On the other, I lament the fact that this will kill one of the best parts of the web: the fact that the source is sent to the end user instead of a binary. It now makes the code and how it works opaque, thus killing the spirit of innovation and learning.
https://github.com/WebAssembly/design/blob/master/TextFormat...
When compiled from C/C++, does WASM do bounds checking of pointers and arrays? What kind of memory safety does it offer?
The linear memories, on the other hand, are up to you - you can execute operations on address within a linear memory, and it's up to you if you messed up and overwrote or read out data that you shouldn't have. What you do get is a) protection against heap overflows affecting values outside the heap, and b) protection against execution of heap data. In the future, they're also planning to support multiple linear memory segments, which would allow you to isolate memory used for potentially-buggy dynamically-allocated buffer code from memory used by less-fragile or more-sensitive code. WebAssembly.org's descriptions indicate that linear memories would be used both for C/C++ heap allocations and for any local/global variables accessed with operators (like the & reference operator) that make it hard to make these distinctions statically.
More information on the security properties of the system: http://webassembly.org/docs/security/
General information on linear memory semantics: http://webassembly.org/docs/semantics/#linear-memory
Earlier quoted context omitted.
You're unnecessarily constraining your thinking to the present-day Web. WASM fundamentally expands what's feasible in that domain. For instance, access to the DOM doesn't really matter for game engines like Unity or Unreal, or for lower level libraries like OpenCV, libsass, or libarchive which you might want to use in your web application. No one is arguing that WebAssembly will completely replace JavaScript, especia…
> For instance, access to the DOM doesn't really matter for game engines like Unity or Unreal My point was who wants these to be in the browser? I mean they're cool as demos, but I don't see the use. Is it just people using web browsers as the content delivery platform instead of e.g. Steam?
Anybody that resents the user having ultimate control over the User Agent. A game in e.g. the Unity engine isn't important. Instead, there are a lot of people that would love to replace their (easily adblockable) web page with a small opaque binary that contains freetype, custom layout/UI library, and maybe "drm"-like obfuscation. You don't need the DOM if you intent to render everything yourself.
At best, we will see a new wave of "flash intro"[1] style "custom user experience" replacing perfectly usable HTML pages. At worst, this could be the catalyst that replaces what remains of the open web with a locked down "cable tv"-like mess.
Earlier quoted context omitted.
> This is our one chance to kill javascript; if we don't do it now, it'll be entrenched forever, and best we'll ever get is 'compiles-to-js' languages like clojurescript and typescript. Do people really hate JavaScript that much? I've grown fond of it in recent years, especially after ES6.
Yes. People really hate JavaScript that much. ES6 brought some sanity to the language, but I continue to be firmly in the camp of continuing to hate and despise its existence.
Granted, that was back in 2008 and most of my complaints have been addressed now almost a decade later (except for destructors, it still doesn't have those, but I also don't need them anymore).
These days I move between JavaScript, Python, Go, and C seamlessly and I can honestly say that I don't hate any of them as much as clients, managers, and 3rd party code.
[1] http://davywybiral.blogspot.com/2008/01/javascript-bad.html
Earlier quoted context omitted.
> it's far from inconceivable that PGO could be applied to the intermediate code that web assembly effectively is. A developer could do some kind of PGO before he produces the final binary, I can imagine that. But then it's still just a static binary. And I personally can't imagine PGO being done in the user's browser and not being slower than the alternative of not doing it, just like I've never heard of some OS whi…
Java does PGO on every server running Java in the world. Even some swing apps benefit once you get it started up.. That said, I'm not sure the full JVM is coming to browsers anytime soon.
Java VM receives the classes, methods, strings, has GC and all that, but it has to JIT to reach that lower level to be efficient and has to do a kind of establishing what's actually used, similarly to what tracing JIT engines for classic JavaScript do.
I believe that kind of run-time measurements and then code generation and optimization is what some Java people call PGO, and what asm.js at the moment intentionally (by design) avoids.
In short, Java's PGO on the user side is not what PGO for static languages like C is (by the developer). And asm.js is even lower than C. It's really closer to... asm.
Exactly because asm.js avoided these decisions was Firefox with asm.js support faster than Chrome at the time the later treated all js code the same.
Earlier quoted context omitted.
You still have to ferry data in and out of Javascript to interact with the page. In the long-term, maybe language-specific bindings to interact with DOM APIs will become popular, but otherwise to get anything done in most cases you're probably going to expend enough effort on ferrying things in and out of JS land to negate the possible benefits of not needing to deal with a different language. I'd be surprised if man…
Can someone explain what the option is for accessing the dom initially? Is there some wrapper JS that will be needed to call into the wasm?
Earlier quoted context omitted.
> something else that offers native bindings to other languages will eventually... No it won't. This is our one chance to kill javascript; if we don't do it now, it'll be entrenched forever, and best we'll ever get is 'compiles-to-js' languages like clojurescript and typescript. Let's be realistic; who has the man power, community good will and business savvy to push an entirely new language across all platforms, mob…
> This is our one chance to kill javascript; if we don't do it now, it'll be entrenched forever, and best we'll ever get is 'compiles-to-js' languages like clojurescript and typescript. Do people really hate JavaScript that much? I've grown fond of it in recent years, especially after ES6.
Earlier quoted context omitted.
Yes. People really hate JavaScript that much. ES6 brought some sanity to the language, but I continue to be firmly in the camp of continuing to hate and despise its existence.
Weird. I remember hating it ages ago. So much so that I was developing a Python->JavaScript transpiler (before all the cool kids were writing transpilers!) and blogging about how bad it was [1]. Granted, that was back in 2008 and most of my complaints have been addressed now almost a decade later (except for destructors, it still doesn't have those, but I also don't need them anymore). These days I move between JavaS…
I would never debate that. I think language choice for many people is a personal decision. There are some that I will hold my nose and use; not even complain too much. There are others that the minute there is an alternative to, I would use that instead. JS is in the latter camp for me.
If it helps, my current favorite language is Rust... they may be syntactically similar, but I just can't stand the semantics, or lack there of, of JS.
When compiled from C/C++, does WASM do bounds checking of pointers and arrays? What kind of memory safety does it offer?
Earlier quoted context omitted.
> something else that offers native bindings to other languages will eventually... No it won't. This is our one chance to kill javascript; if we don't do it now, it'll be entrenched forever, and best we'll ever get is 'compiles-to-js' languages like clojurescript and typescript. Let's be realistic; who has the man power, community good will and business savvy to push an entirely new language across all platforms, mob…
> This is our one chance to kill javascript; if we don't do it now, it'll be entrenched forever, and best we'll ever get is 'compiles-to-js' languages like clojurescript and typescript. Do people really hate JavaScript that much? I've grown fond of it in recent years, especially after ES6.