8 ms·

considering every mistake in the list had an accompanying "right way", I don't think it was a critique of Node.js. Some of these might rightly be called "Mistak

• thirsteh 12y ago
  Most of the callback spaghetti and event loop blocking stuff is just a critique of Node.js, not developer ability. Most other languages don't have these problems.
  • jonny_eh 12y ago
    It's a trade off. Other languages don't have this problem but they are missing the benefit of an all async ecosystem.
    • thirsteh 12y ago
      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.
    • MichaelGG 12y ago
      Or they have proper syntax to allow wiring in a sane style, letting the compiler generate the callback hell in codegen. In F#, async is just a library. C# has it built in via a dedicated keyword.
    • esailija 12y ago
      One is not even a tradeoff* and the other is completely unrelated to having an all async ecosystem. *Anything available in other languages in place of callbacks (promises, generators, async await etc) is also available in node. If you are using callbacks you are just ignorant (or don't want to deviate from out of the box features in which case node is the worst possible thing for you). Nowadays there is not even a performance benefit so the only credible reason to use callbacks is not even there.
      • woah 12y ago
        What about the fact that they are simple, idiomatic, and require almost no effort to reason about?
        • deleted 12y ago
          [deleted]
  • notduncansmith 12y ago
    Developers have the ability to avoid these problems, so I wouldn't call it a critique of Node.
    • thirsteh 12y ago
      Developers also have the ability to avoid buffer overflows in C, yet they happen all the time, even for some of the most seasoned developers. This is an indication that there are issues with the language.
      • tuananh 12y ago
        "with power comes responsibility". C allows you to do many low level stuff, it's your job to deal with it.
        • Nitramp 12y ago
          Said responsibility is then just not using C when you don't want buffer overflows, and by extension not using Node/JavaScript when you want readable code?
          • musername 12y ago
            if you don't need (exclusive) any benefit offered by C or node, sure.