I think asyncIO might have changed my life today. I think this is a turning point. Invest in your skills.

AsyncIO is beautiful stuff indeed but not many seems to gasp it. Run to_thread or run_in_executor everywhere. I managed to make classic sockets as fast as the asyncio sockets using that. Would've not expact that. But things that regularly need to_thread / run_in_executor are maybe beter of in seperate process.. This is all asyncio single process: https://molodetz.nl/dashboard.

Not happy with aiosqlite tho. Maybe it's better not to use that at all.

Coroutines are great indeed ;P

I'm glad it's kinda the default in js now with async

Funny how python, the main language for big data stuff and AI, doesn’t even have decent first class concurrency.

@Lensflare It's glue, It should have the simplest options for everything. The only argument I can see in favour of concurrency is that C# has blocking and green threads rather than async, and if you don't care at all about efficiency, this saves you from function coloring.

@lorentz welp, I agree. But nowadays scripting languages like Python and JS aren’t used as glue anymore and that’s the problem.
They are advertised as full ass programming languages but lack the features and properties of full ass programming languages.

@Lensflare JS isn't really glue though, before WASM it was impossible to call out to other languages from it, and even with WASM the targets must be designed with the limitations of WASM in mind. I call Python glue because it's usually used to call out to C libraries that weren't written with Python in mind at all.

@Lensflare I guess there's node-gyp but it's so terrible to work with from the C angle that I'm convinced the intended extension mechanism is just to write all the libraries directly in JS on top of Node's networking and disk IO.

@lorentz js is glue but the other way around. You can call js from almost all languages. There are even libs for languages like C# which have a js api.

@Lensflare It used to even be built into java

@Lensflare I keep repeating, programming languages are for people, not for the machine. That makes python and js the better languages. And it's not true that it hasn't true concurrency, with run in executor I explain above here, you can run as blocking as you want in seperate threads nu giving it a thread pool executor or process pool executor. Sounds you're a bit behind. You're spreading fake news.

@Lensflare funny, how people live in the 90's.

@whimsical compiled machine code is for the machine. Programming languages are for people.

I’m not claiming that Python doesn’t have concurrency. I’m saying it doesn’t have proper first class concurrency. If it did, something like asyncio wouldn’t exist.

Java has thread support as well but it was horribly inconvenient because it used callbacks and callbacks needed anonymous type instances because it didn’t have lambdas (not sure if it has now).
This is a good example of how multithreading support doesn’t mean first class concurrency.

@Lensflare that real time concurrency, I've tested with python 3.14 without GIL. And realised, what to do with it anyway. It's not that you're about to encode videos or whatever. But fact is, it does really run concurrent, als with the GIL version. Does not block. I can run an input() (for stdin read) no problem.

@whimsical I know that it doesn’t block, otherwise it would be useless.

And what I’m talking about has nothing to do with realtime.

I’m talking about at least language features like async/await and structured concurrency.