That's not really true. Erlang's VM is fantastic at GC with thousands upon thousands of green processes multiplexed onto the system threads, allowing soft realtime performance. Similarly, Haskell's Parallel Strategies library works well with the Parallel GC. Immutability makes this a whole lot easier.
Erlang uses only actors as concurrency mechanism and exploits that fact by giving each actor its own heap. So Erlang's GC does not need to accommodate concurrency, even though Erlang itself does.
To OCaml in particular, and you're right that immutability does make it much easier, but OCaml has mutable variables, which is precisely why it's hard.
Menlo Park, Ca - Full time - Frontend, Backend, Dev Ops, ML/AI
Blackbird is a stealth, ventured backed, artificial intelligence technology company focused on solving some important challenges created by the shift from desktop to mobile. Our stack is primarily in functional style Scala (we are heavy functional programming users) with most of our AI stack in Python and C++.
We're one of a few startups that do AI research above and beyond product development. We host regular talks on multiple disciplines ranging from systems to functional programming to deep learning.
The team was founded by former Stanford CS graduates that built self driving cars, search at Google and Yahoo Research, co-authored the google file system and scaled Twitter to 200 million users. Our open source code powers Snapchat, Tumblr, Wikipedia in production today.
We're currently looking to add some great engineers to our team. Have a passion for AI/ML and want to work with the bleedingist of edges? Want to write highly scalable software with the architects who scaled Twitter and Google? Want to run ops for software which is designed for fault tolerance? Want to design next generation user interfaces? jobs at blackbird.am
Blackbird is a stealth, ventured backed, artificial intelligence technology company focused on solving some important challenges created by the shift from desktop to mobile. Our stack is primarily in functional style Scala (we are heavy functional programming users) with most of our AI stack in Python and C++.
We're one of a few startups that do AI research above and beyond product development. We host regular talks on multiple disciplines ranging from systems to functional programming to deep learning.
The team was founded by former Stanford CS graduates that built self driving cars, search at Google and Yahoo Research, co-authored the google file system and scaled Twitter to 200 million users. Our open source code powers Snapchat, Tumblr, Wikipedia in production today.
We're currently looking to add some great engineers to our team. Have a passion for AI/ML and want to work with the bleedingist of edges? Want to write highly scalable software with the architects who scaled Twitter and Google? Want to run ops for software which is designed for fault tolerance? Want to design next generation user interfaces?
It's a huge issue on mobile. Multiple rendering engines requiring the world to write software to a spec is what prevents people from writing code dependent on a particular browser or, in this case, a rendering engine. You see it all the time in the mobile web: plenty of sites just plain don't work when using other rendering engines.
And the fact that web developers then actually can't develop just for one rendering engine and claim that "it's enough" is a very good thing for me. I refuse to use Chrome and I'm extremely hit by all the sites developed "for Chrome only" on the desktop. The web shouldn't be "what's on the developer's machine and not more."
Located right outside Stanford University in Menlo Park, CA, Blackbird is venture-backed startup founded by a team of Stanford CS Alumni who've previously built search at Google and Yahoo, and scaled Twitter to 200 million users. Our product is at the intersection of Information Retrieval, Natural Language Processing and Computer Vision and we're currently in stealth.
Role - UX Architect, Menlo Park, CA
- Design and implement UX for our flagship product and take on a leadership role
- Opportunity to invent new interfaces on mobile for something people use everyday
Experience
- Excellent Javascript, jquery, CSS, and HTML skills
- Comfortable with frameworks like backbone.js, ember.js etc
- Some basic experience with with design photoshop/illustrator is a plus
- Familiarity with ios/android programming is a plus
We'd love to hear from you! Please email us at stanfordfounders2014@gmail.com with a link to your linkedin profile or resume. Thank you for your consideration!
It's amazing how fast you can go when you don't care about safety ;)
That said, for all non trivial work loads, the latest postgres is quite the work horse, but of course requires some tuning for performance. We ended up switch to it after MySQL consistently sucked on smaller joins.
Can't argue on the replication deal: it's a work in progress.
An important realization I made a while back was that design methodologies do little to address program correctness, which is almost always the wildcard on deliverables; buggy software means missed deadlines and budget. Some, such as TDD, work to address the rapid building of tools to a particular spec, but often fail to promote static guarantees, especially in languages and environments where such provability is largely impossible. Dynamic languages penchant for monkey (guerrilla) patching further exacerbates the problem.
Solutions to this are tough. My first suggestion would be to use languages which facilitate correctness, although it's usually at the expense of developer availability: the pool of engineers with experience and know-how in true FP is orders of magnitude smaller than more pervasive languages. My second thought is to further embrace math as the building block for non-trivial applications: mathematical proofs have real, quantifiable value in correctness. I find it no surprise that the larger companies have made foundational maths, such as category theory and abstract algebra, the underlying abstraction for their general frameworks. This is even a tougher pitch than the first since most engineers don't recognize what they're doing as math at all - a big part of the problem. So many of us are doing by feel what has already been formally codified in other disciplines.
I'm aware that both require more (not necessarily formal) education than most engineers have pursued and makes it a difficult short-term pitch point for any company, but I think if we're serious about eliminating sources non-determinism from projects, it's important we address them directly.
I think that's one aspect of the problem, but the migration from make-do to mathematically rigorous code can be equally fraught with peril. While the code itself can be made predictable, and easy to reason around, the time estimates and project planning often cannot. There is never enough time to factor out all of the commonality, remove all of the unnecessary use of state, codify all the assumptions into data types, etc., so you have to pick your battles.
A programmer needs intuition of what the biggest, most effective improvements are on the code base, which allow them to get the most work done. They also need some ability to guess how much time it will take, so that they don't miss deadlines. No amount of static type analysis will fix that.
Ah, but that's a matter of design - except now we have strong constructs from which to consider our problem. We will never get away from developing the architecture of our system, which is cost dependent on how well understood the domain is. Ideally, that's where we should aim to move: problem specifications that render implementations rote. A lofty goal, I know, but within closer reach every day and possible in many environments already.
Part of the beauty of proof is that so long as it is correct, the individual lemmas are largely irrelevant: we don't necessarily need to remove commonality or statefulness. Of course, I'm purposefully glossing over extra-functional requirements on which, outside of big-O, we don't have a firm grasp.
I'm attempting to stay away from "effective" or "most work done" since they're ill defined and highly subjective but rather focus on measurable changes. I'd argue that, amortized, the upfront costs of better understanding the problem definition results in cost savings down the line, especially as it recedes into maintenance.
The dark side proof is that most mathematical problems are incredibly contrived. Taking a business requirement and translating it into known mathematical problems is harder than it sounds. Once you can do that, you're 90% of the way there, and people who can do that reliably are regarded as geniuses.
But most of the time, development is done without full understanding of the problem space. Usually, the problem doesn't become fully understood until you've already spent a good amount of time coding up your solution. If you wait until you fully understand the problem before starting, then you'll never start, because your brain simply can't comprehend the entire scope.
So instead, you get code bases full of sort-of well-factored code, but with lots of unwittingly reinvented wheels. This status is occasionally improved when somebody really smart happens to notice the commonality, and remembers a classic problem that it resembles, and manages to refactor the entire thing using the general solution. However, this almost never becomes apparent during the first revision.
"I find it no surprise that the larger companies have made foundational maths, such as category theory and abstract algebra, the underlying abstraction for their general frameworks."
I would like to learn more; do you have a specific example?
Having worked with real "engineer" engineers, I've found that they have, and value, a considerable amount of mathematical education, but that education is all in continuous mathematics; abstract algebra and formal logic have about the same amount of respect as basket weaving. Unfortunately, continuous math isn't particularly useful for software.
As an electrical engineer who briefly flirted with computer engineering, I had 4 semesters of continuous math and 1 semester of discrete math[1]. I also had classes like linear systems and electromagnetics where I had to actually use continuous math heavily.
While I do not think continuous math is particularly useful for general software development, I think it is very valuable for specific problem domains. I have found my Calculus/DiffEq foundation to be very valuable for my work with radar signal processing and NLP code, more so in the former because it was basically translating electrical engineering algorithms, formulas, and concepts into C. It is also important for any type of development that makes heavy use of geometry.
As a side note, I saw some of the bias you describe out of the more "pure" EEs I worked with when I first started. There was a strong bias against software engineers, particularly those who went the CS route, because they didn't understand the math and physics behind the hardware. Admittedly, some were clueless and probably should not have been writing software for multi-million dollar hardware[2]. Most were competent, though, and able to pick up the basics they needed to know when tutored for a bit.
[1] Which was actually titled "Discrete Mathematics", and was just covered basic set theory, combinatorics, and linear algebra.
[2] Like the one who added a reset routine that blindly opened power contacts on the UUT without verifying that the power supplies were off first. Fortunately, that was caught before they actually opened with hundreds of amps going through the bus.
As you say, continuous math (to my mind, calculus, diffeq, and linear algebra; anything involving reals) is necessary for some problem domains. But accounting is necessary for some problem domains as well. And molecular biology.[1]
But if I get worked up into a good froth, I can make a case that software development is applied formal logic or applied abstract algebra (or both). I don't believe you can do professional software development (in Weinberg's sense) without some serious discrete math, in the same way you can't do signal processing without calculus.
[1] If you've got something that mixes the three, let me know. It's probably something I should stay away from.
I must admit to ignorance of Weinberg's books and other writings. My interest is piqued now, though.
That said, based on your second statement nearly all scientific and engineering programming would not qualify as "professional software development". The code I worked on had little to no discrete math or formal logic in it. There was not an integer to be found save loop counters and array indices Do you not consider an (electrical engineer | mechanical engineer | physicist | molecular biologist) who can code and spends the vast majority of their time writing production code like this a professional software developer?
Two good examples from the Scala community would be Algebird[1] from Twitter which uses Monoids as a main abstraction and Spire[2], which might be the best numerical library out there and heavily rooted in Abstract Algebra.
I considered editing my other comment but decided instead to break it out.
There are a couple of complexities that your comment illustrates well:
First, continuous math _is_ available and immediately applicable today. The problem is that we often reason in and program to the implementation, not the abstraction - a subtle difference, but an important one. Not only that, but by reasoning in a flawed representation, we often miss important derivations that result in dramatic simplifications and reductions in the problem domain. I would also argue that we already do use continuous math regularly - for example, linear algebra, combinatorics, and set theor: most of us only know them as arrays, random, and SQL.
Secondly, not enough effort is made in formal education for applying 'pure' math to computer science. Some branches, such as linear algebra, have obvious implementations and analogies already available but others are quite a bit less clear - I fault this more on curriculum silos than an engineer's innate abilities. It's a learned skill that just isn't often taught.
I think modern software engineering really needs to start banking on provable languages with strong type systems. Instead of hoping and testing with Monte Carlo sims, let's prove an algorithm once as correct and move on from there.
More provable code is not the answer. Proving the functionality is meaningless if you can't decide on what the functionality should be. And this project has all the classic hallmarks of a requirements quagmire. The requirements are poorly specified and contradictory, and provable code and strong typing can't solve that problem.
Indeed, it makes the problem worse... the strong typing and provable code stubbornly insist that the requirements are contradictory and refuse to even compile. But managers don't want to hear that, of course, so we go back to the dumber languages that happily compile even so. This does not make the requirements any less contradictory of course... it just means that the dumber languages will let you blithely code on, and are guaranteed to do something stupid at run time instead. Progress!
Engineering is systematic approximations and best-guessing. The art of it is knowing when shortcuts are good enough.
Only very small parts of software can be proven, especially for things like flight control, where the parameter space is huge, and exhaustive search or manual formal proofs are impossible. Not even speaking of the fact that the spec against which one could build a proof is never error-free to begin with.
And what in your opinion is the difference between "systematic approximations and best-guessig" and "knowing when shortcuts are good enough"?
For me engineering is using proven and tested solutions every time, even if the solution is not sexy, and art is just "swinging it" - just like using js for everything when they are better more mature solutions.
Since you're not building the same thing every time, you don't have wholesale proven and tested solutions for everything. The engineering part is going about filling the gaps systematically, and figuring out what parts require closer inspection in the first place.
In my opinion, this last part is the art, figuring out what to do when you tread a new path. A good engineer will find the critical parts, but that relies on as much intuition as process. A really good engineer will find the meta-mistakes in the process.
The decision to "swing it" can be an engineering decision. If I am doing something I did before, and all the parts fit, I can swing it, and forego a tedious process. I have to balance the risk of implementation delays and bugs vs. spending time on simulation and paperwork.
It's also perfectly possible to do everything by the book and still fail, if the process is a bad fit, or you run out of time because you're all caught up in following procedure instead of taking common sense shortcuts.
So either swinging it or doing it by the book can be engineering or idiocy, depending entirely on the situation, and, in retrospect, the outcome.
A lot of things, like nonlinear control systems, can only be verified by Monte Carlo methods. Subsystem failure tolerance is difficult to handle by any existing theorem prover.
The JSF software organization uses static analyzers heavily. They are using theorem provers.
You could, you know, pay for a subscription. If you're bumping up on the limit of free articles per month, you're clearly getting some value from the paper. There are worse things than supporting good journalism!
The NYT is executing a decade-long return to payment-based reporting. The early parts include easy-to-circumvent paywalls so that they can have some price discrimination [1] while also setting the social norms that payment is expected for web content. The later stages will likely include more rigid restrictions on content -- but that will only fly once "pay to read" is something people expect from expert content on the web, rather than are surprised by.
Let's make no mistake about it: Javascript has been a multi-billion dollar focus by several top-tier engineering companies for almost two decades. It's more accurate to say that Javascript has succeeded despite its limitations.
There's no denying that the PNaCl is a superior approach, and if we were starting from square one would be the smarter design as well. That said, a well entrenched language supported (and, crucially, maintained) by multiple vendors with loads of developer intellectual investment should win this competition.
> Javascript has been a multi-billion dollar focus by several top-tier engineering companies for almost two decades.
No, that's an exaggeration in time and dollars.
JS was one full-time person, me, till fall 1996, then two. Growth after that was to about eight max, and less than the Java crew at Netscape, until Netscape folded on Java and laid off a bunch of people in late 1997. Call the Netscape investment 8 years x 8 people = 64.
On the IE side, the JScript engine reused a common assembly-coded COM-dispatching indirect-threaded (I think) interpreter, and seemed from what I could tell to take about 6 people, but I'll round up to 8. No LiveConnect and COM based infrastructure saved them compared to Netscape. Ignoring JScript.net in Y2K era, the investment until the IE6 stagnation (skeleton crew) looks like at most 6 x 8 = 48.
Apple did not start with KJS till 2001, I believe. They've always had at most 3 people on JavaScriptCore, they run a tight ship: 14 x 3 = 42.
Chrome started V8 in 2006, as far as I can tell. Lars and a team of U. Aarhus and Google on his farm wrote four versions I hear (good idea: prototype, learn, tear up and rewrite). Call that 2 x 10 = 20 for first two years, then since I think it is more like 5 x 20 = 100.
64 + 48 + 42 + 120 = 274 person-years. Even at $1M/person/year, well high even with Google wealth effect of RSUs (for most; I'm guessing, but an outlier like Lars or Kaspar getting rich does not count; really we should stick to base salary + benefits/burden overhead), that's well shy of "multi-billion".
You can say JS learned from all the JIT research before it. You'd be right, but your statement was exclusive to JS and so excluded that upstream, and fair's fair: that helped other languages who could read the literature and code.
EDIT: Eric Lawrence on twitter reminds me that Chakra has a big team, I hear ~60 heads. That seems to be since 2009. Still well south of "multi-billion", even with my absurdly high $1M/year burdened engineer price.
This kind of post and response, meaningless in the grand scheme of things, is why I come to HN. You never know who will be next to say X sucks and then have someone personally involved in creating X speak up unexpectedly. Makes you want to apologize for saying X sucks in the first place, except you're not because without it you wouldn't get the resulting conversation. ;-) It does make me wonder, what things have I said about somebody's creation and then have them come along and see it. Sometimes it's just hard to remember there are real humans on the other side of this screen. ... And with that, I know I'm up too late. Good night all, and thanks for the post, Brenden. I did want to point out though... You forgot IE 10 and especially 11, plus the fun Opera Mini must have had remotely executing JS for a brief time. But these wouldn't significantly revise the numbers up too much. I'd add Adobe to the mix, but ActionScript and AIR are maybe too far from a browser to count for much evolution in JS terms.
Right, see EDIT for Chakra, and yes, I forgot Opera. Lars Thomas Hansen, then Chris Pine, on LinearB and Futhark; then Jens Lindstrom and (I heard) a small team in Sweden on Carakan.
Also (ahem), I forgot Mozilla in the post-2003 era.
Still, no matter the addenda and the crazy $1M/person-year, nowhere near even $1B.
You never know who will be next to say X sucks and then have someone personally involved in creating X speak up unexpectedly.
So then HN is now the /. of the mid 201X? /. Was at its best when people in the know were finally pissed off enough to chime in and set the hooligans straight.
It does make me wonder, what things have I said about somebody's creation and then have them come along and see it
I passingly wrote some disparaging remarks in a github issue about the ES6 binary data strawman spec written by Dave Herman, pretty much out of my own ignorance, only to get a message from him a few months later asking for feedback on it and what I thought was wrong.
By this point I had learned more about the topic and reading the spec language and knew enough to know I had just been an idiot. I ashamedly responded with an apology and basically told him that my criticism could be ignored because it came from my lack of understanding and not a real problem with the spec.
It's pretty interesting to see it laid out there in person years. It really is a small number (especially compared to the much larger number of bodies working on other parts of those browsers).
I'll still take umbrage with the "MIT approach over Hacker approach" comment by the OP. "Worse is better" is fairly independent of that, and I think it does do disservice not only to the academic shoulders that the modern JS engines stand on, but also the academic brains packed into most of the JS engine teams (even just starting with the backgrounds of the editors of the asm.js spec).
It's also amusing, of course, that the submitter of this article is bzbarsky, who has done amazing work for the web and whose mailing list correspondence, at least, all comes from an address ending with "@mit.edu" :)
And I don't feel one bit sorry about it. I guess I could call it Stanford(/MIT) way, but MIT is nicer, juicer target.
Also asm.js is the Worse is Better compared to PNaCl. It's simpler, it's a 'hack' of JS compiler, it's not as fast as native performance of PNaCl. But it epitome of the said approach.
C is also Worse is Better approach compared to Lisp and it had some of amazing people, work on it.
> There's no denying that the PNaCl is a superior approach, and if we were starting from square one would be the smarter design as well.
Not necessarily. That has been discussed at length many times here and elsewhere. PNaCl's approach is interesting and technically has much merit, but also has significant downsides (startup speed, complexity, size of implementation, reliance on LLVM for something it was not intended, risks of undefined behavior, PPAPI, etc.). It's technically an impressive technology but also one with fundamental compromises.
Instead, an undeniably superior approach could be to start entirely from scratch, not JS nor LLVM nor anything else, and work to design something truly optimal for the use case we are talking about here (code shipped over the network, to run securely inside a browser, at near-native performance, with fast warm and cold startup). That would look very different from both JS and PNaCl, and could avoid the compromises that both have.
Most of the negatives are heavily focused on implementation rather than design, which I don't disagree with. However, the positives of targeting any language at a stable byte code is incredibly valuable... such as an implementation of javascript itself. A bytecode approach provides a superset to our current status quo.
That said, as browsers act more like operating systems, it makes me wonder if we've somewhat missed the point.
I agree with you about starting from scratch. I think if history is any indication, ultimately we'll end up having to write a new 'web' with very different semantics and design philosophies; goodness knows the old metaphor is starting to creak in a number of problematic ways.
> However, the positives of targeting any language at a stable byte code is incredibly valuable... such as an implementation of javascript itself. A bytecode approach provides a superset to our current status quo.
Not necessarily, it depends which bytecode. For example the bytecode in PNaCl, which is based on LLVM IR, is excellent for C and related languages, but not for many other important languages.
Remember Java bytecode backward compatibility hampering language evolution, in the generics (erasure) debate and result. Then they broke bytecode compat anyway.
Flash has two language implementations in it, one for AS2 and the other (Tamarin) for AS3. Only way to be sure about AS2 compat!
In many ways, with JS you have one problem; add bytecode and now you have two.
But asm.js is a bytecode, isn't it? Just with a clever-but-weird encoding that allows a backward compatibility.
In a same manner, one can deliver, for example, an x86 bytecode in JS-encoded form. Just encode opcodes as, say, "eax = 1" instead of "\xB8\x01\0\0\0".
No, asm.js is a JS subset. "bytecode" as boosted here would be a non-subset, like JVML to Java source.
Sure, bits is bits. Doesn't matter if you're after gzipped good results. But bytecode hopes spring eternal and the hopers do not want gzipped, minified, Emscripten-produced asm.js. They want a different syntax.
You didn't respond to the "now you have two problems" point.
Keeping asm.js a subset of JS avoids all the back-compat-locking/future-hostile-lowering problems. And engines have only one parser to make super-fast. (Already there.)
This is a significant win. What your "sane" means is mostly aesthetics. asm.js already has int32 and uint32 conversions and casts. There is no big semantic gap for vanilla C/C++ source to JS. Typed array views help a lot here; JS's built-in operators and a few helpers in ES6 (Math.imul, polyfillable) do the rest.
The non-vanilla gaps of note are mostly gaps in JS (e.g., int64, uint64, SIMD), which we're filling in ES7 for many reasons.
Shared memory threads are indeed a gap to confine to a checked subset, not push into JS along with data races (VM-level and usercode-level -- this is fatal). We're working on that too, but it's not a "bytecode" issue _per se_.
If you continue to believe that "it's not just syntax", and you have something in the way of semantics other than the above in mind, please state it explicitly.
I was thinking of int types, SIMD, shared memory with an explicit model, and arbitrary jumps. It's nice that some of those are getting fixed.
I would also like to see a bytecode with structures (and alignment control), nice code generation and execution and some form of virtual memory for resources.
What I don't understand is why Mozilla didn't define a bytecode and a to-JS compiler for it. Browsers without support would have been just as slow, but there would have been much more room for evolution.
I'm almost expecting Mozilla to pull a Trojan any day now: define a bytecode that compiles to asm.js and declare asm.js deprecated.
> What I don't understand is why Mozilla didn't define a bytecode and a to-JS compiler for it
If nothing else, Mozilla does not have nearly as much money as Google, and really cannot afford a "tear down everything and rebuild it" approach like PNaCl. An advantage of OdinMonkey is that it is able to reuse a huge chunk of the SpiderMonkey infrastructure. If you look at the diagram in the article with the red arrow, the "Ion-compile" step is the same size as the others, but in reality is a huge number of line of code, representing multiple engineer-years of ongoing work.
Much of the work the article describes, such as parallel Ion compilation, was carried out mostly for the benefit of non-asm.js compilation, but because OdinMonkey shares the infrastructure, it was able to benefit from it without having to create a new implementation from scratch.
Beyond the engineering of the implementation itself, asm.js itself is a natural evolution of Emscripten-style JS, which had already successfully demonstrated that it can be used for large applications, and that other non-Mozilla browsers are interested in it enough to have done optimization work for it. This reduces the risk that the design itself is technically broken in some way that wouldn't be apparent until people try to run large production-ready applications, as well as the risk that only Firefox will ever be able to run asm.js code at a decent speed.
> If nothing else, Mozilla does not have nearly as much money as Google, and really cannot afford a "tear down everything and rebuild it" approach like PNaCl
The rest of your post is spot-on, but this part isn't really true. The barriers to "tear down everything and rebuild it" are much more systemic and less monetary (just look at the small JS engine teams that got us where we are today).
Meanwhile, Mozilla Research certainly continues to grow, and Rust is a perfect example of a "tear down everything and rebuild it" project now run by them, albeit in a different domain than JS.
The domain differs for Rust from JS or PNaCl. The latter are on the web. Rust is AOT compiled and for systems programming. It's competing with C++, not JS -- and not for safe C++ on the Web (not yet, anyway; Rust2JS and Rust on the GPU are of course on radars due to LLVM and eholk & co. at IU, respectively).
Even with Rust, we don't tear down Unix or DWARF, to pick two examples -- we use 'em for maximum leverage.
int types are in JS and have been since 1995, due to the bitwise logical and shift ops.
arbitrary jumps are a deoptimizer and verifier hazard (Java's verifier had O(n^4) complexity DoS attack demo'd by Michael Franz and his group at UCI). Do not want.
SIMD is coming and wanted in hand-coded JS too, not a bytecode issue per se.
> What I don't understand is why Mozilla didn't define a bytecode and a to-JS compiler for it. Browsers without support would have been just as slow, but there would have been much more room for evolution.
You mix speed ("just as slow" -- wait, we're fast at asm.js input, faster on startup than PNaCl -- did you read the post?) with "room for evolution". I just argued above that having two syntaxes hurts evolution. Please separate speed from evolution and address my argument.
Mozilla is in no position, philosophically or market-share-wise, to "pull a Trojan". Also, my argument stands no matter who is making it. No ad hominem fallacies, please!
> int types are in JS and have been since 1995, due to the bitwise logical and shift ops.
That's like saying int64 is a subset of float64 because you can use two floats to encode it.
> arbitrary jumps are a deoptimizer and verifier hazard
True, this would be one of the decisions to be made when designing a bytecode format.
> You mix speed ("just as slow" -- wait, we're fast at asm.js input, faster on startup than PNaCl -- did you read the post?)
You misunderstood. Asm.js running on a browser that doesn't have support for it is just as slow as output from bytecode-to-JS compiler would be. And for browsers that do have support, both asm.js and a hypothetical bytecode would behave the same.
The major differences with a bytecode would be requiring two "executables" and a better semantic model.
Also, I'm not necessarily defending PNaCl itself, nor did I even bring it up.
> No ad hominem fallacies, please!
I'm not sure where you got that, the Trojan comment was meant positively.
I think it would be nice if Mozilla introduced a bytecode (superset of asm.js semantics), once asm.js itself was accepted.
> True, this would be one of the decisions to be made when designing a bytecode format.
Indeed, no clean-slate design, we have learned from the past. Dropping goto leaves less to change in asm.js. You need to produce the missing semantics or else we're just arguing syntax.
> Asm.js running on a browser that doesn't have support for it is just as slow as output from bytecode-to-JS compiler would be.
No, asm.js on browsers that do not use AOT compilation is already faster than non-asm.js for the workloads of interest (compiled from C/C++, etc.).
Anyway, speed was not the issue. => evolution is harder with two syntaxes.
Trojan is usually pejorative -- beware Greeks bearing gifts and all that ;-). No worries, but really, it does not make sense to do a second syntax for asm.js, at least not yet. Maybe in the farther future when JS has reached some fixed point.
> No, asm.js on browsers that do not use AOT compilation is already faster than non-asm.js for the workloads of interest (compiled from C/C++, etc.).
That would be a bytecode-to-asm.js compiler. Hence, no difference besides distribution.
I was not aware so many features are getting added to JS for the sake of asm.js. Other than structure/array abstractions (like LLVM's), which largely only improve debugging, I can't think of important missing features that can't be fixed with compilers or extra APIs.
The only major objection remains lack of elegance (which is indeed largely a syntax/decoding argument). I guess browsers environments are doomed to be ugly and quirky.
> That would be a bytecode-to-asm.js compiler. Hence, no difference besides distribution.
Your "That" referred to something in my sentence "No, asm.js on browsers that do not use AOT compilation is already faster than non-asm.js for the workloads of interest (compiled from C/C++, etc.)" -- but I have no idea what. Please use a noun. What "That" did you mean?
I was not talking about a bytecode-to-asm.js compiler. I said asm.js code (output of Emscripten, hand-coded -- whatever typechecks) runs faster in other browsers such as Chrome than non-asm functionally equivalent code, even without AOT compilation. But as the blog post shows, AOT in Firefox is even faster at startup (and see the link on "throughput" for other wins).
Missing features are not being added to JS for the sake of asm.js. I clearly wrote we are adding SIMD, int64, etc. for hand-coded JS users. Ecma TC39 is not only concerned with "compile to JS" use-cases, we look at apps, libraries, and compilers.
For some reason, at least twice now, when I've written X, you've read Y or !X. Not sure why, but I hope this message is clear, at least!
If a hypothetical bytecode were designed, a compiler from this bytecode to asm.js would be just as fast in browsers without support for this bytecode (or for that matter asm.js) as asm.js is currently.
One would compile C/C++ to this bytecode and either ship it directly (to browsers that support it) or compile to asm.js and ship that (to browsers that don't support it).
This process I described is precisely how Dart works and while I don't particularly like Dart itself, I think its compilation/distribution mechanism is nice.
It's possible to do this later, after (and if) asm.js becomes popular. And it would even possible to eventually compile JS itself to this bytecode.
> But as the blog post shows, AOT in Firefox is even faster at startup (and see the link on "throughput" for other wins).
I am not immediately concerned with the merits of asm.js as implemented in Firefox at the moment.
> Missing features are not being added to JS for the sake of asm.js. I clearly wrote we are adding SIMD, int64, etc. for hand-coded JS users. Ecma TC39 is not only concerned with "compile to JS" use-cases, we look at apps, libraries, and compilers.
Sure, I guess. These features just seemed to me more important for asm.js than generic application JS (as opposed to, say, macros).
JVML is not a bytecode. The bytecode syntax is just a disguise . JVML is a high level language that prescribes a certain object / method / inheritance model. Methods are associated with objects according to specific vtable / vinterface rules.
OTOH, asm.js is defined in terms of value types + function pointers. Just call the function pointer with the right arguments. Bring whichever objects / closures you like.
PS. Gripe of the day: 64bit computing is here (even ARM supports it) and asm.js doesn't seem to be prepared.
> No, asm.js is a JS subset. "bytecode" as boosted here would be a non-subset, like JVML to Java source.
Sorry for quoting Wikipedia, but bytecode is just a form of instruction set designed for efficient execution by a software interpreter.
Maybe I'm mistaken on this, but from reading about asm.js I got an impression that asm.js-aware browsers use different approach to asm.js code and treat it more like a weirdly-encoded bytecode, not as an ordirary JS source. Or I'm misunderstanding things?
If so, asm.js is a bytecode. Whenever there's a correspondence between it and other languages doesn't matter for determining if it's bytecode or not, it's another (useful, but not related to being bytecode) property.
> They want a different syntax.
I don't think syntax matters that much, it's mostly semantics. Probably.
actually, asm.js is just javascript. Basically, Mozilla looked at what sort of javascript code that the different JIT's allready handle really well, and made a specification out of it. So even in Chrome, asm.js will run very efficiently. Mozilla figuered out a way to write javascript code that made type-information easy to extract, which again makes it easy to AOT-compile. For instance, the following code:
function asmjs(i) {
i = i|0;
return (i + 1)|0;
}
is valid javascript, and you can easily write this in your own programs. The "|0" means that the variable will be converted to a integer, because it is specified in the javascript standard. As an optimization, you can use this as a type annotation, kind of like writing "int i = 0;" This is what asm.js is in a nutshell, and why it's so easy to implement a special compiler for it.
You are replacing the "bytecode" objection, which is about syntax, with your own non-objection equating asm.js with a bytecode like JVML. I'm happy you're ok with asm.js, but those who are not, and who demand "bytecode", do care about syntax first.
Forget it. JS VMs in browsers are required, JVMs are dead weight. Reversing the trend against the Java plugin, which accelerated due to malware (Brian Krebs said Java was the #1 paid-for malware vector some years ago) but which began with declining plugin share re: Flash, is very unlikely. #1 reason: mobile -- plugins don't fly there, not just because Jobs was mean to Flash.
That's kinda my point as well. If we are to wipe clean. Nothing in browser for scripting exists.
Some kid from Zambia develops JavScript 2.0 in two weeks.
Entire Google team works out a specification for LLWM (Low Level Web Machine) and it's pretty close to LLVM. They take how long to implement it?!
People need to get their browser scripted so they look around shopping for a new language. Oh, cool the awesome LLWM spec is out there. Wow. It's got all the thing they want. Let's wait....
A month passes. People look again but no LLWM. On the other hand there is this JavScript 2.0 that kind of works. It's ugly, but Mark took a look at it and he uses to make dancing kittens. In 3D (i.e. the picture just rotates around axis, using CSS).
Another month passes. Is LLWM done yet? Hmm, the clients are itchy, they want their browser scripted. Maybe dabbling in that JavScript 2.0 doesn't sound so bad.
Third month passes. LLWM is still being worked on. Your clients have employed Mark and dumped you. Yeah, life is cruel and JavScript 2.0 is more cruel - Integers overflow when adding two numbers with more than six digits each, it confuses 0 and o, no local variables, just global vars.
...
Fourth month passes. LLWM is still being worked on. JavScript 2.0 sucks but everyone tolerates it. Also there is JavScript 2.1 comming out that allows variables to not be in UPPERCASE. And there is a nice library for dancing kittens called dance.jv2
...
Year passes. LLWM ships. JavScript 2.123 is out and it's about the same in terms of speed and features. Sure there are few warts here and there, like lack of static typing, but overall it's quite solid.
Compare this situation with many other examples of Worse is Better.
How long between Javascript's "it only took 2 weeks" until now though?
Is this is an example of "worse is better" innovating at faster speed, when in fact, Javascript performance has moved at a glacial pace until recently and it took enormous investment to get there.
I think it is fair to say that if someone started with today's web/mobile requirements and designed a language from scratch to meet performance, latency, and memory requirements as well as portability/cross platform execution, it probably would not take as long as Javascript did to reach the current levels of performance.
That is, you're comparing 15+ years of Javascript JIT engineering activity with what, 2-3 years of PNaCL activity by a much smaller team?
>I think it is fair to say that if someone started with today's web/mobile requirements and designed a language from scratch to meet performance, latency, and memory requirements as well as portability/cross platform execution
True, but so is that developing a simpler, cruder and slower but Fast Enough alternative to said language, would take less time and by the time the said alternative would developer, they would be on same feature parity.
> That is, you're comparing 15+ years of Javascript JIT engineering activity with what, 2-3 years of PNaCL activity by a much smaller team?
No, I'm comparing asm.js engineering (if you can call it that), to (P)NaCl.
JS performance improvements was a weird road to take, but JS of old days wasn't the JS of new days. It's use case was significantly different and Google wanted to enable new use cases for it to run it's Gmail program. So they did.
Enormous investment? See my estimate (generous) above.
Contrast with the Dart (nee Dash) investment, where a team of at least 60 now labors on a language+VM that cannot cross the chasm to other browsers in any foreseeable future where there are multiple browsers with disjoint source that have significant market share.
Evolution doesn't care about aesthetics (my pelican slide from JSConf.{us,eu}). It doesn't care about wealth-effect follies that can't be standardized among developers without a compile-to-JS plan that undermines the native-VM plan. It does not care about roads-not-taken in the past, so long as the road from here is clear.
Bet on punctuated equilibrium. Both PNaCL and asm.js are could follies if you consider mobile games. There is no incentive for someone developing games for consoles or phones to use either of those technologies.
Game devs code to metal, use C++ and OpenGL. This is why Jobs went from web apps to allowing native in iPhone 1 era.
Both PNaCl and Emscripten (or Mandreel -- the relevant comparison, not asm.js which is a different category) work on such source. This is how Firefox OS runs games (Disney Where's My Water, many others). Cross-compilation works.
Coding to metal isn't just about source language, it's about optimizing system level performance. Top tier game devs use vTune, GPU profilers, system level analyzers, to maximize overall system performance for a given workload. Developers at studios like Naughty Dog, Bungie, DICE, Infinity Ward, et al don't just delegate to the C compiler and call it a day.
Leaving aside casual games, which are mostly not performance sensitive, top tier game development is very high risk and expensive. One reason why developers like consoles and the iPhone/iPad is absolute predictability when it comes to target platform. Even branching over into the Desktop PC, game tuning requires a ton of testing on a huge matrix of platforms, chipsets, drivers, and other configurations, all of which is a big expense, as well as a big support cost.
What is the motivation for say, Infinity Ward to port Call of Duty to asm.js or PNaCL? Most of the people who would actually buy it will do so on a console, or through something like Steam. You'd be asking them to add an immature and unproven technology into the mix that sacrifices multithreading, or drops a big chunk of performance on the floor, and in return, add back millions of frustrated web users who will be making customer support claims.
I love the web, I have the tons of "native" apps on mobile that don't really deserve to be native apps at all and would work equally well as a URL to a web site that doesn't force an install. But --
Games are not webby. They are not the web, and treating the browser like a C virtual machine that throws away pretty much most of the browser's machinery in favor of just OpenGL bindings is not what the browser was designed to do, and the fact that it does it at all is amazing, but it is not helping the web.
I think both Chrome and Firefox would do the world a much bigger favor concentrating on making the other parts of the browser rendering engine a lot faster. JS performance is not the primary reason that Web apps feel janky compared to native ones, the entire development model for web development is a minefield full of performance hazards.
For years, the JVM had huge performance advantages on JS. It had native code interfaces, it had off-heap non-GCed memory allocation capability, it had high performance, and yet, Minecraft is pretty much the only success story. Now why is that? And why NaCL, which has a rich father (Google) behind it, and the world's largest browser marketshare of hundreds of millions, can't convince many developers to port to it. You think Emscripten ports are easier than NaCL? The best explanation is that the return on investment in making a game that is shoe horned into the browser is not worth it.
If given the option to buy a game on Steam, or buy it via Chrome Web Store or Firefox store, I would buy the Steam version. I bet the majority of people reading this would do the same.
I see that casual, simple mobile games might be suitable for this, but that's a problem for FirefoxOS and ChromeOS to solve. Most game devs will continue to target iOS and Android until FireOS gets a non-trivial marketshare. Crossing that chasm is going to be hard.
To make a TL;DR short, I am frustrated that native is taking over in the non-games space, and the efforts by both Google and Mozilla to get at the real heart of the matter, of making jank-free, buttery smooth, mobile apps easy to develop for web developers is moving far slower than it needs to be.
> concentrating on making the other parts of the browser rendering engine a lot faster.
The fallacy of the excluded middle, yawn.
We're working on perf all over, so are Chrome folks. But unlike Google, we're not building three VMs requiring their own toolchains. We can't afford to, nor can others building browser engines, and developers are not buying it from what I can tell.
> All this games stuff is a huge distraction.
True in deep ways (have to keep my kids away from it or their brains turn to mush).
We agree that hand-coded JS needs pause-free GC and JITting. Pause-free GC is doable, I've advocated it. Top engines' GCs are still optimized for throughput.
Pause-free JITting is harder, and less theoretically tractable. Whack-a-mole is unwinnable, AOT is beating JIT here.
We follow our nose on this one. If AOT == JIT in some utopian future, great. Otherwise, misspeculations and phase changes happen, and using background threads on other cores to recompile can help, but without precog JITting there will be jank and startup pain.
Well, I agree on the performance (speed) side, VM out, subset In. but feel abandoned on the memory footprint side.
Objects are just huge! Asm.js promises something more like structs, I think. Now making THAT available to JS programmers would be a great help.
I really don't want to go back to C just for faster JS. Lets use the knowledge of the last year to put some of the asm.js goodness into JS hands. LLJS is likely not the answer from a recent jlongster post. Rather than a new language, simply parts of asm.js would be better received by the JS community.
You're an executive of Mozilla. I think you can join threads without being condescending.
As for whether developers are buying PNaCL, asm.js, Dart, or even Javascript, as a major platform for games development remains to be seen. The majority of the game-dev resources are being spent on native, and those that are developing for mobile, are doing so for native. If Javascript is lucky, it might one day be as popular as Flash for doing games, it hasn't even reached 1/100th of the success of the FlashVM in that regard.
There is a lot of time spent on HN arguing over JS vs Dart vs NaCL, meanwhile, the consumer experience is being taken over by native, and it is not because of JIT performance. Failure to see why developers choose native, and why consumers choose it, I think is a tragic tunnel vision.
You wrote a tl;dr piece with a whopper in the middle asserting that we should all go work on other perf than JS perf that is attracting game publishers, big ones -- while at the same time, Google is pushing *NaCl (both with and without the P) / PPAPI as the way to get native code including those very games ported to Chrome and Chrome OS.
I think that's at least the false dilemma fallacy I identified, if not something more like a conflict of interest, and I'm gonna say so. Bluntly.
I frankly don't care whether game devs ever hand-code in JS or Dart. They'll continue to use C++ for good reasons (until the Rust-pocalypse). GC is never free, nor is JIT. C++ and other AOT languages endure.
Really, it's not for us to over-sell JS and require rewrites.
And again, Google apparently gets this market need because they have been selling NaCl against it (with limited success). So it's not out of bounds for JS suddenly, in spite of your tl;dr protests.
It's incorrect to view Google as a single entity. There's a large number of engineers each with their own ideas of what should be done, and Google gives a lot of resources for people to explore things. To say that Google is pushing something can only really be understood in context of how much company level priority and head count is put on it vs individual loudness and passion of the teams doing their things.
Some very small teams at Google who work on stuff as 20% side projects are so vocal and active with the external community that they give the impression of huge focus and investment. Others, while mostly quiet, give the impression of almost no investment while large groups of people churn away.
My interests are aligned with preserving and maintaining what is good about the Web: federation, transparency, frictionlessness, indexability, composeablity, linkability, etc. I am more focused about avoiding this future (http://idontwantyourfuckingapp.tumblr.com/). To me the trend towards appification and install of everything is something we should not be chasing. Ideally, web apps should trend towards less code execution, not more.
The first two decades of the Web were mostly about content. Now we're turning it into an entertainment device and a gaming platform, it's this generation's television. Everyone is chasing off into the bandwagon/rathole of trying to be more like iOS apps, because of the perception that it's how you make money. That gravy train will eventually saturate and become a dead end. It's short term thinking. Skate towards where the puck will be or should be, not chasing Apple down the field trying to catch their lead skater.
Long term I want the Web to "win", but not by changing into a platform of binary opaque blobs like native.
Great comment -- with you all the way on this one.
I use "they" for Google on purpose, it's a fleet of ships for sure. But I also confer with my VP Engineering, Chrome counterpart regularly and know (mostly) what projects are official and intentional. :-)
> We're working on perf all over, so are Chrome folks.
So where are the blog posts about buttery smooth touch interactions on Firefox OS? Where are the blog posts about saving/loading large arraybuffers into indexeddb without it crashing the browser / taking a week and a half on mobile? Because there are asm.js blog posts every other day. I'd love to read about how regular browser stuff is getting leaps and bounds better, but I don't believe that it is.
Smooth touch interactions are supported better by Firefox OS with touch events, do you have a particular bug in mind?
Fixing bugs and blogging about them would take all blogging energy for little gain. We fix bugs without enough positive noise, but I think the main thing is to fix bugs.
OTOH, Emscripten/asm.js work (which, silly exaggeration, is not blogged about every other day) is not a bug fix. It's a bigger deal, and it needs explication (especially because some FUD about how it entailed new VMs still lingers in the twittersphere).
Also, we're fastest on Emscripten output due to AOT. That is news, news! I say ;-).
Or were you referring to OCaml in particular?