Hacker News Reader

Comment by korijn | Hacker News Reader

I have been using the async/await syntax in C# for more than ten years and never had a problem with it.

What is your point?

Most of Pythons standard library is sync, the minute you want to use a sync api from within async/await code it becomes a nightmare to manage.

If you are only using async library’s then async/await works perfectly.

It's straightforward to call sync functions from async ones. Are you referring to the fact that those sync functions could block and cause the async code to perform worse? I admit it's a few more lines of code to write a script that runs async code.

I've worked on several projects recently where async was used throughout and haven't had issues. There are many async libraries now, like ones to utilize GCP services, make HTTP calls, connect to Redis, etc.

Yes, I mean blocking sync calls from async code.

Sounds like you're referring to the "coloured functions" "problem", but it's the other way round. Calling a sync API from an async function is no different to calling it from a sync one. Calling an async function from a sync one requires that you make the caller async.

Personally, I like that. An asynchronous function is different to a synchronous one, and if you call an asynchronous function the caller is asynchronous. The "colouring" just reflects the realities of the problem domain. I'm not keen on libraries that monkeypatch the world to hide that fact, as gevent does.

However, some people prefer those libraries. Which is fine. They both exist, use what you like. There's no need to have wars about it.

> However, some people prefer those libraries. Which is fine. They both exist, use what you like. There's no need to have wars about it.

This results in ecosystem fragmentation though, which means that more effort is spent developing and maintaining different kind of solutions to the same problem, only because of their different developer experience.

On the contrary, look at Go, where it was decided from the beginning (i.e. stdlib) that we're going with coroutines.

It's a bit like (I'm exaggerating) arguing for what should be the default coding style, where a built-in/blessed formatter would make this a non-issue. gofmt is a nice example of this.

Also, honest question: AFAICT Python was more of the "there's 1 preferred way to do things". Doesn't arguing between async and coroutines goes against this mantra?

> Calling a sync API from an async function is no different to calling it from a sync one.

That's only true syntactically. If your sync function actually does any IO, it will block your async worker thread. Said differently it just synchronized your async code.

> the minute you want to use a sync api from within async/await code it becomes a nightmare to manage

What's wrong with sending the sync code to a thread pool? My CPU-, disk- and database-intensive application is filled with calls like:

   result = await asyncio.to_thread(long_function())

...and its resource usage and performance are great.

His point seems to be that mixing async and sync code in Python is a nightmare. I'm not sure how the fact that you do not observe the same issue in C# (a totally different language and runtime) is relevant?

And one if the very relevant differences is that C# is task-based while Python is coroutine-based.

And because C# is statically typed, it can reliably warn on missing awaits (a common issue in the also-task-based javascript, though less problematic than it is in Python).

I'm calling parent out on their weak argument by copying it. Quote:

> I have been using Gunicorn with Gevent for nearly 10 years and never had a problem with it.

Reply on news.ycombinator.com