4 ms·
You are getting pushback because people don't agree with your core assertion. The point of the colored function is that the color is a leaky abstraction. No mat
by zaphar 6y ago
You are getting pushback because people don't agree with your core assertion. The point of the colored function is that the color is a leaky abstraction. No matter the language you are using an async function call inside a sync function must be converted into a sync call and vice versa. Some languages make it easier than others to do but you can't escape the fact that you must do that conversion.
Rust assists you by enforcing the distinction with compile time type checking. But all that is doing is yelling at you that you are trying to mix the two fundamentally non-composable things together. You still have to do the conversion yourself. You still have to do extra work to accomplish the conversion.
Also it's just ugly to have layer after layer of async/sync wrapping going on. So what ends up happening is that you end up preferring one color over the other. Either you try to keep everything asynchronous or synchronous to avoid the whole thing.
- shakow 6y ago> The point of the colored function is that the color is a leaky abstraction I disagree with this take; I understand the point of the original “What color is your function?” as colored functions creating an impassable divide between Promise-wrapped values and sync code. Indeed, in the end, the author mentions e.g. C# as not being colored, because even if sync/async functions are different, it features escape gates to unwrap promises and bring them back into the sync world.
- Analemma_ 6y agoC# isn't exactly doing a great job at escaping the color world, judging by the number of bugs I've seen where calling .Wait() or .Result on an async function from a sync one caused the entire application to deadlock.
- hobofan 6y agoI see your point, but I partially disagree. > trying to mix the two fundamentally non-composable things together. You still have to do the conversion yourself. I think the fact that you can do the conversion shows that they are composable. As I've written in the blog post, I don't mind verbosity verbosity much, as long as it gets me some control. > The point of the colored function is that the color is a leaky abstraction. And I think that's where the difference lies. In JS, an async function will leak all up your callstack, while in contrast in Rust, you can clearly control where the leaking stops. > Also it's just ugly to have layer after layer of async/sync wrapping going on. So what ends up happening is that you end up preferring one color over the other. Either you try to keep everything asynchronous or synchronous to avoid the whole thing. I think that's fair, but I haven't really had much problems with that in practice.
- zaphar 6y agoJust to double check I went back and re-read the article. It wasn't strictly about JS. It was about the entire concept of async await. In fact if you read it he dunks on C#, Dart (the language he works on), and python. He only calls out one language as having gotten it right. Go. Go eliminated the distinction. Everyone of his points about JS/C#/Dart all tick the same boxes he calls out as problematic in Rust as well. The size of the problem may be simpler but you haven't eliminated it. Everything is composable if you wrap it appropriately. Saying that since you can convert something into a newer more composable form doesn't imply that the original is composable. It just means that since we can write code everything is composable with the right amount of work. What people actually mean when they say two things are composable is that you don't need a shim to compose them together.