Asynchronous waaahh???
-
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
-
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
Not a fan of async methods myself (in C#). I had never experienced them before, but I recently had to figure how to call them synchronously in order to use some third-party software which insisted -- for no reason that I could tell.
-
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
Whenever I have to use the fetch API in JavaScript, I need to use an asynchronous function because fetch is inherently asynchronous and returns a promise. I sometimes create a promise object within synchronous functions, and that seems to work OK as well. I suppose that if I used promises the way they're meant to be used, they'd be great. Sometimes promises don't return a response and are rejected. I should probably bother to address that in my code but I just don't. The only times I need to use promises, and asynchronous functions with the await keyword are when I need to retrieve XML, JSON, or HTTP data. The XMLHttpRequest runs just fine synchronously but it's always a good idea to use an asynchronous function and the await keyword anyway. Considering that JavaScript runs as a single thread, asynchronicity is nice to have. So, no, wouldn't say you're alone in that.
-
Not a fan of async methods myself (in C#). I had never experienced them before, but I recently had to figure how to call them synchronously in order to use some third-party software which insisted -- for no reason that I could tell.
Unfortunately, I mean you know how it is, when a new buzzword is created so many peeps jump on the bandwagon as a excuse to use just to sound cool. So, I could totally see it being unnecessarily used. But, I don't see that as a problem with the simplified syntax. I see is as a people problem not really bothering to learn crap. There are things that inherently should be asynchronous. File IO, Network IO, etc. Your application should never lock up if there's a problem or it's slow, etc. However, it's also nice to be able to simply say in simple syntax wait for this crap because because because. It's really nothing more fancy than that. Maybe there should be two hotlines... one for macro abuse and another for async/await abuse. :laugh:
Jeremy Falcon
-
Whenever I have to use the fetch API in JavaScript, I need to use an asynchronous function because fetch is inherently asynchronous and returns a promise. I sometimes create a promise object within synchronous functions, and that seems to work OK as well. I suppose that if I used promises the way they're meant to be used, they'd be great. Sometimes promises don't return a response and are rejected. I should probably bother to address that in my code but I just don't. The only times I need to use promises, and asynchronous functions with the await keyword are when I need to retrieve XML, JSON, or HTTP data. The XMLHttpRequest runs just fine synchronously but it's always a good idea to use an asynchronous function and the await keyword anyway. Considering that JavaScript runs as a single thread, asynchronicity is nice to have. So, no, wouldn't say you're alone in that.
Totally agree man. It's JS we're talking about, so I'm about to yap a lot... :laugh: :laugh: In JavaScript async/await is especially important. JavaScript by it's very nature is meant to be non-blocking. Without getting too much into the history of it for one post, I'll just say that's a strength of JavaScript. But, it does come with some gotchas, as you mentioned. Here's the 30 second history of it dealing with non-blocking code in JS. In the beginning, there were callbacks. The Lord spoketh, thy non-blocking code doesn't return. Thou shalt use callbacks. :laugh: Now callbacks were great, but they don't chain. And things got convoluted real quick. JS will always be non-blocking, so then now what? Promises! They came about to deliver us from callback craziness. They chained... all was well... until folks realized promised also go complicated too. You could have like 10 promises all with nested variables (closures helped with this a bit), but it got messy if a coder didn't modularize crap nicely. Now, the reason I said all that was because, all async/wait is in JS is syntax sugar for promises. You can in fact return a promise and call it with await. It'll work. Even though it's just syntax sugar, it still cleans things up and makes variable scoping with return values, etc. muuuuuuch less cumbersome. Oh side note, throwing an exception in an async function is no different than rejecting a promise. Just cleaner syntax.
Jeremy Falcon
-
Unfortunately, I mean you know how it is, when a new buzzword is created so many peeps jump on the bandwagon as a excuse to use just to sound cool. So, I could totally see it being unnecessarily used. But, I don't see that as a problem with the simplified syntax. I see is as a people problem not really bothering to learn crap. There are things that inherently should be asynchronous. File IO, Network IO, etc. Your application should never lock up if there's a problem or it's slow, etc. However, it's also nice to be able to simply say in simple syntax wait for this crap because because because. It's really nothing more fancy than that. Maybe there should be two hotlines... one for macro abuse and another for async/await abuse. :laugh:
Jeremy Falcon
Certainly. And maybe using threads can be confusing to some. But I spin up threads whenever I need to. And not when I don't.
-
Certainly. And maybe using threads can be confusing to some. But I spin up threads whenever I need to. And not when I don't.
Touché :laugh:
Jeremy Falcon
-
Unfortunately, I mean you know how it is, when a new buzzword is created so many peeps jump on the bandwagon as a excuse to use just to sound cool. So, I could totally see it being unnecessarily used. But, I don't see that as a problem with the simplified syntax. I see is as a people problem not really bothering to learn crap. There are things that inherently should be asynchronous. File IO, Network IO, etc. Your application should never lock up if there's a problem or it's slow, etc. However, it's also nice to be able to simply say in simple syntax wait for this crap because because because. It's really nothing more fancy than that. Maybe there should be two hotlines... one for macro abuse and another for async/await abuse. :laugh:
Jeremy Falcon
Jeremy Falcon wrote:
should be asynchronous. File IO, Network IO,
Uh, say what? I don't see it.
-
Jeremy Falcon wrote:
should be asynchronous. File IO, Network IO,
Uh, say what? I don't see it.
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
-
Totally agree man. It's JS we're talking about, so I'm about to yap a lot... :laugh: :laugh: In JavaScript async/await is especially important. JavaScript by it's very nature is meant to be non-blocking. Without getting too much into the history of it for one post, I'll just say that's a strength of JavaScript. But, it does come with some gotchas, as you mentioned. Here's the 30 second history of it dealing with non-blocking code in JS. In the beginning, there were callbacks. The Lord spoketh, thy non-blocking code doesn't return. Thou shalt use callbacks. :laugh: Now callbacks were great, but they don't chain. And things got convoluted real quick. JS will always be non-blocking, so then now what? Promises! They came about to deliver us from callback craziness. They chained... all was well... until folks realized promised also go complicated too. You could have like 10 promises all with nested variables (closures helped with this a bit), but it got messy if a coder didn't modularize crap nicely. Now, the reason I said all that was because, all async/wait is in JS is syntax sugar for promises. You can in fact return a promise and call it with await. It'll work. Even though it's just syntax sugar, it still cleans things up and makes variable scoping with return values, etc. muuuuuuch less cumbersome. Oh side note, throwing an exception in an async function is no different than rejecting a promise. Just cleaner syntax.
Jeremy Falcon
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
-
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
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 -
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, 2013Yeah, 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
-
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
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
-
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
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 -
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
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.
-
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
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.
-
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.
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
-
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.
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
-
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
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.
-
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
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.