[viktorcode]

If I understand correctly, Go language praised in the article still has red and blue functions, only now they the colours are handled implicitly, and you as a programmer reading the code will have harder time guessing which is which on the call site.

[Jtsummers]

There are no function colors in Go in the way being discussed. Every function can be spawned as a go routine, every function can spawn go routines.

[hutao]

Go (and other language with threads) implicitly run inside the "async IO monad." In the function color analogy, what this means is that all functions are red, and the "ordinary" function call corresponds to "await" in languages such as JavaScript or C#.

Async/await is one implementation of cooperative concurrency, where the programmer must explicitly annotate the points where a context switch may occur. However, one can imagine a program transformation that marks every function as async, and makes every function call an await. After making that transformation, the async/await annotations would no longer be necessary. The end result is pre-emptive concurrency, where the runtime may potentially interrupt the active thread at any function call.

To make another analogy, Haskell requires all IO actions to run in the explicit IO monad, while most languages (C, Java, JavaScript, etc.) do not distinguish between "pure" and "impure" functions. Therefore, C, Java, and JavaScript could all be said to implicitly run in the IO monad.

Async IO is also an instance of a monad. In JavaScript, all async functions must run inside the explicit async IO monad, while Go does not distinguish between async and sync functions. Therefore, Go implicitly runs in the async IO monad. This is similar to the aforementioned distinction between cooperative (made explicit to the programmer) and pre-emptive (handled implicitly by the runtime) concurrency.

In fact, Eugenio Moggi, the PL theorist who realized monads could describe programming languages, was not looking for a programmer-facing abstraction. Rather, he was trying to describe the "implicit" monad in a programming language's semantics (such as the IO monad in most programming languages, or the async IO monad in Go).

[Jtsummers]

>> Go language praised in the article still has red and blue functions

This is my principle point of disagreement with the OP comment in this thread. Your response is either not meant for me, or is meant to agree with me, but I'm really not sure but you write:

> In the function color analogy, what this means is that all functions are red

and

> while Go does not distinguish between async and sync functions

Which was my point. Go does not have the function color problem (around sync/async) because it does not color its functions that way.

[hutao]

I was not looking to disagree with your point, I only wanted to make additional commentary. Sorry if my comment came across the wrong way.

I do think "There are no function colors in Go in the way being discussed," versus "all functions [in Go] are red" are two slightly different ways of formulating the same set of facts, and the distinction between them is insightful, so that was what I wanted to touch upon. Namely, I wanted to point out that there is an "implicit" color within the programming language itself.

[slopinthebag]

The functions are still coloured, just implicitly. IYKYK to spawn a goroutine or not ts.

[Jtsummers]

> The functions are still coloured, just implicitly. IYKYK to spawn a goroutine or not ts.

In Go, you can choose to either block on a function call or to execute it as a go routine. The function has no "color" in the sense of the article.

If you want to print asynchronously, you can with a `go fmt.Println("Hello")`, or you can block on that print and remove the `go `. There is no color to any function. And the function containing that, it also has no color. It can be called synchronously or spawned as a go routine, Go makes no distinction between the kinds of functions that can be used each way.

[slopinthebag]

Say you have a function like validate_user(). In Go, should you block the main thread on this call, or fork and join? What if it makes a DB request and now your UI is blocked for 2 seconds or something? You need to know implicitly you need to call validate_user() in a goroutine, and then deal with forking and joining manually. If it's explicitly coloured as async, you know.

In most async/await languages you can run async functions as sync, eg. Tokio's block_on method or C#'s .Result.

[amiga386]

I think you're missing something. Go's functions are all blue, not all red. As far as I know, the callers of async functions with Rust's Tokio and C#'s Tasks themselves need to be async; not the case for Go.

Concurrency is usually a mix of goroutines and channels. There is no inherent link between caller and asynchronous callee. You can use goroutines without channels, and channels without goroutines.

You can write "go" to launch any function call in its own goroutine, but you cannot get a return value from it. This isn't valid:

    user_is_valid := go validate_user(u)

The idiomatic way you can do that is to use a goroutine and a channel:

    ch := make(chan bool)
    go func() {                  // runs asynchronously
        ch <- validate_user(u)   // blocks until it can send
    }()
    user_is_valid := <-ch        // blocks until it can receive
    return user_is_valid         // ta-da, blue function returning red function result

I don't think it's a boon to have functions "coloured for you" to tell you that they might block. On the other hand, functions that would block tend to accept a Context parameter to let you control what they should do. It's a major indicator that the function's probably going to do something async, but it doesn't have to.

[slopinthebag]

Well, the benefit of async/await is that you can just do

   let user_is_valid = validate_user(u).await

But you can also pass around future values. It's pretty dang ergonomic, the tradeoff is that it requires more ceremony to block on async functions (and is not even possible in JS). This was considered a potential problem 10 years ago but we've discovered since than that it's not really an issue at all.

My point about the colouring is that it's actually nice to have explicit colouring, in go the asynchronicity of functions aren't encoded by the type system but in practice you still handle them differently. You can't just call one of them without passing in things like context, or handling channels without refactoring anyways.