3 ms·

Off-topic, but the idea of "colored functions" from the "What Color is Your Function" article doesn't apply to Rust's async/await. That article is about JavaScr

Off-topic, but the idea of "colored functions" from the "What Color is Your Function" article doesn't apply to Rust's async/await. That article is about JavaScript before it had async/await, when it used callbacks. In Rust, you can call async functions from normal ones by spawning them on the executor. The .await syntax isn't as painful as dealing with callbacks and closures in JavaScript. Plus, if you call an async function incorrectly, Rust's compiler will catch it and give you a clear error message, unlike JavaScript, where bad function calls could lead to unpredictable behavior. The premises of the article don't apply, so Rust's async/await doesn't introduce the same "colored function" issues. (See also https://without.boats/blog/let-futures-be-futures/ https://without.boats/blog/let-futures-be-futures/ )

lolinder 1y ago
I read the article when it hit HN months ago but I don't agree that function coloring doesn't apply. What you're describing is that Rust makes coloring less painful, not that functions aren't colored. JavaScript itself has come a long way towards making coloring less painful. TypeScript+ESLint solves the weird unpredictable behavior issues with JS and async/await solves the syntax issue. Promises in general give well-defined semantics to calling an async function from a sync function. But all that only undoes some of the arguments about function coloring, not all of them. Fundamentally the same question applies: do you make async-ness part of the type system or do you instead build a system like green threads that doesn't put it in the type system? I happen to think that coloring functions according to their async-ness is actually the right move (with the right ergonomic improvements), but plenty of people don't agree with me there even with all the ergonomic improvements Rust and TypeScript have made to the model.

lolinder 1y ago

I read the article when it hit HN months ago but I don't agree that function coloring doesn't apply. What you're describing is that Rust makes coloring less painful, not that functions aren't colored. JavaScript itself has come a long way towards making coloring less painful. TypeScript+ESLint solves the weird unpredictable behavior issues with JS and async/await solves the syntax issue. Promises in general give well-defined semantics to calling an async function from a sync function. But all that only undoes some of the arguments about function coloring, not all of them. Fundamentally the same question applies: do you make async-ness part of the type system or do you instead build a system like green threads that doesn't put it in the type system? I happen to think that coloring functions according to their async-ness is actually the right move (with the right ergonomic improvements), but plenty of people don't agree with me there even with all the ergonomic improvements Rust and TypeScript have made to the model.