Any time you have a barrier between one function being able to call another. The original article on this called them red functions and green functions. A green function can call a red function but a red function can't call a green function.
In terms of async, it's when you have to have a function with "async" attached to it and making it so that only other async functions can call async functions.
It ends up creating a weird circumstance where you can end up with a lot of duplicated APIs, particularly in libraries, because you are providing both async and non-async versions of functions.
The coloring is a property of concurrency safety and whether the language enforces it.
For instance, if you resolve a future in the wrong context you'll still have problems - the coloring is just a compile time error that you are doing things wrong, rather than a runtime deadlock.
The term comes from an old blog post [0] about different kinds of effect systems. Every function has a color, and every colored function can only call functions that are compatible with it, usually of the same color. The net result is that you end up either duplicating a lot of your common code so you have compatible interfaces for all the different colors (let's call that "separate but equal" if we're feeling spicy), or you end up shoving round pegs into the square holes of your dominant function color.
The terminology is used to talk about languages that have async and sync functions where you declare (or color) the function as either async or sync.
In these languages it's pretty common for the language to enforce a constraint that async functions can only call other async functions. Javascript / Typescript, Python are popular examples of languages with colored functions.
No, it refers to a function that has constraints on how it can be called and composed. A classic example is functions tagged `async` in languages like Javascript or Rust.
(Technically, that's the symptom - the underlying cause is that it's a function that involves some effect, like asynchronicity, or, in some functional languages, IO.)
Any time you have a barrier between one function being able to call another. The original article on this called them red functions and green functions. A green function can call a red function but a red function can't call a green function.
In terms of async, it's when you have to have a function with "async" attached to it and making it so that only other async functions can call async functions.
It ends up creating a weird circumstance where you can end up with a lot of duplicated APIs, particularly in libraries, because you are providing both async and non-async versions of functions.
The coloring is a property of concurrency safety and whether the language enforces it.
For instance, if you resolve a future in the wrong context you'll still have problems - the coloring is just a compile time error that you are doing things wrong, rather than a runtime deadlock.
Right, and a lot of people would rather avoid that issue altogether by using a different concurrency model.
The term comes from an old blog post [0] about different kinds of effect systems. Every function has a color, and every colored function can only call functions that are compatible with it, usually of the same color. The net result is that you end up either duplicating a lot of your common code so you have compatible interfaces for all the different colors (let's call that "separate but equal" if we're feeling spicy), or you end up shoving round pegs into the square holes of your dominant function color.
[0] https://journal.stuffwithstuff.com/2015/02/01/what-color-is-...
https://journal.stuffwithstuff.com/2015/02/01/what-color-is-...
The terminology is used to talk about languages that have async and sync functions where you declare (or color) the function as either async or sync.
In these languages it's pretty common for the language to enforce a constraint that async functions can only call other async functions. Javascript / Typescript, Python are popular examples of languages with colored functions.
https://journal.stuffwithstuff.com/2015/02/01/what-color-is-...
In this context: functions anotated with async
[flagged]
Please don't fulminate on HN. The guidelines make it clear we're trying for something better here. https://news.ycombinator.com/newsguidelines.html
[flagged]
No, it refers to a function that has constraints on how it can be called and composed. A classic example is functions tagged `async` in languages like Javascript or Rust.
(Technically, that's the symptom - the underlying cause is that it's a function that involves some effect, like asynchronicity, or, in some functional languages, IO.)
No.