What Color Is Your Function? (2015)

Prior to ES6 JavaScript did not have async functions, just normal functions. Async functions came from the runtime, not JavaScript the language. For example there is no setTimeout function in JavaScript, it has to be implemented by the framework that runs the JavaScript. Talking about an function being async makes it confusing though. It's better to think of them as events. You call a function that executes a job, and specify a function to be called (an event handler) when the job has been completed. Putting the callback function in the function arguments is just a convention, other conventions are foo.on("ready") = handlerFunction; foo.ready = handlerFunction; foo.error = errorHandler; bar(handlerFunction); biz(successHandler, errorHandler); The callback convention is less verbose and probably why it's the most popular. Using just functions makes you more powerful...

I have similar sentiment when I'm reviewing modern java code that's riddled with Futures.

Async stuff in Python can be encoded in multiple ways, with gevent everything is a regular function.

http://sdiehl.github.io/gevent-tutorial/

EXACTLY!

But... don't bother too much trying to explain this to ppl who don't intuitively grok it right away... some just seem to never get it no matter how hard you try and explain it to them, it's like their brains are "wired differently" when it comes to reading and understanding code, they don't get the advantage and meaning of unification / universality / "one solution for many problems" etc.

Go is NOT my favorite programming language, but there's a stroke of simple genius in it that probably only got materialized bc its creators were left alone to work on it their way inside Google and just implemented their solution to things without being bothered by "language experts"...

EDIT+: not saying "colorless + channels" is always better or anything like that, all's tradeoffs... probably async/await code is much more readable than channels hell for many/most cases (but because it's less powerful - no true parallelism possible).

> A function has a single exit entry point and a single exit point and no state. If you call a function, you run its body.

> A coroutine has several entry points and exit points, and an internal state. If you call a coroutine, you make an instanciation (the body doesn't run).

Sort of, in some languages, but it doesn't have to work that way.

First, let's note that "blues" do have state, and they put it on the stack. So blues can only be entered once and store state on the stack. Reds store state in an object, and they can yield out of the middle and be reentered.

Then let's note that our top-level code has to be "red", or it would be impossible to ever run "red" code.

Now let's go on a journey.

1. Make it so calling a red from a red will start running the body right away, by default.

2. When calling a red from a red and running the body, we're already inside a coroutine instance. Instead of making a new one, keep using the same one. Grow it and store the new state at the end.

3. When calling a blue, if we're inside a coroutine instance, put the blue's stack inside it. And since our top-level code is red, the we always are inside a coroutine instance.

4. Since all our stack frames are safely stored inside coroutine instances, it's safe to call from a blue into a red! The entire stack can be saved for later, blue and red alike.

5. At this point the only difference between blue and red is that a blue function cannot yield, it can only have something deeper on the stack yield. For fun, you could make 'yield' into a runtime-provided function. Now functions written in the language are all the same. There is no difference between blue and red.

-

So there is still a distinction between "coroutines" and "functions". But in this setup, a coroutine is merely a container that you run functions inside of. There is only one kind of code you run, and it is a function.

Some language work this way. I wish javascript worked this way.