4 ms·

I've exclusively used async/await style languages for my entire life and have not once ran into this supposed problem of function colouring. Basically all IO/as

I've exclusively used async/await style languages for my entire life and have not once ran into this supposed problem of function colouring. Basically all IO/async work you do requires a context, does it matter if that context is a parameter or a keyword? I don't think so. The author is inventing a problem to rant about.

notnullorvoid 5mo ago
The one time I did run into coloring being an issue was when working with gevent/greenlets (green threads) in Python nearly a decade ago. Implicit management of async operations is something I hope I never have to deal with again.
triMichael 5mo ago
The author is definitely not inventing a problem. I ran into this issue at work this month. We were using WPF, which is C# combined with XAML. I needed to call some async code. First, I tried to call it from synchronous code. That compiled correctly and seemed okay, but then I got vague crashes, and after doing research, I found everyone was like "don't ever call an async function from a sync function" for that exact reason. So instead, I had to change whatever called that to be async, and then whatever called that to be async, and so on. The solution I ended up having to go with was literally changing the code in over a hundred places. This is legacy code that I touch as little as possible, and instead of the one line fix that it felt like it should have been, async turned it into over a hundred small changes throughout the entire project. I'm not saying there isn't a better approach. I'm pretty new to async/await code as I've been doing asynchronous code through threads my whole programming career. I don't think WPF is a good technology, so maybe some newer tech has solved it better. But what I can say is that this problem was not invented, it is a real problem and it caused a simple change to become a complicated one.

notnullorvoid 5mo ago

The one time I did run into coloring being an issue was when working with gevent/greenlets (green threads) in Python nearly a decade ago. Implicit management of async operations is something I hope I never have to deal with again.

triMichael 5mo ago

The author is definitely not inventing a problem. I ran into this issue at work this month. We were using WPF, which is C# combined with XAML. I needed to call some async code. First, I tried to call it from synchronous code. That compiled correctly and seemed okay, but then I got vague crashes, and after doing research, I found everyone was like "don't ever call an async function from a sync function" for that exact reason. So instead, I had to change whatever called that to be async, and then whatever called that to be async, and so on. The solution I ended up having to go with was literally changing the code in over a hundred places. This is legacy code that I touch as little as possible, and instead of the one line fix that it felt like it should have been, async turned it into over a hundred small changes throughout the entire project. I'm not saying there isn't a better approach. I'm pretty new to async/await code as I've been doing asynchronous code through threads my whole programming career. I don't think WPF is a good technology, so maybe some newer tech has solved it better. But what I can say is that this problem was not invented, it is a real problem and it caused a simple change to become a complicated one.