5 ms·

Javascript (where the color analogy is from) does not allow in any way calling promise/async/callback based functions as if they were blocking. Every language

Javascript (where the color analogy is from) does not allow in any way calling promise/async/callback based functions as if they were blocking. 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.

BenoitP 6y ago
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.
- gpderetta 6y ago
  > There will be no issue in terms of program correctness there is if it leads to deadlocks.
gpderetta 6y ago
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).
pron 6y ago
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.
- hobofan 6y ago
  (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.
- jevgeni 6y ago
  Most of the functions are syntactically distinct.
- pornel 6y ago
  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.
hobofan 6y ago
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.
SideburnsOfDoom 6y ago
> > 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.
- shakow 6y ago
  > 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-your-function/ 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.”
  - SideburnsOfDoom 6y ago
    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.
stefan_ 6y ago
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.
- MaulingMonkey 6y ago
  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/892fab053b4f6d26929a2aba71be751f9195630b/examples/example1.rs#L10 https://github.com/MaulingMonkey/untokio/blob/892fab053b4f6d...
- auganov 6y ago
  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.
resonantjacket5 6y ago
"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.
- _flux 6y ago
  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..
  - kuschku 6y ago
    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

BenoitP 6y ago

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.

gpderetta 6y ago
> There will be no issue in terms of program correctness there is if it leads to deadlocks.

gpderetta 6y ago

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).

pron 6y ago

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.

hobofan 6y ago
(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.
jevgeni 6y ago
Most of the functions are syntactically distinct.
pornel 6y ago
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.

hobofan 6y ago

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.

SideburnsOfDoom 6y ago

> > 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.

shakow 6y ago
> 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-your-function/ 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.”
- SideburnsOfDoom 6y ago
  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.

stefan_ 6y ago

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.

MaulingMonkey 6y ago
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/892fab053b4f6d26929a2aba71be751f9195630b/examples/example1.rs#L10 https://github.com/MaulingMonkey/untokio/blob/892fab053b4f6d...
auganov 6y ago
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.

resonantjacket5 6y ago

"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.

_flux 6y ago
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..
- kuschku 6y ago
  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