• Tartas1995
    link
    fedilink
    arrow-up
    2
    ·
    1 year ago

    It is not really tangential to the discussion. You claimed it is because Js single threaded. Also it is not single threaded from the “users” perspective if you mean the developer. There are workers.

    If your issue is asynchronous function calls, just call synchronous functions. You might be stuck in a while loop somewhere but if you prefer that, use it. There are sync functions for everything in Js and/or you can easily create them yourself.

    • ☆ Yσɠƚԋσʂ ☆@lemmy.mlOP
      link
      fedilink
      arrow-up
      2
      arrow-down
      9
      ·
      1 year ago

      Js is single threaded from user perspective. You have no access to the threading runtime as a user and cannot spawn a thread in Js to do some background work. Workers are a recent addition, but using them is quite different from what I’m talking about.

      And being stuck in a while loop is precisely why people have to use callbacks and why all the APIs are async. This is literally the problem. If you’re dealing with any non trivial load, you are forced to use async mechanics.

      • Tartas1995
        link
        fedilink
        arrow-up
        1
        ·
        1 year ago

        And what is the alternative? How do you handle any non trivial load in any other language? Without a second thread or while loop. Because apparently you dislike both. You like it sync for your database -> while loop somewhere, but while loops are bad. But asynchronous is bad because it adds complexity to your code when you use functions to reduce the nesting.

        On nodejs, the platform that you talked about earlier, they are literally called worker_threads". So they are different? How? Why can’t you use them?

        • ☆ Yσɠƚԋσʂ ☆@lemmy.mlOP
          link
          fedilink
          arrow-up
          1
          arrow-down
          9
          ·
          1 year ago

          I literally just explained this to you in a prior comment. Let’s say you have a web server that’s accepting connections. You have one thread that grabs the connection and spawns a thread from a pool of workers threads to handle it. Then it goes back to listening for connections. This is how things work on platforms like the JVM. The runtime manages the execution of the threads. This is similar to the way the OS handles scheduling processes. When you’d doing async by hand you’re basically handrolling your own scheduler each time.

          What stops you from using worker threads is lack of ergonomics. Just the fact that each worker has to live in a separate file creates friction. In a sane language you can just do new Thread().start() and you’re done. In Js it’s a Rube Goldberg machine as always. When you look at at actual code people write in Js, you see async code everywhere. So, maybe you can answer why you think that is, and why people aren’t using worker threads to write sync style code they’d write in other languages.

          • Tartas1995
            link
            fedilink
            arrow-up
            1
            ·
            1 year ago

            You seem to misunderstand my points.

            And I don’t think you want to.

            • ☆ Yσɠƚԋσʂ ☆@lemmy.mlOP
              link
              fedilink
              arrow-up
              1
              arrow-down
              9
              ·
              1 year ago

              I’ve directly addressed your points, and I get the impression that you’re the one who’s ignoring my points here. The reality is that blocking operations in js are handled using async calls, and reasoning about async code is inherently more difficult than sync code. Platforms that provide proper threading allow developers to write sync style code and handle blocking by using threads that are managed by the runtime. While you have workers in Js, it’s pretty clear that they’re not meant to be used in the same way, nor do people use them this way in practice.