Skip to content
  • Categories
  • Recent
  • Tags
  • Popular
  • World
  • Users
  • Groups
Skins
  • Light
  • Cerulean
  • Cosmo
  • Flatly
  • Journal
  • Litera
  • Lumen
  • Lux
  • Materia
  • Minty
  • Morph
  • Pulse
  • Sandstone
  • Simplex
  • Sketchy
  • Spacelab
  • United
  • Yeti
  • Zephyr
  • Dark
  • Cyborg
  • Darkly
  • Quartz
  • Slate
  • Solar
  • Superhero
  • Vapor

  • Default (No Skin)
  • No Skin
Collapse
Code Project
  1. Home
  2. The Lounge
  3. Asynchronous waaahh???

Asynchronous waaahh???

Scheduled Pinned Locked Moved The Lounge
javascriptasp-netalgorithmsquestion
30 Posts 5 Posters 0 Views 1 Watching
  • Oldest to Newest
  • Newest to Oldest
  • Most Votes
Reply
  • Reply as topic
Log in to reply
This topic has been deleted. Only users with topic management privileges can see it.
  • J Jeremy Falcon

    So, here I am... n00bing it up in a new language and getting my learn on. Wut wut. And I come accross a feature that's postponed for now as the language is still young... async routines. Ok, I get it. It's new to the party. I can still do multi-threading, so not end of the world should I need to block something that would otherwise be non-blocking. Buuuuuuuttt, ran across a few posts online with the typical "I never used it so I hate it" mantra. And it got me wondering, do people really hate the concept of asynchronous routines? Seems to me the only people that hate it just don't know it. Like at its core (using JavaScript as a reference) all it does is reduce complexity with what would otherwise be non-blocking code. Fail to see why that's so bad. Using pseudocode...

    function bruh() {
    const response = fetch('/stuff');
    // omg, we not done
    console.log(response);
    }

    async function bro() {
    const response = await fetch('/stuff');
    // omg, we done
    console.log(response);
    }

    Like, why is that so bad? I bet these people would freak out over the concept of generators. :laugh: I just don't see why people would hate this. Am I not alone with this thought?

    Jeremy Falcon

    R Offline
    R Offline
    realJSOP
    wrote on last edited by
    #11

    Javascript is crap, and so are async functions, especially if you need to wait for something to happen before proceeding with execution, or return a value that isn't a Promise.

    ".45 ACP - because shooting twice is just silly" - JSOP, 2010
    -----
    You can never have too much ammo - unless you're swimming, or on fire. - JSOP, 2010
    -----
    When you pry the gun from my cold dead hands, be careful - the barrel will be very hot. - JSOP, 2013

    J 1 Reply Last reply
    0
    • R realJSOP

      Javascript is crap, and so are async functions, especially if you need to wait for something to happen before proceeding with execution, or return a value that isn't a Promise.

      ".45 ACP - because shooting twice is just silly" - JSOP, 2010
      -----
      You can never have too much ammo - unless you're swimming, or on fire. - JSOP, 2010
      -----
      When you pry the gun from my cold dead hands, be careful - the barrel will be very hot. - JSOP, 2013

      J Offline
      J Offline
      Jeremy Falcon
      wrote on last edited by
      #12

      Yeah, I'm not interested in entertaining this nonsense man. You JS haters have nothing new to say and none of y'all experts in it. We're supposed to be adults man... supposed to be.

      Jeremy Falcon

      R 1 Reply Last reply
      0
      • M maze3

        this. was trying to recall why I disliked asynchronous, and something with JavaScript, but seeing op post and then quick lookup "var response = await fetch(url)", that seems so easy. Thinking I thought you had to do callback functions. So yeah, you can do both, oh neat. But that whole callback thing urks me. It's more how the flow of data I see in my head function get this data now with the data do X thing but callback function get this data end function some other function now do thing with this data its that separation of functions which my internal mapping does not like

        J Offline
        J Offline
        Jeremy Falcon
        wrote on last edited by
        #13

        For sure man, no doubt JS is different. It's single threaded and non-blocking, so it comes with a shift in thinking. And wrapping your head around it might take some... effort. :laugh: Personally, my beef with anything is JS related isn't the language, is the childish behavior with some (not you) who see something different and just hate it because they're stuck in the past, refusing to learn, arrogantly assume they know everything, etc. Like, um... what? We're adults... I think. :laugh: Anyway, great post. Sorry for the mini-rant.

        Jeremy Falcon

        P 1 Reply Last reply
        0
        • J Jeremy Falcon

          Yeah, I'm not interested in entertaining this nonsense man. You JS haters have nothing new to say and none of y'all experts in it. We're supposed to be adults man... supposed to be.

          Jeremy Falcon

          R Offline
          R Offline
          realJSOP
          wrote on last edited by
          #14

          Whatever dude...

          ".45 ACP - because shooting twice is just silly" - JSOP, 2010
          -----
          You can never have too much ammo - unless you're swimming, or on fire. - JSOP, 2010
          -----
          When you pry the gun from my cold dead hands, be careful - the barrel will be very hot. - JSOP, 2013

          1 Reply Last reply
          0
          • J Jeremy Falcon

            If you have a potentially long running process (because of a timeout on failure, etc.) your application shouldn't lock up because of it. Too many instances of trying to cancel a command line app or use a GUI that just locks while it's off just chillin.

            Jeremy Falcon

            P Offline
            P Offline
            PIEBALDconsult
            wrote on last edited by
            #15

            Maybe you are thinking only of GUI applications? I write mostly command-line utilities and they take and long as they take. I tend to have them log something every ten seconds or so so you know it's still at it and not just gone down to the pub. In a WinForms application, I might spin up a thread, and use a ProgressBar or something if possible.

            J 1 Reply Last reply
            0
            • J Jeremy Falcon

              For sure man, no doubt JS is different. It's single threaded and non-blocking, so it comes with a shift in thinking. And wrapping your head around it might take some... effort. :laugh: Personally, my beef with anything is JS related isn't the language, is the childish behavior with some (not you) who see something different and just hate it because they're stuck in the past, refusing to learn, arrogantly assume they know everything, etc. Like, um... what? We're adults... I think. :laugh: Anyway, great post. Sorry for the mini-rant.

              Jeremy Falcon

              P Offline
              P Offline
              PIEBALDconsult
              wrote on last edited by
              #16

              Jeremy Falcon wrote:

              single threaded and non-blocking

              Sounds like it would be blocking, not non-blocking. I didn't see how you have non-blocking with a single thread. Unless they've redefined what blocking and non-blocking mean.

              J 1 Reply Last reply
              0
              • P PIEBALDconsult

                Maybe you are thinking only of GUI applications? I write mostly command-line utilities and they take and long as they take. I tend to have them log something every ten seconds or so so you know it's still at it and not just gone down to the pub. In a WinForms application, I might spin up a thread, and use a ProgressBar or something if possible.

                J Offline
                J Offline
                Jeremy Falcon
                wrote on last edited by
                #17

                Same applies on the console. If you cannot cancel a long running process then that's no bueno. If data integrity is a concern then making operations atomic should be a consideration. It's never a good idea to look up a computer more than a second or so.

                Jeremy Falcon

                P 1 Reply Last reply
                0
                • P PIEBALDconsult

                  Jeremy Falcon wrote:

                  single threaded and non-blocking

                  Sounds like it would be blocking, not non-blocking. I didn't see how you have non-blocking with a single thread. Unless they've redefined what blocking and non-blocking mean.

                  J Offline
                  J Offline
                  Jeremy Falcon
                  wrote on last edited by
                  #18

                  JavaScript has a very specialized execution engine that everything goes though. Not sure how much you wanna read up on it, but if you're curious Google "javascript event loop". Its entire runtime model is designed to be non-blocking and runs on a single thread. Makes it brain dead simple to have several worker scripts running at the same time. Don't have to worry about inter-thread communication and still get the benefit of always being non-blocking. But, there are tradeoffs and that's where those new to JavaScript usually freak out.

                  Jeremy Falcon

                  P 1 Reply Last reply
                  0
                  • J Jeremy Falcon

                    Same applies on the console. If you cannot cancel a long running process then that's no bueno. If data integrity is a concern then making operations atomic should be a consideration. It's never a good idea to look up a computer more than a second or so.

                    Jeremy Falcon

                    P Offline
                    P Offline
                    PIEBALDconsult
                    wrote on last edited by
                    #19

                    Jeremy Falcon wrote:

                    never a good idea to look up a computer more than a second or so.

                    Bullpuckey. Ctrl-C kills most console utilities anyway. Not a problem.

                    J 1 Reply Last reply
                    0
                    • J Jeremy Falcon

                      JavaScript has a very specialized execution engine that everything goes though. Not sure how much you wanna read up on it, but if you're curious Google "javascript event loop". Its entire runtime model is designed to be non-blocking and runs on a single thread. Makes it brain dead simple to have several worker scripts running at the same time. Don't have to worry about inter-thread communication and still get the benefit of always being non-blocking. But, there are tradeoffs and that's where those new to JavaScript usually freak out.

                      Jeremy Falcon

                      P Offline
                      P Offline
                      PIEBALDconsult
                      wrote on last edited by
                      #20

                      Truly not interested in it. Is it time-sharing one thread in the engine? Or does each process get one thread in the engine? Unsure that the terms "blocking" and "non-blocking" truly apply to the situation.

                      J 1 Reply Last reply
                      0
                      • P PIEBALDconsult

                        Truly not interested in it. Is it time-sharing one thread in the engine? Or does each process get one thread in the engine? Unsure that the terms "blocking" and "non-blocking" truly apply to the situation.

                        J Offline
                        J Offline
                        Jeremy Falcon
                        wrote on last edited by
                        #21

                        PIEBALDconsult wrote:

                        Truly not interested in it.

                        :laugh:

                        PIEBALDconsult wrote:

                        Is it time-sharing one thread in the engine? Or does each process get one thread in the engine?

                        If I were to give it an oversimplification, the time sharing analogy fits perfectly. It's all in one thing, but no one particular bit of code will block the app in the traditional since, since they all get their orders from the event loop. Now, all of this is under the hood of course, and most peeps will never notice what's going on.

                        PIEBALDconsult wrote:

                        Unsure that the terms "blocking" and "non-blocking" truly apply to the situation.

                        Fair enough. When I say non-blocking, I mean something along the lines of this:

                        JavaScript is also known for it’s non-blocking behavior. Non-blocking means that JavaScript doesn’t wait for the response of an API call, an Ajax request, an I/O event or a timer but moves on with the other block of code below it.

                        Stuff like methods, etc. can block execution, but a lot of peeps opted for routines that do not block and that's where callback hell came from. The event loop made this a breeze to deal with because of the way it scheduled execution and returns. So, I kinda just lump sum crap when I talk about it these days. Old age stuff. :laugh:

                        Jeremy Falcon

                        P 1 Reply Last reply
                        0
                        • P PIEBALDconsult

                          Jeremy Falcon wrote:

                          never a good idea to look up a computer more than a second or so.

                          Bullpuckey. Ctrl-C kills most console utilities anyway. Not a problem.

                          J Offline
                          J Offline
                          Jeremy Falcon
                          wrote on last edited by
                          #22

                          Gotta disagree there, it sends a signal like [SIGINT](https://www.gnu.org/software/libc/manual/html\_node/Termination-Signals.html) which can totally be ignored if a program hangs. I've had way more than one app just tell me "whatever bro" after smashing Ctrl+C over and over.

                          Jeremy Falcon

                          P 1 Reply Last reply
                          0
                          • J Jeremy Falcon

                            PIEBALDconsult wrote:

                            Truly not interested in it.

                            :laugh:

                            PIEBALDconsult wrote:

                            Is it time-sharing one thread in the engine? Or does each process get one thread in the engine?

                            If I were to give it an oversimplification, the time sharing analogy fits perfectly. It's all in one thing, but no one particular bit of code will block the app in the traditional since, since they all get their orders from the event loop. Now, all of this is under the hood of course, and most peeps will never notice what's going on.

                            PIEBALDconsult wrote:

                            Unsure that the terms "blocking" and "non-blocking" truly apply to the situation.

                            Fair enough. When I say non-blocking, I mean something along the lines of this:

                            JavaScript is also known for it’s non-blocking behavior. Non-blocking means that JavaScript doesn’t wait for the response of an API call, an Ajax request, an I/O event or a timer but moves on with the other block of code below it.

                            Stuff like methods, etc. can block execution, but a lot of peeps opted for routines that do not block and that's where callback hell came from. The event loop made this a breeze to deal with because of the way it scheduled execution and returns. So, I kinda just lump sum crap when I talk about it these days. Old age stuff. :laugh:

                            Jeremy Falcon

                            P Offline
                            P Offline
                            PIEBALDconsult
                            wrote on last edited by
                            #23

                            OK. Seems OK given the language's primary usage. But backward for general purpose development. We (many of us) keep asking for more and more cores and hyperthreading so we don't have to share a thread. From my point-of-view, the caller should be able to request blocking or non-blocking behavior as appropriate for the current task. If I have to wait for an asynchronous call to complete anyway, then why bother going through all that trouble. </rhetorical> I would much rather spin up a thread on my side as needed. It seems you don't have that luxury.

                            J 1 Reply Last reply
                            0
                            • P PIEBALDconsult

                              OK. Seems OK given the language's primary usage. But backward for general purpose development. We (many of us) keep asking for more and more cores and hyperthreading so we don't have to share a thread. From my point-of-view, the caller should be able to request blocking or non-blocking behavior as appropriate for the current task. If I have to wait for an asynchronous call to complete anyway, then why bother going through all that trouble. </rhetorical> I would much rather spin up a thread on my side as needed. It seems you don't have that luxury.

                              J Offline
                              J Offline
                              Jeremy Falcon
                              wrote on last edited by
                              #24

                              For sure, but it's just a different way of thinking. Personally, I like both models and think JS (despite its beginnings) has come a long way and does some really interesting stuff.

                              Jeremy Falcon

                              1 Reply Last reply
                              0
                              • J Jeremy Falcon

                                Gotta disagree there, it sends a signal like [SIGINT](https://www.gnu.org/software/libc/manual/html\_node/Termination-Signals.html) which can totally be ignored if a program hangs. I've had way more than one app just tell me "whatever bro" after smashing Ctrl+C over and over.

                                Jeremy Falcon

                                P Offline
                                P Offline
                                PIEBALDconsult
                                wrote on last edited by
                                #25

                                Never, not once. But then again, I don't write utilities which hang. And Ctrl-Z on OpenVMS.

                                J 1 Reply Last reply
                                0
                                • P PIEBALDconsult

                                  Never, not once. But then again, I don't write utilities which hang. And Ctrl-Z on OpenVMS.

                                  J Offline
                                  J Offline
                                  Jeremy Falcon
                                  wrote on last edited by
                                  #26

                                  I dunno what apps you've used, but clearly we've used different ones. Either way, looks like we're gonna disagree on whether or not some things should be non-blocking. I still still think non-blocking is cool and the way to go, if possible. Oh the upside, it's Saturday and there's ice cream to be had. :laugh:

                                  Jeremy Falcon

                                  P 1 Reply Last reply
                                  0
                                  • J Jeremy Falcon

                                    I dunno what apps you've used, but clearly we've used different ones. Either way, looks like we're gonna disagree on whether or not some things should be non-blocking. I still still think non-blocking is cool and the way to go, if possible. Oh the upside, it's Saturday and there's ice cream to be had. :laugh:

                                    Jeremy Falcon

                                    P Offline
                                    P Offline
                                    PIEBALDconsult
                                    wrote on last edited by
                                    #27

                                    It certainly has its uses, but that doesn't mean that it should be forced on everyone all the time. Use it when it makes sense, same with everything. Something to bear in mind is whether or not you have anything else to do while you wait. If not, you're still just waiting. Or, in a real language, I can spin up a thread and do other things in my process, zing bang Bob's your mascot.

                                    J 1 Reply Last reply
                                    0
                                    • P PIEBALDconsult

                                      It certainly has its uses, but that doesn't mean that it should be forced on everyone all the time. Use it when it makes sense, same with everything. Something to bear in mind is whether or not you have anything else to do while you wait. If not, you're still just waiting. Or, in a real language, I can spin up a thread and do other things in my process, zing bang Bob's your mascot.

                                      J Offline
                                      J Offline
                                      Jeremy Falcon
                                      wrote on last edited by
                                      #28

                                      PIEBALDconsult wrote:

                                      Something to bear in mind is whether or not you have anything else to do while you wait. If not, you're still just waiting.

                                      I'm trying to end this discussion because it's going nowhere man. I've already mentioned there is always something to do, like respond to user input or signals. It's clear you have zero desire to agree with me, so not sure why we be dragging this out man. If you need to read a 1 byte file that's guaranteed to be small, cool... assuming it's local and not network attached. I'm referring to long operations. Not sure why this needs to be dragged out.

                                      Jeremy Falcon

                                      P 1 Reply Last reply
                                      0
                                      • J Jeremy Falcon

                                        PIEBALDconsult wrote:

                                        Something to bear in mind is whether or not you have anything else to do while you wait. If not, you're still just waiting.

                                        I'm trying to end this discussion because it's going nowhere man. I've already mentioned there is always something to do, like respond to user input or signals. It's clear you have zero desire to agree with me, so not sure why we be dragging this out man. If you need to read a 1 byte file that's guaranteed to be small, cool... assuming it's local and not network attached. I'm referring to long operations. Not sure why this needs to be dragged out.

                                        Jeremy Falcon

                                        P Offline
                                        P Offline
                                        PIEBALDconsult
                                        wrote on last edited by
                                        #29

                                        Again, I write mostly back-end stuff, there's no user input or anything. A long-running task is still going to take a while. Querying a database for some data and writing it to a file of some sort could take minutes or longer no matter what. And I can use a different process to do something else at the same time. Or spin up multiple threads in one process to write multiple files, no big deal. That's my bread and butter. Other languages can support other needs.

                                        J 1 Reply Last reply
                                        0
                                        • P PIEBALDconsult

                                          Again, I write mostly back-end stuff, there's no user input or anything. A long-running task is still going to take a while. Querying a database for some data and writing it to a file of some sort could take minutes or longer no matter what. And I can use a different process to do something else at the same time. Or spin up multiple threads in one process to write multiple files, no big deal. That's my bread and butter. Other languages can support other needs.

                                          J Offline
                                          J Offline
                                          Jeremy Falcon
                                          wrote on last edited by
                                          #30

                                          A user can be a script. Clearly, you just don't wanna agree man. :laugh: But hey... ice cream.

                                          Jeremy Falcon

                                          1 Reply Last reply
                                          0
                                          Reply
                                          • Reply as topic
                                          Log in to reply
                                          • Oldest to Newest
                                          • Newest to Oldest
                                          • Most Votes


                                          • Login

                                          • Don't have an account? Register

                                          • Login or register to search.
                                          • First post
                                            Last post
                                          0
                                          • Categories
                                          • Recent
                                          • Tags
                                          • Popular
                                          • World
                                          • Users
                                          • Groups