Hacker News Reader

Comment by amelius | Hacker News Reader

Offtopic. Does anybody know of a practical imperative language in which promises are implicit? Often, when writing software, it happens that deeply nested functions suddenly have to return a promise instead of a direct value, and this forces the programmer to rewrite all the callers of that function into dealing with promises, which of course sucks. So it would be better if the programming language would do that rewriting instead (under the hood), so to speak.

View on HN

This is what monadic syntax is for. You can do the following for any Future in scala:

    for {
       resa <- asyncCall(1)
       resb <- asyncCall(2)
       resc <- asyncCall(3)
    } yield new Obj(resa, resb, resc)

which just gets rewritten to

    asyncCall(1).flatMap(resa => asyncCall(2).flaMap(resb =>
           asyncCall(3).map(resc => new Obj(resa, resb, resc))))

This doesn't just work for futures, it works for any monad. This is super amazingly useful. Also, query syntax for LINQ in C#/F# can support this too.

With scala async, you can also express this in direct style: https://github.com/scala/async.

There's Async Await. Which makes asynchronous code look like regular blocking code. But the calling code needs to know about it.

I recognise your concern: asynchronicity is infectious if it's manifested as monads. Which sucks. Client code needs to know whether the code it is calling is blocking or asynchronous.

Maybe effect systems can trace through code whether it is 'infected' with blockingness. Without any change showing in the intermediary source code. The blockingness/non-blockingness only manifesting itself at the top of the call graph.

You are literally describing monads.

Haskell. It's do-notation also makes it a very good imperative language.

Go. It's what I love most about it. If something needs to wait for a response, e.g., a database call, your goroutine just pauses without blocking any other goroutine, even if you're running only a single process. You never have to return a promise.

Contrast that with JavaScript where you're forced to use promises/async await. If you don't, you block the whole event loop.

See also "What Color is Your Function": http://journal.stuffwithstuff.com/2015/02/01/what-color-is-y...

I don't understand the claim that not using async / await and promises with js will block the event loop. Can you elaborate on what you mean?

I mean that, in an event loop, synchronous code is blocking code. If you could synchronously run a database query in Node, nothing else would be allowed to execute while you waited. That's why you have to use asynchronous callbacks/promises/generators/await whatever.

In Go I can make an apparently synchronous database query without blocking anything except the calling code.

looks like async/await (C#) is close to what you're looking for.

Reply on news.ycombinator.com