4 ms·
The problem is more that Rust cannot (currently) abstract over these different function types; and that they are more limited (e.g. no async methods in traits).
by willtim 5y ago
The problem is more that Rust cannot (currently) abstract over these different function types; and that they are more limited (e.g. no async methods in traits). But the idea of effects tracking is a good thing and we are bound to see more of it in modern statically-typed languages.
- kevincox 5y agoThis is partly true. Unlike JS (where the colouring argument came from) you can always just block, so while you mean be "stealing" an event dispatcher thread nothing bad will happen, you just have to deal with the fact that the functions you are calling may task some time to return (as the article argues). There is no true function colouring in Rust. (Much like you can unwrap an Option or Result to handle that type of colouring.) In Rust an `async` function is just a fancy way to write a function that returns a `std::future::Future. You can certainly write a trait with functions that return a `std::future::Future<Output=T>`. Although you will probably have to box them at the moment. https://play.rust-lang.org/?version=stable&mode=debug&edition=2018&gist=0f2a4f6734293899112c9e4f7062904e https://play.rust-lang.org/?version=stable&mode=debug&editio... I think this restriction is because they are trying to figure out how to handle dynamic vs static generics. Presumably they will add support for this in the future. The compiler also recommends https://docs.rs/async-trait https://docs.rs/async-trait which has a pretty clean solution.