On 2013-11-13 21:41, Igor Bukanov wrote:
> On 13 November 2013 20:41, Bardur Arantsson <[email protected]> wrote:
>
>> In practice it's much more difficult to be *explicitly*
>> async and it should just be delegated to the language/runtime. There are
>> some things humans just aren't good at.
>
> I suspect Rust makes asynchronous programming significantly more
> bearable. Programming in JS in that style is often painful due to the
> noise of all those function() { } spread through the code and bugs
> connected with accessing stuff that should only be ready later. Rust
> nicely addresses that with shorter syntax for closures/macros and move
> semantics.
>
> So an experiment of writing in asynchronous style in Rust and
> comparing that with C++/JS/other languages would be very useful to
> judge.
>
It's *not* a matter of just making the syntax "lighter". Asynchronous
callbacks lead to "the pyramid of doom" (as Dave Herman puts it) of
nested callback functions.
Unfortunately, instead of actually fixing the underlying problem (which
is the need for an explicit callback model in the first place), the
ECMAScript committee seems to have gone with
function foo*(...) {
yield ....;
}
which is lighter syntax but still absurd. (To bear fair they also have
extreme constraints of backward compatibility.)
Python has also (to my great disappointment) gone this route, but there
you can't even tell "from the outside" if a function is async-safe --
it's not part of its interface syntactically, but it's of huge
importance in practice.
My overall point is: Why should the *programmer* be segregating
functions into asynchronous and synchronous? We have computers and
compilers which are more than capable than doing this for us at this point!
Regards,
_______________________________________________
Rust-dev mailing list
[email protected]
https://mail.mozilla.org/listinfo/rust-dev
