4 ms·

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 c

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.

endorphine 5y ago
> 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?
sly010 5y ago
> 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.

endorphine 5y ago

> 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?

sly010 5y ago

> 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.