Yes, if I'm writing a web server I want everything to be async. But, just as I want to share JS on the server and the client I also want to use JS as my build language. At least for me, I find it much faster to build using a sync style.
Maybe I just haven't learned the async way but for example I tried to make a build system using node. I needed to spawn out to a builder to build some stuff, copy files, spawn git in various ways to see if repos are dirty or clean, git add, git commit, and a few other things. I found it a massive nightmare and after 2 days I switched to synchronous python for my building. Was done in 2 hours.
If there's some articles or tips that will make me as comfortable at async for building as I'm as sync in python then please point me at them. But, for whatever reason, I'm struggling with async for really complex tasks. (and yes, I'm using promises)
There is no inbuild async nature. It just did not have a stdlib whatsoever, so node could come along and offer a completely async one. There were async server frameworks in python before, like twisted and tornado.
For a long, long time, the language itself lacked almost all of the niceties that make async programming bearable. Node code quickly devolved into a giant mess of callbacks nested twenty levels deep.
Javascript's async story is far worse than Python's.
Yes and no. Python may have an great async core with Twisted and gevents, but it doesn't have an great async ecosystem. Most tools and libraries aren't written with async in mind and you end up having to roll your own in many places where Node either gives it to you out of the box or with well supported third-party libraries. After having written quite a bit of Twisted code I have to say I find writing async code in Node a lot quicker and easier, despite being a much more experienced python programmer.
Yeah, if you're going to have to do async to be performant than it better be pretty pervasive throughout all the libraries. Bonus points if the language supports syntax to make async easier as well. Node is beating out Python for server stuff not simply because it is "async", but because it is so much FASTER. The speed of V8 vs. CPython is a big part of that. In fact, vanilla JS doesn't have much to make async programming particularly easy: it has verbose function declaration and no yield mechanisms. Even library-level solutions like promises are merely 'OK'.
Still, it is easier to build a fast server that can handle streams in Node than it is in Python. Async Python? I'll just stick to async JS in that case.
Javascript's async feels a bit more natural than Python's.
In Python, you've also got to run the event loop and pass the async function to it. This makes playing with async code in the interpreter more difficult. Also don't forget that async is also turtles all the way up (same as in JS). It'll infect any synchronous code that touches it.
I've written a Tornado app which makes heavy use of asyncio, and while it's pretty efficient, I would reconsider writing it the same way if I had to go back in time.
I love Python async - it’s a complete game changer for certain types of applications.
I find Python async to be fun and exciting and interesting and powerful.
BUT it is a big power tool and there’s so much in it that it’s hard to work out how to drive it right.
I have pretty good experience with Python and javascript.
I prefer Python to javascript when writing async code.
Specific example I spent hours trying to drive some processes via stdin/stout/stderr with javascript and it kept failing for reasons I couldn’t determine.
Switched to Python async and it just worked.
The most frustrating thing about async Python is that it has been improving greatly. That means that it’s not obvious what “the right way” is, ie using the latest techniques. This is actually a really big problem for async Python. I’m fairly competent with it, but still have to spend ages working out if I’m doing it “the right way/the latest way”.
The Python project really owes it to its users to have a short cookbook that shows the easiest, most modern recommended way to do common tasks. Somehow this cookbook must give the reader instant 100% confidence that they are reading the very latest official recommendations and thinking on simple asyncio techniques.
Without such a “latest and greatest techniques of async Python cookbook” it’s too easy to get lost in years of refinement and improvement and lower and higher level techniques.
The Python project should address this, it’s a major ease of use problem.
Ironically, pythons years of async refinement mean there’s many many many ways to get the same things done, conflicting with pythons “one right way to do it” philosophy.
It can be solved with documentation that drives people to the simplest most modern approaches.
python's async mostly works as long as you're using async-native libraries. if you can await it, it's okay. it only gets disastrous when you have to start mangling callback code into promises.
although i really do love javascript's ability to await synchronous functions without it causing any errors. i'm sure it's less performant, but sometimes i just don't care.
Python absolutely has async/await/promises, and it's actually quite a lot worse than JavaScript in this regard because Python _also_ has synchronous APIs and _no_ tooling whatsoever to make sure you don't call a sync API in an async function thereby blocking your event loop (which, if your application is a networked service with any amount of traffic at all, will typically result in a cascading failure in production). I'm no great fan of JavaScript, and I've written _wayyyyy_ more Python than JS, but async/await/promises is exactly the wrong example to make the case that Python is better.
I've played with the concurrency in Python, and it's simply not worth it. Much better to use Node.js or Go where the async story is not an afterthought.
Of course if you are stuck with Python it's better than nothing.
simple reason - there is NO framework that is built ground up for nodejs style async programming.
Obviously there is Twisted and Tornado - but gevent or asyncio are actually the paradigms that people are using now. If there were a Flask like framework that was ground up built to leverage async (rather than bolting it on) and included all the batteries for web development.. then python would have a serious edge over node.
I think my experience in async in other languages has shown how rough async in Python is.
Unless async is the default python, it will always be an after thought and introduce needless complexity when working on large projects that require a lot of external libs.
It lets me do stuff that would be hard with ordinary Python.
No doubt it takes some effort and practice to grasp, but once you have it worked out you'll find it's a powerful tool in the toolbelt.
Many languages now have async and await - it's not exclusive to Python. The reason so many languages have gopne this way is that so far it's the easiest and most sensible solution to writing concurrent code in a way that won't become incomprehensible.
And if you are trying to get your head around it, the easiest analogy is the web browser and JavaScript. If you have grasped JavaScript and the event loop then essentially you have grasped async Python, or not far from it.
Some people misunderstand async Python - they think the point is to make Python faster - it isn't. The point is to enable concurrent programming.
I do understand the haters - at first, until you grasp it, async Python so incredibly foreign and so different from ordinary synchronous Python that you might think "AAAARGH why did they do this and make it so hard"? But really it's not hard once you grasp the mental model of what is going on.
I don't know what python's async support is like but the biggest issue with porting to the web is the browser mostly requires that you exit events before it will do anything. This is contrast to pretty much all other environments. That means there are tons of patterns and libraries that just don't work and require major re-writes or big AST manipulations like asyncify from emscripten.
I'm not saying you can't do async work in any language. Rather I'm saying that likely the patterns you're used to using in some language that's not JavaScript won't work in the browser and you'll have to massively change your style.
Yeah but node.js predates asyncio by about 5 years. Python was early to the game with asyncore and Twisted (circa early 2000's), but the async I/O support stagnated and left a big hole for node.js.
Part of the reason for stagnation was because you really need new language features -- i.e. yield/send, yield from, etc. JavaScript already had the necessary language features for its concurrency model.
Yes, if I'm writing a web server I want everything to be async. But, just as I want to share JS on the server and the client I also want to use JS as my build language. At least for me, I find it much faster to build using a sync style.
Maybe I just haven't learned the async way but for example I tried to make a build system using node. I needed to spawn out to a builder to build some stuff, copy files, spawn git in various ways to see if repos are dirty or clean, git add, git commit, and a few other things. I found it a massive nightmare and after 2 days I switched to synchronous python for my building. Was done in 2 hours.
If there's some articles or tips that will make me as comfortable at async for building as I'm as sync in python then please point me at them. But, for whatever reason, I'm struggling with async for really complex tasks. (and yes, I'm using promises)
reply