This is actually not about war; rather the peace and prosperity
of people writing concurrent programs.
(Andrei, I hope you are reading and will check out
https://vorpus.org/blog/notes-on-structured-concurrency-or-go-statement-considered-harmful/
and
https://vorpus.org/blog/timeouts-and-cancellation-for-humans/)
Recently I've been working with Trio, which is a Python async
concurrency library implementing the concepts described in the
articles above. A synopsis (Python):
with open_task_container() as container:
container.start_task(a)
container.start_task(b)
await sleep(1)
container.start_task(c)
# end of with block
# program continues (tasks a, b, c must be completed)...
The point is that tasks started in the container's scope will not
live past the scope. Scope exit will block until all tasks are
complete (normally or by cancellation). If task b has an
exception, all other tasks in the container are cancelled.
What this means is that task lifetimes can be readily understood
by looking at the structure of a program. They are tied to
scoped blocks, honor nesting, etc.
Similar for control of timeouts and cancellation:
with fail_after(10): # raise exception if scope not
completed in 10s
reply = await request(a)
do_something(reply)
reply2 = await request(b)
...
These are novel control structures for managing concurrency.
Combining this with cooperative multitasking and explicit,
plainly-visible context switching (i.e. async/await-- sorry
Olshansky) yields something truly at the forefront of concurrent
programming. I mean no callbacks, almost no locking, no
explicitly maintained context and associated state machines, no
task lifetime obscurity, no manual plumbing of cancellations, no
errors dropped on the floor, no shutdown hiccups. I'm able to
write correct, robust, maintainable concurrent programs with
almost no mental overhead beyond a non-concurrent program.
Some specimens (not written by me):
#1: the I/O portion of a robust HTTP 1.1 server
implementation in about 200 lines of code.
https://github.com/python-hyper/h11/blob/33c5282340b61ddea0dc00a16b6582170d822d81/examples/trio-server.py
#2: an implementation of the notoriously difficult "happy
eyeballs" networking connection algorithm in about 150 lines of
code.
https://github.com/python-trio/trio/blob/7d2e2603b972dc0adeaa3ded35cd6590527b5e66/trio/_highlevel_open_tcp_stream.py
I'd like to see a D library supporting these control structures
(with possibly some async/await syntax for the coroutine case).
And of course for vibe.d and other I/O libraries to unify around
this.
I'll go out on a limb and say if this could happen in addition to
D addressing its GC dirty laundry, the language would actually be
an unstoppable force.
Regards,
--John
