5 ms·

There's a huge amount of technical jargon and sarcasm that makes it hard to see her point. Basically she's saying that python async (which the current state of

There's a huge amount of technical jargon and sarcasm that makes it hard to see her point. Basically she's saying that python async (which the current state of the art implementation uses libuv the same thing driving nodejs and consequently suffers from the same "problems") doesn't have actual concurrency. Computations block and concurrency only happens under a very specific case: IO. One computation can happen at a time with several IO calls in flight and context switching can only happen when an IO call in the computation occurs. She fails to see why this is good: Python async and nodejs do not need concurrency primitives like locks. You cannot have a deadlock happen under this model period. (note I'm not talking about python threading, I'm talking about async/await) This pattern was designed for simple pipeline programming for webapps where the webapp just does some minor translations and authentication then offloads the actual processing to an external computation engine (usually known as a database). This is where the real processing meat happens but most programmers just deal with this stuff through an API (usually called SQL). It's good to not have to deal with locks, mutexes, deadlocks and race conditions in the webapp. This is a huge benefit in terms of managing complexity which she completely discounts.

eropple 7y ago
> Python async and nodejs do not need concurrency primitives like locks. You cannot have a deadlock happen under this model period. This is dangerously wrong and I would suggest that you reconsider the steps that got you to this understanding because something really important has been lost. It is absolutely critical to understand that deadlocks are not why you have locks. Correctness during concurrent operation is why you have locks. Deadlocks are a failure state when you do not have correctness during concurrent operation. So are things like double-increment and double-create. Parallelism does not imply deadlocking, concurrency implies deadlocking, and both NodeJS and Python are concurrent runtime environments. And I can guarantee you that, with a little skull sweat, you can write a deadlock in NodeJS or Python. It is very easy. If you need some help, here's a trivial example (and ordinarily I wouldn't use a link shortener here but this one is hefty, it just goes to the Typescript playground): https://bit.ly/2Tvjyze https://bit.ly/2Tvjyze Also, as a concrete, real-world, yes-it-happens-here example of where locking is important, consider that I've recently built a dependency injection framework in NodeJS--tried to use others' first, but my situation isn't covered by existing ones--and had to resort to a mutex to avoid double creation of objects within a single lifecycle. Creation of objects within this lifecycle happens asynchronously--it has to, as the act of creating the objects might itself rely on asynchronous operations. So, if I were to have a diamond-dependency (A deps B and C, B and C dep D), I will non-deterministically, and based on the creation time of B and C, create either one or two instances of D. I rely upon a mutex, keyed upon the dependency being created, to ensure that this does not happen. . I would also submit that perhaps you should adopt a principle of charity and think real hard about whether your priors are correct before you start talking about what she "fails" to see. Rachel is one of those people who has Been Around and while I also have Been Around, I understand that Rachel has Been Around More and I probably should be listening more than I should be smarming at her. Just a thought.
- crimsonalucard 7y ago
  >Parallelism does not imply deadlocking, concurrency implies deadlocking, and both NodeJS and Python are concurrent runtime environments. And I can guarantee you that, with a little skull sweat, you can write a deadlock in NodeJS or Python. It is very easy. If you need some help, here's a trivial example: https://codesandbox.io/s/2wxvp https://codesandbox.io/s/2wxvp Ok technically you're right. I am completely wrong when I say it can NEVER happen. But let's be real here, you introduced DEADLOCKING deliberately by introducing LOCKS and by doing context switching at weird places to make it happen. When nodejs came out one of the selling points was the lack of deadlocks and locks. Case in point: there are no lock libraries in standard NodeJS. Think about it, why is a LOCK needed here? Let's say you didn't have locks AT all. Wherever the heck you are the current Node task technically has what is equivalent to a LOCK on everything. Why? because all node instructions are atomic and single threaded. This is what replaces LOCKS in nodejs. Your code example is just strange. The only place where your example is relevant is if there was another process. >But as a concrete example of where locking is important, consider that I've recently built a dependency injection framework in NodeJS--tried to use others' first, but my situation isn't covered by existing ones-- Probably because, again, nobody really programs using DP in node let alone context switching and adding made up locks in the middle of all these injections and constructions. Whatever you're doing is probably very unique or (maybe, I don't know your specific situation) a sign over engineering. DP is a very bad pattern and is one of the primary sources of technical debt in code (especially when it's over 2 layers deep and in a diamond configuration)... but that's another topic. Anyway... What is the point of "acquiring" a lock if in node I have a "LOCK" on everything? It makes no sense, whatever it is you're doing I am almost positive that there is a simpler way of doing it. Either way the dependency chain makes it obvious which needs to be created first and what can be created concurrently. The below psuedo code should produce what you're looking for without locks and with equivalent concurrency which is one of the main selling points of single threaded async. b, c = await runAsync([B, () => C(await D())]) a = await A(b, c) B is evaluated with D async, C is kickstarted after D, with B still being evaluated async. All of this blocks until both B and C are complete then A evaluates. Whatever the heck you're doing with locks, things should happen in the same order as the dependency chain in both my code and one with locks. There's really no other order these things can be evaluated. I would even argue that my code is indeed the canonical way to handle your diamond problem in node, no lock code needed as expressed by the standard node library. Think about it, node includes high level functions for http but none for locks which are an even lower level concept than http. It must mean you aren't supposed to use locks in Node. I will say you are technically right in the fact that a deadlock CAN happen. I was wrong in saying it can NEVER happen, but you have to realize that I have a point here. Your example is really going very very far out of the way to pull it off. >I would also submit that perhaps you should adopt a principle of charity and think real hard about whether your priors are correct before you start talking about what she "fails" to see. Rachel is one of those people who has Been Around and while I also have Been Around, I understand that Rachel has Been Around More and I probably should be listening more than I should be smarming at her. I was not smarming her, whatever smarming means, I am disagreeing with her just like you are disagreeing with me. There is NOTHING wrong with disagreeing with anybody. What is wrong is when you are proven wrong and you don't accept it. I accept that my statement of a deadlock NEVER happening in nodejs is categorically wrong. "Being around" does not entitle you to anything. I hate it when people say this, nothing personal. Do you even know how long I've been around? Additionally, the overall main point of my post still stands, which you didn't even really address. I don't think Rachel gets the point of green threads. I think we can both agree I've made a strong point and maybe you should use your own charity principles on me. Just a thought.

eropple 7y ago

> Python async and nodejs do not need concurrency primitives like locks. You cannot have a deadlock happen under this model period. This is dangerously wrong and I would suggest that you reconsider the steps that got you to this understanding because something really important has been lost. It is absolutely critical to understand that deadlocks are not why you have locks. Correctness during concurrent operation is why you have locks. Deadlocks are a failure state when you do not have correctness during concurrent operation. So are things like double-increment and double-create. Parallelism does not imply deadlocking, concurrency implies deadlocking, and both NodeJS and Python are concurrent runtime environments. And I can guarantee you that, with a little skull sweat, you can write a deadlock in NodeJS or Python. It is very easy. If you need some help, here's a trivial example (and ordinarily I wouldn't use a link shortener here but this one is hefty, it just goes to the Typescript playground): https://bit.ly/2Tvjyze https://bit.ly/2Tvjyze Also, as a concrete, real-world, yes-it-happens-here example of where locking is important, consider that I've recently built a dependency injection framework in NodeJS--tried to use others' first, but my situation isn't covered by existing ones--and had to resort to a mutex to avoid double creation of objects within a single lifecycle. Creation of objects within this lifecycle happens asynchronously--it has to, as the act of creating the objects might itself rely on asynchronous operations. So, if I were to have a diamond-dependency (A deps B and C, B and C dep D), I will non-deterministically, and based on the creation time of B and C, create either one or two instances of D. I rely upon a mutex, keyed upon the dependency being created, to ensure that this does not happen. . I would also submit that perhaps you should adopt a principle of charity and think real hard about whether your priors are correct before you start talking about what she "fails" to see. Rachel is one of those people who has Been Around and while I also have Been Around, I understand that Rachel has Been Around More and I probably should be listening more than I should be smarming at her. Just a thought.

crimsonalucard 7y ago
>Parallelism does not imply deadlocking, concurrency implies deadlocking, and both NodeJS and Python are concurrent runtime environments. And I can guarantee you that, with a little skull sweat, you can write a deadlock in NodeJS or Python. It is very easy. If you need some help, here's a trivial example: https://codesandbox.io/s/2wxvp https://codesandbox.io/s/2wxvp Ok technically you're right. I am completely wrong when I say it can NEVER happen. But let's be real here, you introduced DEADLOCKING deliberately by introducing LOCKS and by doing context switching at weird places to make it happen. When nodejs came out one of the selling points was the lack of deadlocks and locks. Case in point: there are no lock libraries in standard NodeJS. Think about it, why is a LOCK needed here? Let's say you didn't have locks AT all. Wherever the heck you are the current Node task technically has what is equivalent to a LOCK on everything. Why? because all node instructions are atomic and single threaded. This is what replaces LOCKS in nodejs. Your code example is just strange. The only place where your example is relevant is if there was another process. >But as a concrete example of where locking is important, consider that I've recently built a dependency injection framework in NodeJS--tried to use others' first, but my situation isn't covered by existing ones-- Probably because, again, nobody really programs using DP in node let alone context switching and adding made up locks in the middle of all these injections and constructions. Whatever you're doing is probably very unique or (maybe, I don't know your specific situation) a sign over engineering. DP is a very bad pattern and is one of the primary sources of technical debt in code (especially when it's over 2 layers deep and in a diamond configuration)... but that's another topic. Anyway... What is the point of "acquiring" a lock if in node I have a "LOCK" on everything? It makes no sense, whatever it is you're doing I am almost positive that there is a simpler way of doing it. Either way the dependency chain makes it obvious which needs to be created first and what can be created concurrently. The below psuedo code should produce what you're looking for without locks and with equivalent concurrency which is one of the main selling points of single threaded async. b, c = await runAsync([B, () => C(await D())]) a = await A(b, c) B is evaluated with D async, C is kickstarted after D, with B still being evaluated async. All of this blocks until both B and C are complete then A evaluates. Whatever the heck you're doing with locks, things should happen in the same order as the dependency chain in both my code and one with locks. There's really no other order these things can be evaluated. I would even argue that my code is indeed the canonical way to handle your diamond problem in node, no lock code needed as expressed by the standard node library. Think about it, node includes high level functions for http but none for locks which are an even lower level concept than http. It must mean you aren't supposed to use locks in Node. I will say you are technically right in the fact that a deadlock CAN happen. I was wrong in saying it can NEVER happen, but you have to realize that I have a point here. Your example is really going very very far out of the way to pull it off. >I would also submit that perhaps you should adopt a principle of charity and think real hard about whether your priors are correct before you start talking about what she "fails" to see. Rachel is one of those people who has Been Around and while I also have Been Around, I understand that Rachel has Been Around More and I probably should be listening more than I should be smarming at her. I was not smarming her, whatever smarming means, I am disagreeing with her just like you are disagreeing with me. There is NOTHING wrong with disagreeing with anybody. What is wrong is when you are proven wrong and you don't accept it. I accept that my statement of a deadlock NEVER happening in nodejs is categorically wrong. "Being around" does not entitle you to anything. I hate it when people say this, nothing personal. Do you even know how long I've been around? Additionally, the overall main point of my post still stands, which you didn't even really address. I don't think Rachel gets the point of green threads. I think we can both agree I've made a strong point and maybe you should use your own charity principles on me. Just a thought.