_jmar777

Where to start, where to start...

The problem here is browsers, not JavaScript. Python has evolved much since the '90s, just like JavaScript has. The problem unique to JavaScript is browsers, and end users running browser versions with a decade span in between them. This is also why the "IE9+" requirement is so relevant to this conversation, because developing with that luxury is entirely different than developing for IE7+ (or, for some poor souls still out there, IE6+).

Sweet... so how does Dart compare with asms.js?

/me ducks

:)

If your browser requirements are IE9+, then there's little need for things like underscore (and, arguably, even jQuery) since you can count on x-browser support for things like document.querySelectorAll() and other niceties that jQuery typically levels the playing field for.

For example, why would there have been confusing over _.each vs. $.each when you have perfectly consistent native support for [].forEach? Nothing against Dart... it's cool and all, but I'm not sure the JavaScript "fragmentation" rationale is all that strong when you have the luxury of only dealing with such modern implementations.

> Other engines just neglected to implement it.

Why would they have? Seems like waiting for ecma approval and specification makes sense.

Storm is actually not similar to Hadoop at all. I think this title resulted from a misreading of the README, which states: "Storm is a distributed realtime computation system. Similar to how Hadoop provides a set of general primitives for doing batch processing, Storm provides a set of general primitives for doing realtime computation."

/nitpick

I think you're being too hard on JavaScript there. Type coercion, ASI, and function scoping are all language features, not errors. Likewise, eval is not an error; it's dangerous, but it's also a feature (and one that nearly all dynamic/scripted languages provide). As Crockford said, "JavaScript is the only language people feel like they don't need to learn to use." That statement alone describes why so many developers end up scratching their heads at stuff like `1 == "1"`. That's not an error or an oversight in the language - it's a feature that the developer didn't realize he/she was using. It's hard to make it 10 minutes in ANY educational material on JavaScript that doesn't explain equality (==) vs identify (===) comparisons in JavaScript.

Lastly, the new class stuff doesn't actually change the inheritance/object models in JavaScript. It's syntactic sugar on top of prototypes, and the "weird constructor stuff" is quite analogous to existing constructor functions. For example, from the [ecmascript wiki](http://wiki.ecmascript.org/doku.php?id=strawman:maximally_mi...): "Class declarations/expressions create a constructor function/prototype pair exactly as for function declarations."

I'm clearly a bit of a fanboi and obviously biased, so take all of this with a grain of salt - but most of these new language features are a good thing. I'm glad to see JavaScript evolving in big ways. It was getting boring watching new editions come out with nothing more interesting than Array.prototype.reduce in them. Especially when you consider server-side contexts like Node.js, stuff like typed arrays, generators, Maps, etc. are welcome additions.

Rockfish Interactive made a mobile app for (and used by) the Mitt Romney campaign. I'm not even sure what "Romney's Agency" means in the title here, but it sounds a bit oversold...

Make http://news.ycombinator.com/newslogin redirect to https://news.ycombinator.com/newslogin. Not to be overly facetious, but there's some irony to having an unsecured login form on a site called "Hacker News". :p

On a related note... any chance we can get confirmation on passwords being hashed/salted?

Update: already forwarded this to Mathias, but posting here in case anyone else wanted to see the full benchmark test: https://gist.github.com/3518344

Yes.

Yes, I had a single index:

  db.events.ensureIndex({ ts: 1 });

I'll try to clean up my benchmark code a little, throw it in a gist, and then I'll send it your way.

I've been playing around with the Aggregation Framework lately (using the release candidate). The performance seems to be pretty reasonable, especially when compared to similar tasks with the old MR framework. A quick and dirty benchmark number in case anyone is interested:

* Obligatory unscientific, probably not meaningful, etc. disclaimer.

Mongo Version: 2.2.0-rc1

Hardware: MBP, Snow Leapord, 2.2 GHz Intel Core i7, 8 GB mem

Data: Single collection with 500k records (machine generated time-series event data)

Query Pipeline:

  [
      {
          $match: { ts: { $gte: 1293858000000, $lt: 1296536400000 } }
      },
      {
          $group: {
              _id: 'aggregations',
              sum: { $sum: '$foo' },
              num: { $sum: 1 },
              avg: { $avg: '$bar' }
          }
      }
  ]

Results: The time range matched against above matches 42,466 documents within the collection. The average response time over 50 runs is 419ms. Not exactly "Big Data OLAP" stuff just yet, but plenty fast enough for most use cases involving reasonably small sets of data. Great job to the MongoDB team!