|
Top-level
 I'm in two minds, to be honest. New features are good and generator syntax is good, writing iterators by hand today is annoyingly finickey. Yet, I am really sad that Rust seems to be diving head-first into the function-colouring mistakes of old though. First `?`, then `.await`, and now `yield`. These are all the same thing, but now we have a million different incompatible concepts to account for as API designers. 5 comments
I want a version of Rust where: - Algebraic effects are a thing I know that some of these things are in tension (It wouldn't make much sense for iterators/generators to be linear, say), but being able to choose linearity based on the effect would be really nice and would reduce the extent to which async code needs to guard against the subtle perils of cancellation. @jsbarretto interesting list. Personally, I would like to see pinning as another reference type: &pin _. If there is no cancellation of futures, how are deferred/background tasks cancelled? E.g. stopping a stream of data from http because it is not needed anymore. @boxdot 'No cancellation' doesn't mean 'task can't end': it just means that a future can be sure that it doesn't get suddenly cancelled by an external entity. The future must run to completion. If you want to end a background task, you send it a signal via a channel or something of the sort and then it returns of its own accord upon receiving this signal. |
Gregory's Server
To be honest, I'm quite tired of needing to add `try_`, `async_`, etc. versions of the APIs I write. It's annoying and makes me want to avoid developing APIs that encourage the use of closures, even though - in my view - statically dispatched closures are *the* killer Rust feature that almost all the other killer Rust features sit on top of. This is complexity that *should* be pushed up to the language rather than muddying every single non-trivial API that sits below it.