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:
>> For someone coming from a C# background there is some seemingly simple syntactic sugar missing from D.
>>

>> 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/await make asynchronous code in C# and JavaScript look clean and easy to wrap ones head around it. Solution to aka. callback hell. If popularity is what you're looking at, it JavaScript not Go. And async/await is all over the place...it more that a syntactic sugar, it a pattern.
>

> ‘async’ is viral keywords that poorly scales, I worked on Dart core team and even they admitted this problem is not solved well.
>
Doesn't scales for what?

Try C# or JavaScript and experience the true power of async/await.

On Monday, 18 June 2018 at 20:54:22 UTC, aberba 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:
>>> For someone coming from a C# background there is some seemingly simple syntactic sugar missing from D.
>>>
>
>>> 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/await make asynchronous code in C# and JavaScript look clean and easy to wrap ones head around it. Solution to aka. callback hell. If popularity is what you're looking at, it JavaScript not Go. And async/await is all over the place...it more that a syntactic sugar, it a pattern.

I look at popularity but I prefer crutical thinking.

Nothing beats simple non-async code in understamdability save for declarative stuff or no code. Really no code is best but obviously not always an option.

So why async in JS?
That is because it’s their last choice to make things at least _look_ better.

To give you a picture of how JS got to async you have to understand that they started (and still in many ways are) as

Practically all of today’s JS execution environments are single threaded process with integrated eventloop for events such as timers and clicks.

They introduced APIs back in 199x that used callbacks exclusively. Then people constructed Futures (Deferred etc.) on top.
But it’s a JavaScript (popular, just like you said) so it has to make it more builtin and simple. Because *some* (many) would think that say jQuery Deffered is slow, you’d better use plain callbacks. All of that stupidity sqaured is a day in day out talk in JS world, because well popularity.

So being wise they decided to not destroy the excecution model (but extend with workers, which are isolated process btw) but cheaply extend it with syntax shugar.

And they succeeded because now you come and say that’s basically the best thing to do.

It is not though, and I believe I’ve seen enough to act against it. I use Scala everyday, and there Futures and Monads all the way down in I/O, and no it’s not simpler nor faster model. It’s okayish but that’s about it.

Compared to proper scheduler with integrated eventloop:

async is not fast - same as futures, could use a bit less RAM per connection etc., but same or worse speed (and if you need say.. stacktrace;))

async is not convenient because it splits functions into “red” and “green”, and you can mix them anymore


async is best effort attempt to make imperatice programmers write future-based, monadic code (essentially). It was great success in that, but no, please let’s pick the better model (in general, ofc, special needs are special).


>>
>
>> ‘async’ is viral keywords that poorly scales, I worked on Dart core team and even they admitted this problem is not solved well.
>>
> Doesn't scales for what?
>
> Try C# or JavaScript and experience the true power of async/await.

Oh kid. I tried all of that and more. Like 4 years ago. Pardon for my temper but no I know what I’m talking about and it’s not “I tried it for a week and now I see async is nice”.

To hell with that!
I have actually seen and worked (not directly) on code **cking does make async stack traces tolerable (google for causal stack traces, Dart).

Again sorry to hurt your feelings but unless I see deep technical good reason to go for async, I’ll die fighting against it. Let’s bot cargocult for once, especially considering the interplay with just about any bloody language feature to get “shugar”.

P.S. Damn, it really pusses me off. No offence was meant.

—
Dmitry Olshansky

On Tuesday, 19 June 2018 at 07:14:11 UTC, Dmitry Olshansky wrote:
> On Monday, 18 June 2018 at 20:54:22 UTC, aberba wrote:
>> [...]
>
> I look at popularity but I prefer crutical thinking.
>
> Nothing beats simple non-async code in understamdability save for declarative stuff or no code. Really no code is best but obviously not always an option.
>
> [...]

I hear your rage. People should not sip the kool aid lightly.

Avoid *ANY* form of complexity unless it is really needed.
Add code only when needed
Keep things synchronous until you cannot then redesign so you can

If you really really must use asynchronous design know why you must and what you are getting into then decouple that code as much as possible.

On Tuesday, 19 June 2018 at 07:14:11 UTC, Dmitry Olshansky wrote:

>
> To hell with that!
> I have actually seen and worked (not directly) on code **cking does make async stack traces tolerable (google for causal stack traces, Dart).
>
> Again sorry to hurt your feelings but unless I see deep technical good reason to go for async, I’ll die fighting against it. Let’s bot cargocult for once, especially considering the interplay with just about any bloody language feature to get “shugar”.
>
> P.S. Damn, it really pusses me off. No offence was meant.
>
> —
> Dmitry Olshansky

Yesh. To me, it sounds like you had to work with a bunch of bad programmers rather than the faults with async.

Alexander

On Tuesday, 19 June 2018 at 13:39:51 UTC, 12345swordy wrote:
> On Tuesday, 19 June 2018 at 07:14:11 UTC, Dmitry Olshansky wrote:
>
>>
>> To hell with that!
>> I have actually seen and worked (not directly) on code **cking does make async stack traces tolerable (google for causal stack traces, Dart).
>>
>> Again sorry to hurt your feelings but unless I see deep technical good reason to go for async, I’ll die fighting against it. Let’s bot cargocult for once, especially considering the interplay with just about any bloody language feature to get “shugar”.
>>
>> P.S. Damn, it really pusses me off. No offence was meant.
>>
>> —
>> Dmitry Olshansky
>
> Yesh. To me, it sounds like you had to work with a bunch of bad programmers rather than the faults with async.

Not a single thing I said had to do with people except me describing how JS (probably) came to intriduce async.

To put specifically: no my argument is completly orthogonal to that. I hope you can see it after a while.

>
> Alexander

On Tuesday, 19 June 2018 at 07:14:11 UTC, Dmitry Olshansky wrote:
> On Monday, 18 June 2018 at 20:54:22 UTC, aberba 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:
>>>> For someone coming from a C# background there is some seemingly simple syntactic sugar missing from D.
>>>>
>
> Oh kid. I tried all of that and more. Like 4 years ago. Pardon for my temper but no I know what I’m talking about and it’s not “I tried it for a week and now I see async is nice”.
>
> To hell with that!
> I have actually seen and worked (not directly) on code **cking does make async stack traces tolerable (google for causal stack traces, Dart).
>
> Again sorry to hurt your feelings but unless I see deep technical good reason to go for async, I’ll die fighting against it. Let’s bot cargocult for once, especially considering the interplay with just about any bloody language feature to get “shugar”.
>
> P.S. Damn, it really pusses me off. No offence was meant.
No offense taken. I feel your rage...ha ha. What happened between you and the past where JavaScript was involved?
>
> —
> Dmitry Olshansky

On Monday, 18 June 2018 at 20:54:22 UTC, aberba wrote:
> async/await make asynchronous code in C# and JavaScript look clean and easy to wrap ones head around it. Solution to aka. callback hell. If popularity is what you're looking at, it JavaScript not Go. And async/await is all over the place...it more that a syntactic sugar, it a pattern.

Threads make it easy to write code that does long-running things like IO without blocking your process. Continuation-passing style is an answer to your platform not having threads. Async/await is an answer to the problems of heavily nested scopes and awkward error handling in the continuation-passing style.

D has threads.

The one uncommon case that suffers here is starting operations in parallel and collecting their results afterwards. I believe Vibe has an implementation of futures and a convenience function to run code in a separate thread and get a Future holding the result.

This does hold up one thread waiting for the others to complete, which is mildly suboptimal, but you can solve that as well as async/await by arbitrarily picking one long-running operation to execute in the current thread.

>> ‘async’ is viral keywords that poorly scales, I worked on Dart core team and even they admitted this problem is not solved well.
>>
> Doesn't scales for what?

You generally can't call an async function from a non-async function, and you need some extra dressing on an async function call. (In C# you can manually get the Task<> back and use that, but that's painful.)

So you use all async IO. You write a function. It works in memory and doesn't do IO, so you make it easy to call: you make it a sync function.

Then you change it, and now it does IO. (Maybe it checks values from a config file, and you change it to check if the config file changed on disk.) Now you have to mark the function async and change every call site to add the await keyword.

Except some of these functions might not have been async already. So you have to mark them async and repeat the process across your whole codebase.

You could make everything async by default, but then calling functions is harder. Only a little, but calling functions is probably like 20% of my expressions, and I could do without the syntactic bitter yuck.

On Saturday, 16 June 2018 at 02:44:04 UTC, Jonathan M Davis wrote:
>> * The null conditional operator `?.`
>
> It's been discussed before, and maybe we'll get it or something like it at some point, but it really wouldn't help much with idiomatic D. The average D program does a _lot_ less with classes than a language like C# does. Most stuff is done with structs on the stack - especially with range-based programming. That's not to say that certain types of programs couldn't benefit from such syntax, but it's going to be a lot less common than it is with C#. But it's also pretty trivial to write a helper function that does the same thing if you really want a short-hand way to do it.

That's not the only use case. Recently I'm using Algebraic pretty often and I really wish that this would work: alg.peek!AThing?.method();

On 2018-06-16 04:44, Jonathan M Davis wrote:

>> * The null conditional operator `?.`
>
> It's been discussed before, and maybe we'll get it or something like it at
> some point, but it really wouldn't help much with idiomatic D. The average D
> program does a _lot_ less with classes than a language like C# does. Most
> stuff is done with structs on the stack - especially with range-based
> programming. That's not to say that certain types of programs couldn't
> benefit from such syntax, but it's going to be a lot less common than it is
> with C#. But it's also pretty trivial to write a helper function that does
> the same thing if you really want a short-hand way to do it.

There's code in the DMD front end which screams for this operator.

The AST is built out of classes. It uses virtual functions to do down casting, i.e.

class Statement
{
    ForStatement isForStatement()
    {
        return null;
    }
}

class ForStatement : Statement
{
    ForStatement isForStatement()
    {
        return null;
    }
}

Statement s;
if (auto f = s.isForStatement) { f. ... }

-- 
/Jacob Carlborg

On 2018-06-16 07:48, Nick Sabalausky (Abscissa) wrote:

> If only D hadn't given up on the AST macros idea, we could actually
> implement most of this sugar AS A LIBRARY SOLUTION, just like modern D
> wants.
>
> AST macros are seriously awesome though:
>
> There's this one CLR language, Nemerle, kind of obscure (and kind of
> dead-ish now unfortunately), that has this one really weird, stupid
> limitation: If you want an "if" statement WITHOUT an "else", you have to
> say "when" instead of "if". Stupid idea. *BUT* the language supports AST
> macros. So in 12 lines of code (Yes, twelve!!!!), I added support for
> "if without else"...IN LIBRARY!!
>
> https://github.com/Abscissa/plainIf/blob/master/plainIf.n
>
> Seriously, AST macros turn a language into "LISP without
> parenthesis-hell". So freaking awesome. Wish D hasn't given up on them
> in favor of ugly unhygienic string mixins.

A couple of years ago I started trying to implement AST macros [1], it's pretty stale now.

[1] https://github.com/jacob-carlborg/dmd/tree/macro

-- 
/Jacob Carlborg