Comparing to Haskell, I think of "async" as the IO monad. It's nice to have all code that does IO flagged explicitly as such.

> I think the async-concept gets overused (at my workplace at least).

Problem is it that it self reinforces and before you look every little function is suddenly async.

The irony is that it is used where you want to write in a synchronous style...

Wouldn't the old school style be more like rust async? Simple structs that you poll whenever you need to explicitly. No magic code that looks synchronous but isn't.

I always find it strange how people complain about features when the real problem is that they simply don't like how people use the feature.

Async in C# is awesome, and there's nothing stopping you from writing sync code where appropriate or using threads if you want proper multi threading. Async is primarily used to avoid blocking for non-cpu-bound work, like waiting for API/db/filesystem etc. If you use it everywhere then it's used everywhere, if you don't then it isn't. For a lot of apps it makes sense to use it a lot, like in web apis that do lots of db calls and such. This incurs some overhead but it has the benefit of avoiding blocked threads so that no threads sit idle waiting for I/O.

You can imagine in a web API receiving a large number of requests per second there's a lot of this waiting going on and if threads were idle waiting for responses you wouldn't be able to handle nearly as much throughout.

To be fair, it depends on the version of Go.

Used to be well-hidden cooperative, these days it's preemptive.

Having to put "await" everywhere is very explicit. I'd even say it's equally explicit to a bunch of awkward closures. Why do you say it's less?

> Green threads are a step further than the async keyword because they have none of the function coloring stuff.

I would say that green threads still have "function coloring stuff", we just decided that every function will be async-colored.

Now, what happens if you try to cross an FFI-border and try to call a function that knows nothing about your green-thread runtime is an entirely different story...

This is exactly what I mean.

Thank you for explaining much more clearly than I could.

> none of the function coloring stuff

And it’s this part that I don’t like (and see colleagues struggling to implement correctly at work).

Umm, acktually... (the default server is non-threaded and sequential. It was an example.)

In my less charitable moments, I've wondered if the real reason Python has async/await is because people coming to it from JavaScript couldn't be arsed to learn a more appropriate paradigm.

Hey Yoric, I do not want to underplay what it is like to work with async, but I think there has been a lot of improvements to make it easier, especially in JavaScript/ECMAScript. It is nice not to have to work directly with promises in the same way that was required previously. The language has matured a lot since I started using in Netscape Navigator (I see you formerly worked at Mozilla). I think coding can be complicated in general, although it shouldn't have to be. I think having a mental model for async from the start can be helpful, and understanding the difference between blocking and non blocking code. A lot of people learned writing synchronous code first, so I think it can be hard to develop the mental model and intuit it.

Maybe, but I wouldn't go back to Python 2 without async. It has also improved over time in Python. I have also had success using async in Python. I do understand what the article talks about however. Understanding the difference between blocking and non-blocking code is also a concept relevant to Python. In Node it's one of the concepts you are first introduced to, because Node is single threaded by default. I also understand in Go and other languages there are different options.

https://nodejs.org/en/learn/asynchronous-work/overview-of-bl...

I will agree with what some is said a above, BEAM is pretty great. I have been using it recently through Elixir.