9 ms·

It's not a benefit. Most other modern languages are also async, they just don't force the programmer to think about it. Go, for example, is just as "async" when

It's not a benefit. Most other modern languages are also async, they just don't force the programmer to think about it. Go, for example, is just as "async" when it comes to efficiency as Node.js (more so, actually, since it can use more than one CPU core.) The whole notion that node.js (or Python's Twisted) makes everything more efficient by putting you in an event loop is just a cop-out for not having something more intuitive like blocking semantics with an evented I/O scheduler.

nostrademons 12y ago
I wouldn't say "most" - it's basically just Go, Erlang/Elixir, and Haskell that offer blocking semantics with an eventloop under the hood. If you work in Java, the "easy" way is to use threads, and you have to think about it if you want non-blocking IO. If you work in C++, there is no "easy" way, and you have to think about it if you want non-blocking IO. If you work in PHP, Perl, Python, Ruby, or Javascript, they are single-threaded by default but give you basic UNIX concurrency/IO primitives to work with.
- eropple 12y ago
  > If you work in Java, the "easy" way is to use threads, and you have to think about it if you want non-blocking IO. Or you use Play/Akka and don't think about threads. Or Scala streams and don't think about threads. There's not much thinking about threads going on here. (A major reason why Go just makes me shrug is that I already have its good bits within easy reach on the JVM if I want them, and I don't have its bad bits.) > If you work in C++, there is no "easy" way, and you have to think about it if you want non-blocking IO. YMMV, but I don't find boost::thread_group and Boost.Asio terribly hard. Also, you omitted C#, which has some pretty fantastic asynchronous tools that you don't have to think about at all.
  - warfangle 12y ago
    While Scala certainly rubs on the JVM, it's not always possible to use in a project that requires concurrency...
    - eropple 12y ago
      I have yet to see a project running on a JVM (i.e., HotSpot, not Dalvik) where Scala was impossible to use. I have seen many projects with management that decried its use, but that's a self-caused and self-reparable problem. And Akka is perfectly usable in Java.
      - nostrademons 12y ago
        All software problems are self-caused and self-reparable: if you want to use Language X and all your infrastructure is in Language Y, you "merely" need to write an interpreter for Language X in Language Y. When management decries usage, it's almost always because they're running a cost/benefits analysis and the costs of using X (including writing language bindings for code, training programmers on the team, hiring new programmers for the team, context switching between multiple languages, and dealing with bugs and corner cases that have been encountered and fixed by other people in more mainstream languages) outweigh its benefits. Many of these costs are invisible to the engineer who originally proposed using X.
        eropple 12y ago
        Like I said: Akka's right there. Works in nice, nonthreatening Java. But the "repair" I was referring to is that a developer can leave rather than put up with conservative silliness if they so choose (and personally, I do, my last gig was a Scala one and so is the next). Java shops are not so rare as to be irreplaceable and any shop seriously worried about hiring somebody who can work with systems that are by now fairly well-understood isn't going to be a good place for any decent developer's career.
        deleted 12y ago
        [deleted]

nostrademons 12y ago

I wouldn't say "most" - it's basically just Go, Erlang/Elixir, and Haskell that offer blocking semantics with an eventloop under the hood. If you work in Java, the "easy" way is to use threads, and you have to think about it if you want non-blocking IO. If you work in C++, there is no "easy" way, and you have to think about it if you want non-blocking IO. If you work in PHP, Perl, Python, Ruby, or Javascript, they are single-threaded by default but give you basic UNIX concurrency/IO primitives to work with.

eropple 12y ago
> If you work in Java, the "easy" way is to use threads, and you have to think about it if you want non-blocking IO. Or you use Play/Akka and don't think about threads. Or Scala streams and don't think about threads. There's not much thinking about threads going on here. (A major reason why Go just makes me shrug is that I already have its good bits within easy reach on the JVM if I want them, and I don't have its bad bits.) > If you work in C++, there is no "easy" way, and you have to think about it if you want non-blocking IO. YMMV, but I don't find boost::thread_group and Boost.Asio terribly hard. Also, you omitted C#, which has some pretty fantastic asynchronous tools that you don't have to think about at all.
- warfangle 12y ago
  While Scala certainly rubs on the JVM, it's not always possible to use in a project that requires concurrency...
  - eropple 12y ago
    I have yet to see a project running on a JVM (i.e., HotSpot, not Dalvik) where Scala was impossible to use. I have seen many projects with management that decried its use, but that's a self-caused and self-reparable problem. And Akka is perfectly usable in Java.
    - nostrademons 12y ago
      All software problems are self-caused and self-reparable: if you want to use Language X and all your infrastructure is in Language Y, you "merely" need to write an interpreter for Language X in Language Y. When management decries usage, it's almost always because they're running a cost/benefits analysis and the costs of using X (including writing language bindings for code, training programmers on the team, hiring new programmers for the team, context switching between multiple languages, and dealing with bugs and corner cases that have been encountered and fixed by other people in more mainstream languages) outweigh its benefits. Many of these costs are invisible to the engineer who originally proposed using X.
      - eropple 12y ago
        Like I said: Akka's right there. Works in nice, nonthreatening Java. But the "repair" I was referring to is that a developer can leave rather than put up with conservative silliness if they so choose (and personally, I do, my last gig was a Scala one and so is the next). Java shops are not so rare as to be irreplaceable and any shop seriously worried about hiring somebody who can work with systems that are by now fairly well-understood isn't going to be a good place for any decent developer's career.
        deleted 12y ago
        [deleted]