D community's view on syntactic sugar
John Belmonte
john at neggie.net
Sat Jun 30 07:45:48 UTC 2018
On Saturday, 16 June 2018 at 08:39:07 UTC, Dmitry Olshansky wrote:
> On Friday, 15 June 2018 at 23:04:40 UTC, Sjoerd Nijboer wrote:
>> T* he `async` & `await` keyword from C# make proactor pattern
>> async code extremely easy to reason about.
>
> God please no. Look at Go’s popularity because of dead simple
> go routines and “async i/o is transparent and looks blocking
> but ain’t so”. We have at least vibe.d for that and possibly
> more. Also see Java doing fibers recently, and Kotlin did them
> just a year or so back. People love fibers and mostly dislike
> Futers/explicit async, and plain callbacks are obvious last
> resort that nobody likes.
>
> ‘async’ is viral keywords that poorly scales, I worked on Dart
> core team and even they admitted this problem is not solved
> well.
I've found it fascinating to follow discussion and efforts to
improve the structure and control of concurrency and async
operations for software programming in general. I'm not partial
to async/await at this time but it seems rash to discount it.
Elsewhere in this thread, the "What Color is Your Function?"
article was referenced against async/await.
(http://journal.stuffwithstuff.com/2015/02/01/what-color-is-your-function/).
There's a fair rebuttal to that article, "The Function Color
Myth". (https://lukasa.co.uk/2016/07/The_Function_Colour_Myth/).
I.e. all the concurrency models can be done without coloring.
Coloring is an aid which can be used judiciously.
There's the "Unyielding" article which argues that implicit
coroutines are just as hard to reason about as preemptive
threading.
(https://glyph.twistedmatrix.com/2014/02/unyielding.html)
Most promising in this area is a recent article by Nathaniel J
Smith: "Notes on structured concurrency, or: Go statement
considered harmful"
(https://vorpus.org/blog/notes-on-structured-concurrency-or-go-statement-considered-harmful/)
Essentially he's arguing that the way we spawn concurrent tasks
is as bad as global goto/jump was in its day, and we need to
reign in concurrency with some control structures which let us
reason easily about task lifetimes, cleanup, error propagation,
etc. His implementation of these ideas happens to be built on
top of Python's async/await, but I don't think that primitive is
a requirement.
It would be interesting to try to implement these control
structures by library in D, and perhaps it would suggest some
primitives lacking from or better suited for the language itself.
The fact that D hasn't yet jumped on either of the async/await or
implicit coroutines bandwagons puts it in a good position to get
this right.
More information about the Digitalmars-d
mailing list