D community's view on syntactic sugar

[Dmitry Olshansky]

On Saturday, 30 June 2018 at 07:45:48 UTC, John Belmonte wrote:
> 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.

Okay. I see that you see. I “meet” a guy, you know I admire that 
he _somehow_ made an

HTTP Application server that is faster then let’s pick good 
stuff...

Nginx Plus with tuning by Igor himeself

(before sweat too mich like Igor at least twice did - no shit 
these discussion, you THAT guy he rans his... GWAN? as if it was 
_just_ an spplication server.

You know not a word more but sombody who say:
- knows infosecurity and likes that stuff that say slices into 
the kernel - rootkit for instance
- aand say injects something into the kernel....

You know where it goes and yet that guy obviously good and the 
humor....

Boy wicked humor, I kid you not I “invented” this trick this 
morning....

AND *solved* the _mystery_ of GWAN.

Fuck, it is at _very_ least a brilliant hoax, and boy he is 
good...

He if that’s the real name....

I mean what if this is Linus (oh, my and you know GWAN started 
_as_ _windows_ “app server” ...)

If you don’t laught now... I don’t now..

At the *very* least don’t _ever_ go to DConf...

What the fuck with brain like you simply will not like it....

P.S. Atilla even if that is “alternative way” to *do* it... Yeah.

Let’s say you owe... a bear and an a few hours to dicsuss it, 
okay? ;)

>
> 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.