4 ms·
I really don't see a problem with function color in a typed language. Every function has color and compiler enforces you pass right color. Async is just another
by xfer 6y ago
I really don't see a problem with function color in a typed language. Every function has color and compiler enforces you pass right color. Async is just another type that may have some convenient syntax. It might be inconvenient in untyped languages like js since you couldn't compose them.
- CyberRabbi 6y agoIt’s not a problem of being error-prone, the problem is that the ecosystem is split. As a crate author, do I implement my functions for color A or color B? Every crate author will eventually encounter this question and the inevitable fall out from making the wrong decision. Presently, the only way to deal with this is implement your functionality in both colors.
- hctaw 6y agoIt's only a question if the function needs to call something else that could be either color. The vast majority of code does not. It would take a couple months of bike shedding syntax and discussing internals but I feel like there's a version of this (applied to other function colors) that allowed a library author to annotate/decorate a function for an inclusive or exclusive set of these decorations the compiler can pick to call from a calling context, and allow the function author to specialize over the combination of decorators that actually get called. Since the set of decorators is small (I can only think of 2-3, including async) this feature would be straightforward to implement albeit potentially verbose. There's a fancy compiler pass to make async work though. You need a special control flow analysis to figure out yield points in async bodies, since this new syntax would have no await. It's probably too late for that. It might be implemented in terms of HKT.
- xfer 6y agoIf your function represents async workflow then you can just implement the async side and the caller can just block on it if they want that semantics. The problem with the ecosystem in Rust is there are various runtime libraries and no standard way to factor it out. You shouldn't need to implement the blocking semantics since it should be trivial.
- ben509 6y agoIt's a problem in that you can't arbitrarily compose synchronous and asynchronous functions. Many languages have a distinction between statements and expressions, and some language designers thought that was ugly and designed languages where everything is an expression. But because of how people think, an application typically has a rough hierarchy to it by the designer's intent. So the fact that this becomes a bit more explicit because a language marks statements or async functions as having a specific place in that hierarchy isn't generally a bad thing.
- xfer 6y agoYou can't arbitrarily compose 2 functions with mismatched types. So i don't think this argument holds in a typed language.
- akvadrako 6y agoThe problems are (1) either you write two versions of almost every function or you can only support one use case (sync or async). If you could write generic functions which work in both cases it would be better. (2) it creates a lot of noise writing async/await. It's like if we had to always write x = call f() in the sync case.