Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

Can we please stop using this "color" argument to Rust? The original colouring article was about JavaScript, a dynamically typed language. But rust is a statically typed language, and in a sense, the type is the colour. You can't return an error from a function that does not return a Result<>. And most people agree it is a great thing over dynamic/implicit exceptions. Declaring a function just changes the return type to return a future instead.

Also, it's been many year Pin was stabilized, and that you can write `impl Fn(Xx)` instead of using a where clause, and return closures using that syntax.



The color problem matters for static languages as much as for dynamic languages.

The essence of the problem is whether you can turn internal iterators into external ones without rewriting them. If you can't then your language has function colors.


Also Rust async runtimes have `block_on(async)` and `spawn_blocking(sync).await`, so the main problem of call graphs split by "color" doesn't exist in Rust. Rust can merge the two worlds.

Unlike JS, Rust can wait for async code in blocking contexts, and it can run CPU-bound code in async contexts.


The only thing a type-system brings to the table in this matter is an error at compile time if you used the wrong color.

It won't solve the color problem.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: