Update on await syntax in Rust

"What would be so hard about divided_by_2 = divide_by(, 2)"

Well, first of all, it doesn't work right now, which is a problem for what I was trying to say.

Secondly, if you want to curry things, you'll end up with

    four_arg_func(1, 2)(3)(4)

at a bare minimum as a "curried application", where in Haskell it's just

    four_arg_func 1 2 3 4

Several Algol languages have other issues, such as dealing with optional arguments: in Python!curryable, is the result of

    def f(a, b, c = 10):
        return a + b + c

    f(1, 2)

a function that accepts one more parameter for c, or the number 13? (Even in a dynamic language you ought to think twice before trying to return some sort of "quantum superposition" of those two things!) You'll need to add some syntax that will specify the answer to that question, and now Python!curryable is getting away from just "incompletely applying the function" as it is in Haskell, but now a Thing you have to Do. (Probably by calling https://docs.python.org/2/library/functools.html#functools.p... .)

Haskell hacks that away by making it so functions take a fixed number of parameters, in a fixed order, and there is no such thing as default parameters to a function. A non-Haskell programmer may feel this is not a trade worth making.

Your closure at the end is what it tends to really look like. You'll note that most non-functional code doesn't really do that sort of thing very often, unless you're unlucky enough to stumble across a codebase written by someone trying to write Haskell-in-Python or something.

> I think it's totally reasonable to judge a road surface based on how effective it is, in practice, with the kinds of traffic that will be travelling on it.

Yes, and if we outlawed the use of cars without traction control on certain roads, then I would be fine with designing with the assumption traction control will be on. But as long as you allow older cars without traction control to still drive on the road, you are making the roads less safe for a certain percentage or class of drivers. I view that as different that just making the road safer for some.

> But we should also keep an awareness that it won't always be there.

Exactly. And this is why I think it doesn't make sense as a mitigation to a language level feature which will always be there.

Specifically, I think syntax highlighting is a useful feature and a plus for a comparison, I just don't think it works as a mitigation for a negative for something that pervasive.

All other things being equal, syntax highlighting abilities might push me towards one solution over another, but they won't make me ignore a problem I perceive with a solution.

Depends on the language and the circumstance.

In .NET it defaults to scheduling continuations in the "main" thread as much as possible, with the easiest escape valve being Task.ConfigureAwait(false) that tells it that it can finish continuations wherever they land in the ThreadPool. This is why you can often find a lot of (partly mistaken) advice in .NET to always use ConfigureAwait(false) for "performance" which as often as not leads to people rediscovering the hard way why the easy default is continuations on Main/UI threads. There actually is a more complex TaskScheduler mechanism underlying that big ugly valve, but TaskScheduler is not quite as featureful or easy to control as the RX-equivalent scheduler.

(I heard some rumblings that the .NET team was considering in the long run to better unify async/await TaskScheduler scheduling with the Scheduler model of RX.NET, but I don't know if anything has progressed yet along those lines.)

Python mostly requires manual management of event loops for async/await coroutine scheduling. Most Python code, even/especially using async/await is still generally single-threaded (due to artifacts like the GIL [Global Interpreter Lock] that are getting better with each passing version of Python), so more complicated scheduling is both generally not necessary and also left as an exercise to the user.

ECMAScript 2017 (JavaScript) async/await is also mostly running in single threaded event loops (though not manually managed like Python; generally browser UI event loop managed).

Here's the proposal: https://internals.rust-lang.org/t/explicit-future-constructi...

One of the goals behind it was to align async control flow with sync/thread-based control flow, to make it more intuitively obvious when things would run concurrently and when they would not. That is, calling a function, even if async, would immediately run it to completion, while wrapping it up in a closure or async block that gets spawned would run it concurrently.

This is especially relevant to Rust, which departs from other implementations of async/await in that merely constructing a future is insufficient to start it running, which is why you need that `join3` call to explicitly introduce concurrency.

Under the "implicit await" proposal, your first example would look like this:

    async fn foo() {
        let result = blocking_req(); // await immediately
        let future = async { blocking_req() }; // think of async{} like a lambda function
        // can do more complex stuff with the future, like:
        //  future.await()
        //  Future::join(future, other_future)
        //  tokio::spawn(future)
    }

The thread-based equivalent looks very similar:

    fn foo() {
        let result = blocking_req(); // block the current thread immediately
        let closure = || { blocking_req() }; // don't run this yet
        // can do more complex stuff with the closure, like:
        //  closure()
        //  rayon::join(closure, other_closure)
        //  thread::spawn(closure)
    }