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