Hacker News Reader

Comment by AnkhMorporkian | Hacker News Reader

You know what I've always wanted to see (and it's quite possible one exists; I have never actively searched for one)? A completely asynchronous programming language. Every single operation is carried out asynchronously; everything from addition to while loops.

Synchronization would be a nightmare, but I think it would be a fun exercise to see what you could do in that framework.

View on HN

Erlang is sort of this. All I/O is done by passing messages to Port objects which send the results/errors back as messages. Your process doesn't block until you tell it to and you don't block on a single operation exactly: you block on waiting for a message in your process's mailbox.

The nice thing about this approach is that you can emulate blocking or non-blocking I/O within the same function or even against the same file descriptor. And processes are so cheap that if your callees do block in unexpected ways you can just move that one call into its own process that just sends you a message when it's done.

Such a language would translate really nicely to hardware. Funnily enough, verilog / VHDL are the closest I can think of...

You don't get what you would normally think of as "while loops" though, which makes sense if you think about it.

Check out MyHDL and Cocotb:

http://www.myhdl.org/

http://potential.ventures/cocotb/

Hoare's CSP is exactly this. It's not a programming language per se, but I know of several DSL's that were built using CSP syntax. https://en.wikipedia.org/wiki/Communicating_sequential_proce...

How would that work? My understanding of async is that it's a way of interacting with IO. So how would the examples you give (additional, while loops) behave asynchronously, since they don't involve IO? (Except for maybe memory IO..?)

Addition still takes time though doesn't it? The idea is I could start an addition operation, and then be notified in some way when it's done.

I think the idea most similar to what the grandparent wants is instruction-level dataflow, where programs are DAGs, and instructions are only run when their inputs are ready, rather than when a program counter reaches them.

Physical dataflow machines were built that did this in hardware.

A program as a DAG.... Whoa. That's an interesting concept to try to wrap your mind around.

Just fyi, a library openstack (and myself and others) has created (in python) basically lets u program your workflow (really dataflow) as a DAG, and then the library will run it reliably (and in parallel and so-on). I'm more than willing to answer questions about how it does that if people are interested...

http://docs.openstack.org/developer/taskflow/

https://pypi.python.org/pypi/taskflow

And yes u can do things like built equation solvers to:

http://docs.openstack.org/developer/taskflow/examples.html#l...

And other neat things:

http://docs.openstack.org/developer/taskflow/#examples

That's exactly how Haskell's IO monad works (albeit a little simplified)

> programs are DAGs, and instructions are only run when their inputs are ready, rather than when a program counter reaches them.

At a low level, that's exactly what modern CPUs do.

https://en.wikipedia.org/wiki/Out-of-order_execution

Right, but only on a single core and only over a small sliding window. Real data flow machines made it explicit rather than a fragile optimisation and scaled it up.

True, though with multiple functional units there is some parallelism. Just thought it was an interesting comparison.

This is called Continuation Passing Style: https://en.wikipedia.org/wiki/Continuation-passing_style

Nothing about CPS ensures asynchrony.

But it enables it.

This was attempted with Midori, see here:

http://joeduffyblog.com/2015/11/19/asynchronous-everything/

There are some doing that by default, but I can't remember the names. Every operation can be done in parallel unless you declare a necessary order for some subset(s) of operations.

Is lazy evaluation asynchronous enough for you? It's more predictable than random asynchronous I/O, though, so synchronization is easier.

Haskell does this.

Reply on news.ycombinator.com