Hacker News Reader

I think there's something important and correct in this take.

As another example to your point, whether a function returns a list of foo's or a single foo is a also a color. You have to do completely different things when calling a function that returns a list compared to one that just returns a single value. And that's not just empty pedantry. Haskell let's you treat "list" as an effect (since it is a monad). Array languages like APL, J or R are colorblind with respect to "a list"/"not a list" as the difference is erased (to a large extend). So there really is a whole rainbow of function colors (basically types).

On the other hand, this point of view doesn't really invalidate the original coloring argument at all. The effect encapsulated by "async" really is one that can be annoying and one that can actually be made implicit with a result that many would prefer.

This is exactly why I like all of this being handled in the return type. Return a Promise<T> or a Task<T> or a Stream<T> or an IEnumerable<T> as appropriate. Every function always returns immediately, but it might not do the important work immediately -- instead, it plans out the important work, which you can plug together as you see fit with other work and execute if you want, or simply return a composite plan for someone else to execute. All of its various "colors" are explicit in the return type.

Combinatorial explosions are wrapped up in the Ts themselves. Sure, you might sometimes get a Stream<Array<Stream<T>>>, but if that's simply the appropriate type to describe what your function does, then who's complaining? As long as you have various ways to manipulate those types, like "Combine" (Array<Stream<T>> -> Stream<Array<T>>) and "Flatten" (Stream<Stream<T>> -> Stream<T>) then you can handle everything. And you'll find that getting your types correct increasingly implies that your entire code is correct, so the compiler is helping you out a lot.

> In Go or Rust, returning an error is also a “color” that spreads out to the top of the call stack.

Not unless you're doing it wrong. Errors need to be handled. That may, in some cases, mean handling it with another error, but that isn't adding any "color". The new error is independent of any previous error state.

You're misunderstanding: the fact that the new error is different from the original one doesn't change the fact that the function returns an error. Exactly like how async functions awaiting on a promise to create new promises doesn't change the fact that the function is an async one.

Sure sometimes you can avoid propagating the error upward, but that's not the most common case and it also happens with async/await (if you don't need the result of the promise in the caller function you don't need to await and to make it a async function).

In Rust the similarity is very flagrant because there are one postfix operators for both (? and .await).

> if you don't need the result of the promise in the caller function you don't need to await and to make it a async function

Why call it at all, then? In Rust, futures don't run unless you poll them, so just calling an async function without polling it doesn't do anything.

In contrast, for error returns it's very common to log an error but continue with some default value, or just skip processing one item and continue with the rest. There are a lot of cases where errors can be handled immediately, rather than always blindly bubbled up the call stack

> Why call it at all, then? In Rust, futures don't run unless you poll them, so just calling an async function without polling it doesn't do anything.

Rust is a bit special as the futures are lazy and you need to call your future with `task::spawn` if you want this to work, but it still does. And in other languages it's going to work directly without doing anything in addition to calling the async function.

> In contrast, for error returns it's very common to log an error but continue with some default value, or just skip processing one item and continue with the rest. There are a lot of cases where errors can be handled immediately, rather than always blindly bubbled up the call stackm

It really is use-case dependent but I don't think it's more common than letting the request run in the background without waiting for its result. In fact your log example is a funny one because as soon as you use remote logging you're going to let the request run in the background and never await it (otherwise you'd get tons of gratuitous latency).

You're misunderstanding. async/await creates a dependence. errors do not – at least no more than any other type. Would you say your perspective on "coloring" is equally applicable to email addresses?

I might buy into your idea the "?" operator colors functions. But that's something else entirely and obviously isn't what you were talking about originally as it isn't found in all of the languages originally mentioned.

> async/await creates a dependence. errors do not.

It does! In both case you need to "unwrap" the value, and in most case it means making the caller function async or returning the error. (As an anecdote I've done way more refactoring involving replacing T with Result<T> in entire call stacks in Rust that I've done it for async).

> I might buy into your idea the "?" operator colors functions. But that's something else entirely and obviously isn't what you were talking about originally as it isn't found in all of the languages originally mentioned

It's exactly the same with Java's checked exception and Go errors, as soon as you start calling a function that returns an error, you're going to write something that looks like

    if err != nil {
      return 0, err
    }

And tada! your functions now need to add the error to it's return parameter.

> It does! In both case you need to "unwrap" the value

Just as you do with any value, such as an email address, returned by a function. It is curious that you avoided my question as it would help us better understand where you are trying to come from. If that is the stance you are trying to take you're not exactly wrong about there still being some sort of dependence – there is an inherit dependency created when calling a function, always - but there is not a different color of dependence found within that. You're missing the intent of "coloring" if that is what you are trying to say.

async/await introduces a different type of dependence than a function would normally present, where the dependence is no longer direct. I may even agree that the "?" operator introduces a similar indirect dependence. But a function returning an email address (or error; the type of the value is immaterial) is the "natural color" of a function. If that is all you have, there isn't a secondary color.

> as soon as you start calling a function that returns an error, you're going to write something that looks like

Only for internet memes. You would never write production code like that for so many reasons.

> you do with any value, such as an email address, returned by a function. It is curious that you avoided my question as it would help us better understand where you are trying to come from

I don't understand what you mean with your email address example. If you ask a function for an email address, and you get an email address you don't have to unwrap anything.

> You're missing the intent of "coloring" if that is what you are trying to say.

I'm not, really. The key thing is that as long as you have some effect (like "an error occurred" or "the execution is suspended while running some IO operation", “this function is allocating”, “this function is impure”, etc.) happening somewhere in the call stack then it infects all the call stack no matter what the language does. (A previously pure function calling an impure one becomes impure, a non-allocating function calling an allocating one becomes allocating itself, etc.)

In some language, this effect is visible to the caller by default (but can generally be opted-out) and you have this kind of red/blue split for any effect. In other languages this effect is just hidden (but it still exists on reality), that means less effort annotating your code but also less information when reading other people's code. It's exactly the same tradeoff as typing.

> Only for internet memes

Not literally like that, but the gist of it still stands, you end up adding an error return value to your functions the vast majority of the time.

> I don't understand what you mean with your email address example.

But you didn't think to ask any followup questions to help with your understanding?

> The key thing is that as long as you have some effect [...] happening somewhere in the call stack then it infects all the call stack no matter what the language does.

In the same way email addresses do, I suppose. But that is the "natural color" of a function. Consider:

    fn getEmail() {
        return "joe@example.com"
    }

    fn getPerson() {
        email = getEmail()
        return "Joe Blow", email
    }

    fn getUser() {
        name, email = getPerson()
        return "joeblow123", name, email
    }

    fn main() {
        username, name, email = getUser()
        print(username, name, email)
    }

Yes, you could say in a sense `getEmail` "infected" `getUser` in its need to get the email address to the top of the stack, but the dependence at each step remains direct. getUser returns an email address because an email address is relevant to the result of `getUser`, not just because it happened to call `getEmail`.

That is different to async/await, where `main` now has to become aware of what `getEmail` is doing because `getUser` happened to call it transitively. The dependence is indirect.

    async fn getEmail() {
        return background { return "joe@example.com" }
    }

    async fn getPerson() {
        email = await getEmail()
        return "Joe Blow", email
    }

    async fn getUser() {
        name, email = await getPerson()
        return "joeblow123", name, email
    }

    async fn main() {
        username, name, email = await getUser()
        print(username, name, email)
    }

I may be inclined to agree that the "?" operator can introduce a similar indirect dependence:

    fn producesError() {
        return ProductionError("an error occurred")
    }

    fn doesSomething() {
        value = producesError()?
        return true   
    }

    fn main() {
        result = doesSomething()
        match result {
            ProductionError:
                print("Error", result)
            OK:
                print("OK", ok)
        }
    }

Like async/await, `main` now has to be aware of what `producesError` is doing without calling it directly. But, then again, much like as we discussed in your Go example, you'd never actually write production code like that. There are so many things wrong with it. So, I'm not sure how significant that coloring actually is. And, regardless, is not related to the original discussion.

Your email address example is backwards: you can indeed get function coloring with just regular functions but its not the return value that causes it, but the input parameters. Consider this:

    function foo(name){
        console.log(`Hello ${name}`);
    }

    function bar(name){
      foo(name)
    }

    function top(user){
      bar(user.name)
    }

If the `foo` function at the bottom of the stack needs some additional input (say the email address), then you'll need to pass it down and modify the signature of every function above:

    function foo(name, email){
        sendMail("Hello ${name}", email);
    }

    function bar(name, email){
      foo(email)
    }

    function top(user){
      bar(user.name, user.email)
    }

As you can see, "My function needs some particular data" is also an effect that will transitively contaminate the call stack above (in "indirect" manner to reuse your wording).

In fact this is already apparent in the original blog post since the first two third are about callback-based concurrency, in which the coloring comes as a function parameter.

> But, then again, much like as we discussed in your Go example, you'd never actually write production code like that. There are so many things wrong with it.

No matter how you end up writing your code, there is only two alternative: you either address the problem and then you don't have to propagate the error (this is the minority case by a large margin) or you need to propagate it upwards (which happen at least 90% of the time).

> So, I'm not sure how significant that coloring actually is. And, regardless, is not related to the original discussion.

It is exactly as significant as async coloring. That doesn't mean the problem it causes is big though, the "async coloring problem" is vastly overblown and everybody deals with strictly equivalent "effect problems" all the time without even thinking about it, which was my original argument at the very top of this thread.

By the way:

> But you didn't think to ask any followup questions to help with your understanding?

When you use this kind of passive-agressive tone, don't be surprised if a charitable reader simply discards it, the less charitable thing to do instead would be escalating in aggressiveness.

> Your email address example is backwards: you can indeed get function coloring with just regular functions but its not the return value that causes it, but the input parameters.

Uh, what? Convention in Go and Rust sees errors be returned. Earlier, when you defined the topic of conversation, which hasn't changed, you even said "In Go or Rust, returning an error is also a “color” that spreads out to the top of the call stack.", so you seemingly knew this at one time. Where did you get the idea that they are taken as input parameters now?

> or you need to propagate it upwards

Perhaps like you need to propagate email addresses. But that's the "normal color" of a function. If that is all you are doing, there is no secondary color. That's just "normal" use of a function.

async/await, and perhaps even "?", are not "normal" as they introduce to the caller dependencies on functions the caller didn't even call. This breaks the "black box" nature of a function, seeing implementation details leak, thereby no longer guaranteeing that a function is "black" and thus establishing functions that are of other "colors".

> When you use this kind of passive-agressive tone, don't be surprised if a charitable reader simply discards it

Oh, I wasn't surprised. It was clear from your first comment that your emotions aren't letting you think straight.

> Uh, what? Convention in Go and Rust sees errors be returned

Yes, but that's irrelevant. "Regular" return values don't have this coloring effect, but input have. It's a covariant / contravariant kind of thing. You should really re-read my previous comment if it went over your head.

> Perhaps like you need to propagate email addresses

No, again you get this backwards, you don't need to propagate the email address, errors suppose a specific kind of control flow that is different than non-error values. Again the correct analogy is the input type, not the return type. Understanding this is a prerequisite of understanding the whole concept so you should really take some time thinking about it.

> Oh, I wasn't surprised. It was clear from your first comment that your emotions aren't letting you think straight.

You're projecting your own mindset on me, I've been neither emotional nor aggressive in this entire thread, despite repeated attempt on your side to heat things up.

> Yes, but that's irrelevant. "Regular" return values don't have this coloring effect

It is certainly not irrelevant as that is the very topic of conversation. The topic of conversation was clearly and specifically defined by "In Go or Rust, returning an error is also a “color” that spreads out to the top of the call stack." But you're right to finally come around to realizing that there is no coloring effect created by that. Glad you were able to learn something today!

> errors suppose a specific kind of control flow that is different than non-error values

They might want a different kind of control flow in some circumstances, but it is not supposed. Email addresses might also want a different control flow in some circumstances (e.g. a "local" address).

> Again the correct analogy is the input type

It is quite possible to introduce an indirect dependence through inputs as much as it is possible through outputs, if that is what you are trying to say. I'm not sure your example successfully demonstrates that, though. There is nothing to suggest that email isn't relevant to `bar`, even if the actual "black box" implementation happens to call upon `foo`. I see no evidence of implementation details leaking, which can be demonstrated by removing `foo` and refactoring `bar` to:

    function bar(name, email){
      sendMail("Hello ${name}", email);
    }

> You're projecting your own mindset on me

No, but I read what you wrote. Perhaps I have misinterpreted it? What did you mean by "tone" if not something that pertains to your emotions?

> despite repeated attempt on your side to heat things up.

Admittedly, in context, this too reads like you are referring to your emotions. But as you also seem to be trying to assert that they are not weighing on you, what are you actually trying to say here? You have not made yourself clear, I'm afraid.

> The topic of conversation was clearly and specifically defined by "In Go or Rust, returning an error is also a “color” that spreads out to the top of the call stack."

Returning an error has this property, yes. And errors Alps have this property when they are propagated separately from the return value (like unchecked exception in Java). Returned values do not have this property.

> . Glad you were able to learn something today!

I've tried with much patience and good faith in spite of your aggressiveness to explain this things in ways you can understand them so you could actually be learning something, but it looks like your ego is too fragile for that.

That's really unfortunate for you as it's the recipe for perpetual mediocrity. Good day.

> Returning an error has this property, yes.

Only in the same way that returning an email address does. That does not change the color, though. It remains "black". This is just "normal" use of a function.

Yes, you can go out of your way to leak implementation details making the function no longer "black". async/await, use of the "?" operator, "return err", even checked exceptions all introduce leakage. That can result in a colorful rainbow of functions, but "unless you are doing it wrong" was caveated at the very beginning. The very first sentence I wrote, in fact.

Is that the source of your confusion, perhaps? That you somehow forgot to read the very first sentence? async/await is the only one that isn't yet generally considered a bad practice, and only because it is quite a bit newer than all the others, as we always learn in the end that leaking implementation details leads to pain.

> I've tried with much patience and good faith in spite of your aggressiveness

I really don't understand what you are trying to say here. Aggressiveness? Patience? Good faith? These have no applicability to the conversation, so I am, again, not sure what you are trying to say. Further, these are words that are usually used around emotion, which we both seemingly agreed does not shape our reading of the discussion, so I have no idea what else they could be referring to. What do you mean?

> In Go or Rust, returning an error is also a “color” that spreads out to the top of the call stack.

That's wrong... Suppose A calls B and B returns a Result<T> (so it's colored as you say). A can match both the Some() and the Err() variants of B and return something other than the error in the latter case. So A can shed the color. There is no way to "shed" async-ness like that in javascript.

> There is no way to "shed" async-ness like that in javascript.

In rust you can simply call `block_on` and call it a day. In JS there isn't such a construct by default because the blocking the thread would freeze the app, but it exists in every other language with async/await that I'm aware of.