If there are two types of functions with syntactically distinct calling mechanisms, and there is a cost, in both syntax and performance, for mixing them, then you have two colours. That the cost of mixing isn't infinite but just high -- high enough to require two distinct sets of APIs, one for each colour -- then you have two colours with all their issues, even if to a somewhat smaller extent than the extreme, and unusual, case of JS. If doing something is expensive and unrecommended, then doing it is very much an issue.

(Author here)

I think you've made a good point, though I disagree on the expensiveness. I think the point I should have tried to make is "Rust's async fns are colored, but I don't think that's a big problem".

In my head I used "suffers from the coloring problem" (which I would 90% attribute to point 3 in the post) and "is colored" interchangeably, but obviously there is a difference between the two.

The original article explicitly says it's not about syntax or performance. It's about irrecoverably splitting call graphs when sync functions can't wait for async results. JS has this issue, but Rust and C# don't.

In case of Rust the syntax difference is a deliberate design choice, because `.await` points can also return from the function. Rust handles errors with locally explicit `?` for the same reason.

Most of the functions are syntactically distinct.

Javascript is particularly problematic as there is an uncrossable divide between the async and sync world. But any language with stackless coroutines has as similar problem where you cannot yield across a function stack unless the whole function stack cooperates (i.e. every function is async).

> > Every language where you can call an async function as if it was blocking has no colored functions, and none of the issues of it.

So then C# "has no colored functions" despite being the prime example of them, just because there are escape hatches from "async await" in the form of .Result and co?

This seems like an absurd position to take.

> despite being the prime example of them

Quite the opposite, the main target of the original post (https://journal.stuffwithstuff.com/2015/02/01/what-color-is-...) is JS, not C#; which is explicitly described as not having the problem: “In C#, you can use the await keyword to invoke an asynchronous function.”

That article says

> So JS, Dart, C#, and Python have this problem

The reason why C# _might_ be considered to not have coloured functions is not because "you can use the await keyword to invoke an asynchronous function", it is that, when for whatever reason you cannot use `await`, then there are ways to synchronously call the async code, the simplest being appending `.Result` to the end.

Of course these are not ideal to use, but "escape hatches" to the coloured functions do exist; and yet there are still two "colours" to the functions" - async and not.

it is wrong to say that "C# does not have coloured functions". OK, you can work around this problem. But it's still a problem.

That is such absurd hyperbole. Just because I can wrap an async function call in 10 lines of runtime-specific boilerplate doesn't make the function color problem any less annoying.

It stops unnecessary pollution when dealing with code you cannot control. Often you couldn't care less about the asynchronicity of some calls. Sometimes it's not even obvious why some things are async at all. You're forced to make your code async even when it was never meant to be async as per your mental model.

10 lines is fairly annoying. Fortunately, the color change bit alone is just 1 line - and you can mix runtimes, although the wisdom of doing so is questionable.

    println!("{}", futures::executor::block_on(library::read()).unwrap());

https://github.com/MaulingMonkey/untokio/blob/892fab053b4f6d...

Yes, that is exactly the point I was trying to make!

It seems like a more concrete example of JS in contrast to Rust could have cleared up the confusion, but I didn't really want to make it a X vs. Y article that just comes of as language bashing.

Well, making a blocking call -say writing to a log for auditing purposes- in a tight loop can dramatically decrease performance.

There will be no issue in terms of program correctness, but there will be one in terms of performance assumptions. And performance might actually have been why the programmer chose Rust in the first place?

Seems like Rust's async are not correctness-colored, but they are performance-colored.

> There will be no issue in terms of program correctness

there is if it leads to deadlocks.

"does not allow in any way calling promise/async/callback" To be accurate you can wrap your promise with a spin lock and wait on it if you really really want to. It's just a horrible idea for the browser. But yes you can wait on async functions if desired, the js language doesn't actually prevent it, there's just no built-in feature.

Does this actually work, though? I would expect it to fail similarly as this fails (note, may hang your browser or a tab, depending on your browser):

  var foo = [0];

  function setFoo() {
    console.log("Callback");
    foo[0] = 1;
  }

  setTimeout(setFoo, 100);
  console.log("Waiting..");
  while (!foo[0]);
  console.log("Done.");

Edited the original message with reversed arguments to setTimeout; doesn't seem to affect the results though. Really need to love the complete lack of error messages though..

It doesn't, as promise resolution and execution is scheduled as new tasks on the main thread, which are only ever run if the currently executing piece of code finishes.

That's pretty much identical between IO, setTimeout/setInterval and requestAnimationFrame