PhD in Computer Science with 15+ years experience bridging the gap between the worlds of compilers/interpreters and scientific & business workflow orchestration systems. The world deserves better languages and developer tooling and it's my mission to continue exploring what's possible.
I've always been of the view that for a workflow language, you should use a proper, turing-complete functional language which gives you all the usual flexiblity for transformations on intermediate data, while also supporting things like automatic parallelisation of things like external, compute-intensive tasks.
I think they'd make an excellent content for a loading screen on a game. Pick one at random and give the player something to think about while they're waiting. If this happens enough times, you'll get some repeats, which will help reinforce the message or at least re-trigger the thinking process.
If all you're ever going to do with the result of an async function is await it immediately after calling, then you don't need async functions because you're just doing synchronous programming with extra syntax.
The reason there's a difference between foo() and await foo() is that the former gives you a future (aka Promise in JavaScript), while the latter gives you the result. You can then wait on multiple futures, so that things can happen concurrently.
If you add type annotations to your code and use mypy (which you definitely should), it'll pick up the distinction between the two types - Awaitable[str] vs str - and give you an error if you try to pass the future object to a function that expects a string.
The only case where I've run into problems is where I've called an async function that returns None, but have forgotten to await the result. In that case the function never actually begins execution.
Email: [email protected] or [email protected]
Twitter: 0xpmkelly
https://www.pmkelly.net
http://blog.uxproductivity.com/
PGP key: http://www.pmkelly.net/pgp-key
Fingerprint: 5435 6718 59F0 DD1F BFA0 5E46 2523 BAA1 44AE 2966