dherman

Agreed! In fact it would also be useful in Node: you could build an almost-full-performance but portable version of a native module as a fallback for clients who don't have the requisite software to build a Neon library (say, one they only indirectly depend on) on their machine.

Eat my dust! :P

Watching Christmas movies with the family right now but I'll file a bug with some hints later. :)

Yeah, that's all, just crawling before I walk. Lots of work to do, and very excited to welcome contributors and collaborators!

Fun :) Back in my Racket days (back then it was known as PLT Scheme and dinosaurs roamed the web) I did a similar thing:

http://planet.racket-lang.org/package-source/dherman/javascr...

The Javadot notation was really convenient -- might be worth checking out:

http://jscheme.sourceforge.net/jscheme/doc/javadot.html

I agree it doesn't make sense for Servo to be a drop-in replacement for Gecko, but that doesn't mean we shouldn't bend Firefox towards compatibility with Servo. A future Servo-based Firefox is far enough off that it's impossible to predict every step from here to there, but if you ask me, dcamp's email is on the right track: we should evolve Firefox away from dependence on non-standard tech like XUL, XBL, and XPCOM and towards self-hosting on standard web technology and taking full advantage of everything Servo has to offer. What that looks like in practice remains to be seen.

(Director of Strategy for Mozilla Research here.)

pdf.js was the brainchild of Andreas Gal, now our CTO but at the time a cofounder of Mozilla Research along with Brendan Eich and me. That project started briefly in Research but was shepherded to product pretty quickly.

Shumway is a separate project but similar in spirit. It's not a converter per se, but rather an emulator including a full ActionScript Bytecode (ABC) JIT, implemented in pure JavaScript. Right now we are interested in getting Shumway to the point where it can be used in Firefox as an alternative to the native Flash plugin for certain kinds of web Flash content, to provide better security, stability, and performance. Over time as Shumway matures the ultimate goal would be to eliminate the need for the Flash plugin entirely, but we'll walk before we run.

But Shumway is usable as a standalone project as well, and others have begun taking notice. For example, Prezi has invested in Shumway as a library for rendering vector graphics:

https://medium.com/prezi-engineering/how-and-why-prezi-turne...

Announcement and details are here: http://blog.rust-lang.org/2014/11/20/Cargo.html

The float taketh away and the clear: both giveth back again:

http://pcwalton.github.io/blog/2014/02/25/revamped-parallel-...

The downside of picking subtler, more intricate examples is that you waste your reader's time trying to understand the subtleties of the example, which isn't teaching them anything about Rust.

Another option is to say something like, "For the sake of brevity, this is a very simple and arguably obvious violation of safety. In practice, there are many subtle and hard-to-diagnose sources of unsafety in C++, even when you use safer abstractions like shared_ptr." This allows you to avoid getting sidetracked and losing your reader, while heading off skepticism of readers with more knowledge about C++.

Agreed, and happily sweet.js is very consciously modeled after Racket.

Diverging from JS would require standardization, but it's too early to consider something like that. I don't know what our ultimate plan for threads will be or where asm.js will eventually end up; there are plenty more discussions to be had.

Yes, threading is definitely the main challenge for asm.js. I'm not as pessimistic as you about it, though. :)

I also want to add that the "it's just JS" thing is not somehow an argument of the shining nobility of asm.js. It's purely practical as what we believe is a viable approach to moving the web in the same direction that e.g. the PNaCl team has been trying to move it. I get so disheartened at these mud-flinging contests. Our companies want the same things for the web (and we <3 the PNaCl team and have friendly conversations with them!). We share the same goals. We just believe that asm.js is a more viable approach to getting the web there.

> My statement was correct. It's not JavaScript, which is why you use a keyword to switch to a different compiler mode.

I'm afraid your statement really wasn't correct. asm.js is both syntactically and semantically JavaScript. OdinMonkey is a pure optimization; any observable divergence in behavior (other than timing, which of course all engines are allowed to do) is a bug that will be fixed. The fact that SpiderMonkey uses a prolog directive (not a keyword), which is also of course valid ECMAScript, to trigger a different kind of optimization does not change the fact that it is a valid implementation of JavaScript.

If you need any help with that, don't be shy to jump on #rust on irc.mozilla.org. The team would be happy to answer any questions you may have along the way.

I think you're mixing up tail recursion with general recursion. Rust absolutely supports recursion: the implementation uses segmented stacks to allow for stacks to grow dynamically. Tail call support is about not having the stack grow but only in the subset of recursive calls that are in tail position.

So support for tail calls is not about safety but expressiveness, and Rust chooses to express iterative algorithms through other means, such as the iteration protocol that's built on top of higher-order functions.

EDIT: Maybe I'm misreading you and you only mean the imperative nature of loops forces you to use mutation. Rust does not eschew mutation altogether. Even as a functional programmer myself, I'd argue pretty emphatically that mutation, particularly of local variables, is not a grave safety concern.

We've talked about versioning, and I think feature detection is probably the best approach. If the user agent publishes a list of supported asm.js features via a standard query mechanism (note that this is a feature list, not browser detection) -- e.g., ASM.SIMD === true -- then apps can negotiate content accordingly. This might entail compiling multiple versions of your codebase for various versions of asm.js, but that's an acceptable price to pay for VM evolution, IMO.

Thanks for the erratum report. I always mix those two up! :-/ I've added it to the errata page:

https://github.com/effectivejs/site/wiki/Errata

(Let me know if I got your name wrong for the credit; I followed links from your HN profile.)

Thanks, Dave

Right, that's the idea of FunctionBlob. It wraps a browser-internal representation of the optimized compiled code. The web code can instruct the browser to store that offline, without exposing its implementation-specific details to the web code. The web code can then, in a later session, retrieve that optimized code from storage as another FunctionBlob, which it can then convert into a Function. This is no different from just storing the asm.js source code in offline storage, except it avoids redoing the work of compiling and optimizing the source. (It'd still have to be stored in position-independent format and there might be some back-patching necessary when reloading it.)

Yes, absolutely. When we first started talking about the project I seriously considered designing a "disassembly" syntax, to make it easier. We can still do that pretty easily, it's just taking a bit of a back seat to getting v1 of the spec and Odin implementation out the door.

> It's rather indicative of Mozilla's approach to life, namely, write everything in JS out of some pseudomasochistic desire for backward compatibility hacks.

I'm just trying to make progress in a messy world. JS is not my ideal programming language (even though I've worked hard to make it better 7 years now (!) and counting). I simply believe asm.js has a good adoption/evolution story, and I want to web to continue growing and competing.

> The semantics of JS are pretty horrible too.

A cheap shot, and missing the point. The subset of JS, while being completely equivalent to JS semantics, is also equivalent to a low-level machine model. IOW, it gives you the semantics of a low-level but safe VM.

I was only thinking that it would be internal. Your server point is good, but I think way, way harder, and kind of starts the whole project back at the beginning: how to design a standard, efficient, optimized bytecode format. So I think it's probably not really feasible.

Not the same, but an additional optimization you can do is incremental compilation. Because you have JavaScript's eval, you can download the code a bit at a time and optimize (and cache via FunctionBlob) each piece.

> I want my bytecode to look like this: `iadd`, NOT `(a+b)|0`.

So build a front-end! I actually thought about doing this myself, because I knew we would get people confused about the difference between syntax and semantics. The syntax is not important to the computer, and it's generally not important to a compiler either (codegen can output whatever format it wants).

Note that the bytecode for the JVM and CLR, for example, don't look like `iadd` either. They're binary encoded formats. The format is just not relevant.

> Maybe I'm just old fashioned, but running bytecode through a text interpreter, which is then compiled again to machine code (possibly via another bytecode) seems like a horrific hack.

Never has to pass through an interpreter at all. It does not pass through an interpreter in our implementation.

You seem to be very hung up on surface syntax. The importance of a VM is not the syntax of its language but the semantics.

We have plans!

First of all, we do care very much about supporting compilers for managed languages like Java and C#, but we're starting with this first version that only supports zero GC and atomic primitive types. We have plans to grow outwards from there to support structured binary data, based on the ES6 binary data API, and controlled interaction with the GC. Luke has ideas about how to do this without losing the predictable performance for lower-level compilers like Emscripten.

We do have plans for startup time. I hope to pitch a very small, simple API for a kind of opaque compiled Function. Internally we've been calling it FunctionBlob (we'll bikeshed the name later). The idea is that `new FunctionBlob(src)` is almost identical to `new Function(src)` except the object is (a) an opaque wrapper that can be converted to a function via `fblob.toFunction()` and (b) entirely stateless and therefore compatible for transfer between Workers as well as offline storage. This would essentially make it possible to do things like background compilation of asm.js on a Worker thread, and caching of the results of compilation in offline storage. That way next time you startup you don't have to download or optimize the source. (This could work especially well with the app experience where you could perform these download/optimize steps as part of the installation process.)

As for the use of JS, this is purely pragmatic. The code works today in browsers, so people can start using it and it works -- and even quite fast; Emscripten is already shockingly performant in Firefox and Chrome -- but over time it'll see better and better optimization.

What you're asking for is drastically harder to achieve from a security perspective. If we didn't care about security, we could just standard the Linux syscalls or something and call it a day. :) But what we're doing here is providing the low-level computational model but still only providing attenuated access to system facilities like the network through standardized web API's.

There are good and bad things about PNaCl. But overall, the resistance to PNaCl goes beyond Mozilla -- it's a really hard standardization/synchronization problem. Our goal with asm.js was to produce something that could work today (because it's 100% compatible with existing JS semantics) and work even better tomorrow as engines optimize it even better.

Edit: Re: predictable performance, that's exactly what asm.js is about. The performance model is much closer to that of C or PNaCl/LLVM.

The code has to be explicitly marked as asm.js, using a pragma similar to ES5 strict mode. This way if the code fails to validate, the errors can be reported to the browser's developer tools.

As for debugging, the story is the same as Emscripten. I believe there's plenty of work to do to make it better, but it's no different than the existing state of affairs. All we're doing is formalizing existing practice so that engines can capitalize on it and optimize better.

That's true, but JoshTriplett has a reasonable point. In point of fact, we are discussing custom value types like int32 and uint32, as well as compound value types like immutable records, for the future of ECMAScript:

http://wiki.ecmascript.org/doku.php?id=strawman:value_object...

But standardization takes time, and we wanted to get asm.js working now.

In the future if ECMAScript gains these other features we'll happily incorporate whichever ones make sense. For example, if having more straightforward syntax can help decrease code size that's a clear win. (Though gzipping source tends to mask a multitude of sins.)

It's a lot harder to add types to a general purpose programming language. Your types have to match actual programming idioms, and if you care about them being safe (which, to be fair, recent languages like Dart and TypeScript don't), you have to consider every possible loophole that could lead to a dynamic error -- and the legacy language fights you, because all of its dynamism was designed back when nobody was thinking about respecting some not-yet-existent type system.

The type system for asm.js is a far more restricted problem, which is why we were able to come up with a solution so quickly (we only started this project in late 2012). The type hierarchy is extremely spartan, and it's just designed to map a low-level language (intended for compilers to be writing in) to the low-level machine model of modern computers.