4 ms·

Please state you musings about the async. I'm just getting into that right now and I wonder if my misgivings are a result of my age or a fundamental issue with

Please state you musings about the async. I'm just getting into that right now and I wonder if my misgivings are a result of my age or a fundamental issue with the Python implementation of the concept. Seriously, all and any insight and advice appreciated. Thanks.

rednafi 2y ago
[flagged]
- neonsunset 2y ago
  [flagged]
  - rednafi 2y ago
    [flagged]
    - neonsunset 2y ago
      > Bob Nystrom worked on Dart at Google and wrote the amazing Crafting Interpreters book. Rob Pike referenced this article in his 2023 talk, Go: What We Got Right, What We Got Wrong, while discussing the trade-offs between CSP and coroutine-driven concurrency. I know, which is the exact reason the reply states "uncharacteristically". And yet, it fails to acknowledge existing terminology and tradeoffs and just states at the end in a couple paragraphs how Goroutines shall deliver us all from evil (which could not be demonstrably further from the truth). Surely we need to expect better from one of the Dart's authors than forgetting to mention all the caveats virtual threading via stackful coroutines comes with? And this completely ignores that Go applications end up having to reimplement .NET's task system system anyway and that Goroutines are poorly suited for "fine-grained" concurrency. Even the UX of Goroutines is bad. Want to return a value when one exits? Be sure to not screw up synchronizing and passing the data by hand. One must imagine Gophers writing all that boilerplate happy. I suppose, it's a preferred pastime to learning the internals and ceasing to post the same tired shibboleths.
      - rednafi 2y ago
        [flagged]
        neonsunset 2y ago
        [flagged]
        patates 2y ago
        The context problem is really annoying when using go. Many functions unnecessarily adding a context parameter so they can cancel a task. They made such nice syntax sugar for channels, why not also context?
        yndoendo 2y ago
        Never used F#. Looked it up for thread cancellation and it is syntactic sugar similar to defer in Go. Kind of like an await return is a wrapper around f(x) callback. Been years since I wrote Go code, until last week. Daily has become C#, python, and powershell. Took a day to fall back in and write a tool while learning a new GUI framework. Found the strengths and weaknesses of the GUI. Personal, I find Go more pleasurable to work with than python and C#. Reality, the project requirements dictate the languages that maybe used. This is the reason why Go was chosen over the others listed and unlisted C, C++, Swift, rust, ... Which would be a better experience with developing for iOS, Swift or C# or Go? If it was company's main solution or product, Swift, even when I will need to learn it. >Take a transport, like an HTTP client, send two/three/n requests concurrently That is business logic. Back end maybe embedded and this could become a DOS attack. .NET implemented the code to manage task pools so you don't have to. N aysnc is really a set of Z handlers. With syntax sugar. >Context propagation issues are known Doesn't a context need to exist for two entities to communicate and no system can exist where context is not shared? This is the adapter pattern in GoF, which in can be reduced to function g controlling the interactions between function a and b, where function a or b may act upon the agreed upon return type, callback type, or memory type. Address of the return, callback, and memory must be shared either with-in g() or a() and b() .. from CPU register up to system memory address. >And why would anyone need to bother with explicit synchronization anway? Dependent on business logic. Including which 3rd party libraries must be used for the solution. Software might be architecture for using Reactive objects which mimic async / await with more well defined and shared behavior. A custom managed thread maybe needed for more accurate time limits or an event loop is needed. >sleek one-liner. Be warned, one liners may seem useful, until they need to be debugged. There is a great difference between the two C# Reactive objects: { doing.Where(x => x.CanDo()).Subscribe(x => x.ExtensionDigestion()); doing.Where(x => { #if DEBUG // Set ID_WITH_ISSUES_OR_TESTING to the proper ID when developing new user experience or interface. Use for debugging single issue bug that just happens with the same ID or same line of 3rd party product tie-ins. if (x.Id == ID_WITH_ISSUES_OR_TESTING) { var i = DateTime.UtcNow(); } #endif return x.CanDo() } .Subscribe(x => { x.ExtensionDigestion(); }); }
coder543 2y ago
tl;dr Async/await is what the Python community has settled on, so I don’t think there’s any point in resisting it now, but the fact that it happened is a historical curiosity from my point of view. ----- I’m not the person you replied to, and I actually don’t have anything against async/await as a pattern where it is needed, but I know that prior to Python getting async/await, there were some moderately popular green threading / coroutine libraries like gevent and eventlet. You would (mostly) just write normal, synchronous Python, and then blocking calls would be intercepted by the runtime and allow other coroutines to take their turn. This felt Pythonic to me at the time, because most code would work in both sync and async environments. You didn’t have to write a separate async version, and you didn’t really have to update old libraries. The other pre-async/await approach was taken by Tornado and Twisted... basically a form of callback hell. I don't think anyone liked this, but it might have been popular because it worked... and unofficial green threading implementations like gevent/eventlet sometimes broke in interesting ways. (I think officially incorporating a gevent/eventlet-style solution into Python would have overcome most of the issues... but, that's just my speculation.) I’ve never used Python professionally outside of some short scripts, but it was one of the first languages I used seriously for hobby stuff back during the early days of the Python 3 transition. I never fully understood why Python chose to switch to async/await. Promises can be useful for structured concurrency patterns, but as someone who has been writing Go professionally for a number of years… I just don’t think most code should need to be async-aware. For a language like Rust, I think async/await makes perfect sense. Rust cannot afford to impose a runtime on everyone, and async/await can be implemented in a very low level, efficient way that gives the developer as much control as they need. This kind of ultra-low-level optimization stuff just isn’t relevant to Python… so, as an outsider, I almost wonder how (in Python) async/await isn’t just a clunkier coroutine system. If I were to try to rebut my own comment, I would say that async/await was probably chosen because "explicit is better than implicit", and green threading might have been too implicit for the Python community's tastes.
- rednafi 2y ago
  There are a few truths in this. I’ve been involved in a few large projects written in Python and have seen both ups and downs. Green threads required extensive monkey patching, and debugging those programs was incredibly hard. Instagram moved from them to async/await and wrote a blog post about it, iirc. But I agree that Python’s async/await implementation is a bit too low-level and could use better abstractions. A lot of the hate Python async gets is due to the `asyncio` library. It’s a shame that the default library is full of deprecated and gotcha-ridden APIs. Trio attempted to fix these, but adoption has been low. The community settled on async for the same reason I love Go despite all its faults. It’s flawed, but you can build successful systems with it. Lots of companies still write new services in async Python instead of Go because, as big as the Go community is, Python’s is absolutely ginormous. Plus, LLMs brought more new people to Python than most other languages, and it’s easier to find Python developers and teach them async than to hire Gophers.
rollcat 2y ago
Here's a good one: https://journal.stuffwithstuff.com/2015/02/01/what-color-is-your-function/ https://journal.stuffwithstuff.com/2015/02/01/what-color-is-... The problem is futures (async/await) as a concept; JavaScript, Rust, etc all have the same problems. Take CSP by contrast: https://en.wikipedia.org/wiki/Communicating_sequential_processes https://en.wikipedia.org/wiki/Communicating_sequential_proce... Any Go function can take a channel, return a channel, or use a channel (and spawn goroutines) internally, unbeknownst to the caller/callee. It may lead to some bad design decisions (code that must not be async may never be), but it won't get in your way when you least need a refactor.
CyberDildonics 2y ago
If you're having problems with async in languages it isn't your fault. Spinning off a thread for a single small purpose and trying to synchronize with the result seems fine in theory, but it is a very small piece of the larger puzzle of concurrency and usually gets people into trouble once they realize they need more, because anything more complicated than that one use case becomes very tricky.

rednafi 2y ago

[flagged]

neonsunset 2y ago
[flagged]
- rednafi 2y ago
  [flagged]
  - neonsunset 2y ago
    > Bob Nystrom worked on Dart at Google and wrote the amazing Crafting Interpreters book. Rob Pike referenced this article in his 2023 talk, Go: What We Got Right, What We Got Wrong, while discussing the trade-offs between CSP and coroutine-driven concurrency. I know, which is the exact reason the reply states "uncharacteristically". And yet, it fails to acknowledge existing terminology and tradeoffs and just states at the end in a couple paragraphs how Goroutines shall deliver us all from evil (which could not be demonstrably further from the truth). Surely we need to expect better from one of the Dart's authors than forgetting to mention all the caveats virtual threading via stackful coroutines comes with? And this completely ignores that Go applications end up having to reimplement .NET's task system system anyway and that Goroutines are poorly suited for "fine-grained" concurrency. Even the UX of Goroutines is bad. Want to return a value when one exits? Be sure to not screw up synchronizing and passing the data by hand. One must imagine Gophers writing all that boilerplate happy. I suppose, it's a preferred pastime to learning the internals and ceasing to post the same tired shibboleths.
    - rednafi 2y ago
      [flagged]
      - neonsunset 2y ago
        [flagged]
        patates 2y ago
        The context problem is really annoying when using go. Many functions unnecessarily adding a context parameter so they can cancel a task. They made such nice syntax sugar for channels, why not also context?
        yndoendo 2y ago
        Never used F#. Looked it up for thread cancellation and it is syntactic sugar similar to defer in Go. Kind of like an await return is a wrapper around f(x) callback. Been years since I wrote Go code, until last week. Daily has become C#, python, and powershell. Took a day to fall back in and write a tool while learning a new GUI framework. Found the strengths and weaknesses of the GUI. Personal, I find Go more pleasurable to work with than python and C#. Reality, the project requirements dictate the languages that maybe used. This is the reason why Go was chosen over the others listed and unlisted C, C++, Swift, rust, ... Which would be a better experience with developing for iOS, Swift or C# or Go? If it was company's main solution or product, Swift, even when I will need to learn it. >Take a transport, like an HTTP client, send two/three/n requests concurrently That is business logic. Back end maybe embedded and this could become a DOS attack. .NET implemented the code to manage task pools so you don't have to. N aysnc is really a set of Z handlers. With syntax sugar. >Context propagation issues are known Doesn't a context need to exist for two entities to communicate and no system can exist where context is not shared? This is the adapter pattern in GoF, which in can be reduced to function g controlling the interactions between function a and b, where function a or b may act upon the agreed upon return type, callback type, or memory type. Address of the return, callback, and memory must be shared either with-in g() or a() and b() .. from CPU register up to system memory address. >And why would anyone need to bother with explicit synchronization anway? Dependent on business logic. Including which 3rd party libraries must be used for the solution. Software might be architecture for using Reactive objects which mimic async / await with more well defined and shared behavior. A custom managed thread maybe needed for more accurate time limits or an event loop is needed. >sleek one-liner. Be warned, one liners may seem useful, until they need to be debugged. There is a great difference between the two C# Reactive objects: { doing.Where(x => x.CanDo()).Subscribe(x => x.ExtensionDigestion()); doing.Where(x => { #if DEBUG // Set ID_WITH_ISSUES_OR_TESTING to the proper ID when developing new user experience or interface. Use for debugging single issue bug that just happens with the same ID or same line of 3rd party product tie-ins. if (x.Id == ID_WITH_ISSUES_OR_TESTING) { var i = DateTime.UtcNow(); } #endif return x.CanDo() } .Subscribe(x => { x.ExtensionDigestion(); }); }

coder543 2y ago

tl;dr Async/await is what the Python community has settled on, so I don’t think there’s any point in resisting it now, but the fact that it happened is a historical curiosity from my point of view. ----- I’m not the person you replied to, and I actually don’t have anything against async/await as a pattern where it is needed, but I know that prior to Python getting async/await, there were some moderately popular green threading / coroutine libraries like gevent and eventlet. You would (mostly) just write normal, synchronous Python, and then blocking calls would be intercepted by the runtime and allow other coroutines to take their turn. This felt Pythonic to me at the time, because most code would work in both sync and async environments. You didn’t have to write a separate async version, and you didn’t really have to update old libraries. The other pre-async/await approach was taken by Tornado and Twisted... basically a form of callback hell. I don't think anyone liked this, but it might have been popular because it worked... and unofficial green threading implementations like gevent/eventlet sometimes broke in interesting ways. (I think officially incorporating a gevent/eventlet-style solution into Python would have overcome most of the issues... but, that's just my speculation.) I’ve never used Python professionally outside of some short scripts, but it was one of the first languages I used seriously for hobby stuff back during the early days of the Python 3 transition. I never fully understood why Python chose to switch to async/await. Promises can be useful for structured concurrency patterns, but as someone who has been writing Go professionally for a number of years… I just don’t think most code should need to be async-aware. For a language like Rust, I think async/await makes perfect sense. Rust cannot afford to impose a runtime on everyone, and async/await can be implemented in a very low level, efficient way that gives the developer as much control as they need. This kind of ultra-low-level optimization stuff just isn’t relevant to Python… so, as an outsider, I almost wonder how (in Python) async/await isn’t just a clunkier coroutine system. If I were to try to rebut my own comment, I would say that async/await was probably chosen because "explicit is better than implicit", and green threading might have been too implicit for the Python community's tastes.

rednafi 2y ago
There are a few truths in this. I’ve been involved in a few large projects written in Python and have seen both ups and downs. Green threads required extensive monkey patching, and debugging those programs was incredibly hard. Instagram moved from them to async/await and wrote a blog post about it, iirc. But I agree that Python’s async/await implementation is a bit too low-level and could use better abstractions. A lot of the hate Python async gets is due to the `asyncio` library. It’s a shame that the default library is full of deprecated and gotcha-ridden APIs. Trio attempted to fix these, but adoption has been low. The community settled on async for the same reason I love Go despite all its faults. It’s flawed, but you can build successful systems with it. Lots of companies still write new services in async Python instead of Go because, as big as the Go community is, Python’s is absolutely ginormous. Plus, LLMs brought more new people to Python than most other languages, and it’s easier to find Python developers and teach them async than to hire Gophers.

rollcat 2y ago

Here's a good one: https://journal.stuffwithstuff.com/2015/02/01/what-color-is-your-function/ https://journal.stuffwithstuff.com/2015/02/01/what-color-is-... The problem is futures (async/await) as a concept; JavaScript, Rust, etc all have the same problems. Take CSP by contrast: https://en.wikipedia.org/wiki/Communicating_sequential_processes https://en.wikipedia.org/wiki/Communicating_sequential_proce... Any Go function can take a channel, return a channel, or use a channel (and spawn goroutines) internally, unbeknownst to the caller/callee. It may lead to some bad design decisions (code that must not be async may never be), but it won't get in your way when you least need a refactor.

CyberDildonics 2y ago

If you're having problems with async in languages it isn't your fault. Spinning off a thread for a single small purpose and trying to synchronize with the result seems fine in theory, but it is a very small piece of the larger puzzle of concurrency and usually gets people into trouble once they realize they need more, because anything more complicated than that one use case becomes very tricky.