Follow

Python has been my most used programming language since at least 2016 and it already had asyncio back then but with a different syntax.

However, I find myself not using asyncio even when faced with embarrassingly parallel problems, e.g. I downloaded 2400 JSON files this week sequentially.

I wonder if other programmers reach for intuitively.

Also, would a or programmer use goroutines/promises without thinking twice in the above situation? :blobthink:

@njoseph I use goroutines a lot with Go. They're very easy to use for simple tasks, when doing more complex they need a bit of work to avoid issues but it's actually rare for me to not use them in programs I write.

@njoseph concurrent.futures is enough for my use cases... I suppose asyncio has its space but it seems is quite restricted to some use cases.

@njoseph with go, yes. once i’ve already written the code to download sequentially and tested it, it takes 10-15 minutes to adapt it to use goroutines as a worker pool.

on the elixir side, there’s GenServer and GenStage. GenServer is very easy to set up, akin to doing it with goroutines in go. GenStage took a couple of tries the first time i used it, but i think i understand it now. it’s more generalized than simple goroutines or threads; using a GenServer would’ve been a lot easier to use, but it didn’t do all i needed for my project.

@njoseph I've been using python for sooo long but haven't tried any parallel programming. When I need more compute power I just run the program several times with different parameters and let my OS handle all the parallel stuff xD

@njoseph yes with both. Node has async I/O for pretty much everything so you don't have to think about it really, and go's stdlib is filled with parallelization libs.

@njoseph Pythonista since '03 here. I can't think of a single time I reached for asyncio instinctively.

I've been learning and practicing Go for the last 6 months or so and I think I am always using a go routine without even thinking about it. I think it's partially because the concurrent nature of Go is so baked in, both the language and teaching of it.

@njoseph I used to use Go a lot and yes, you get used to just reaching for Goroutines and Channels. But as a longtime Pythonista I also do not _want_ to use Python's async systems unless forced to.

Rust also offers great async primatives that rival Go's but oddly I have not used those in my projects yet either. Just the business of boilerplating an event handler is enough to put me off.

@njoseph I never reach out for async intuitively because that puts me immediately in a corner: async code can call sync functions, but the opposite is not true.

It's usually an afterthought. I'm now planning to rewrite my whole blog engine from scratch using asyncio, because with a few hundred posts the static site generation is starting to get slow.

@njoseph I never use asyncio instinctively, though concurrent.futures with ThreadPoolExecutor is nice for this kind of task. You can just submit a task to the executor in the form of a method + arguments. It can be used with a context manager so that the synchronization is quite easy: at the end of the with block, it will wait for all the tasks to complete. I find it very readable.

Sign in to participate in the conversation
Mastodon

The social network of the future: No ads, no corporate surveillance, ethical design, and decentralization! Own your data with Mastodon!