1. 19
  1.  

  2. 7

    order is very expensive

    My concept of expensive is based more around engineering hours and ease of understanding than around CPU time. Javascript is by far the most difficult language to reason about that I’ve ever worked with, and it regularly trips up other team members as well. I really want to give a talk on Production Errors Caused By Javascript, about outages caused by mismatches between the Javascript programming model and our team’s concepts of it.

    If you’re doing anything so CPU intensive that throwing CPU’s at the problem is expensive, you’re better off using a different language.

    1. 1

      If you’re doing anything so CPU intensive that throwing CPU’s at the problem is expensive, you’re better off using a different language.

      I would’ve assumed that - it seems absurd that javascript would be more performant than e.g. Python. But recent benchmarks seem to imply that even number-crunching can be really fast in javascript.

      1. 3

        See for example http://web.archive.org/web/20150905072628/http://www.jut.io/blog/2015/pushing-node-js-performance-limits - “one effective way that we get high performance out of node.js is to avoid doing computation in node.js.”

    2. 4

      Promises were one of the fundamental concepts I learned about during my summer internship working with JavaScript at Cisco. If anyone is looking to work with Javascript in the near future, I strongly urge you to read up on this, since it’s the direction that things are going in these days.