Feedback on Átila's Vision for D

[John Belmonte]

On Sunday, 20 October 2019 at 06:44:45 UTC, Russel Winder wrote:
> On Sun, 2019-10-20 at 03:23 +0000, John Belmonte via 
> Digitalmars-d wrote:
>> 
> […]
>> Rust appears to be going down the wrong concurrency path.
> […]
>
> I believe you need to expand on this claim. As far as I am 
> aware there are a number of structured concurrency crates, e.g. 
> Rayon.

long discussion here:  
https://trio.discourse.group/t/structured-concurrency-in-rust/

My summary as an onlooker:
   * Rust and/or the structured concurrency libraries don't have 
cancellation scopes (see 
https://vorpus.org/blog/timeouts-and-cancellation-for-humans/)
   * Rust has a competing ecosystem by way of futures, which adds 
significant API complexity and fractures the concurrency 
ecosystem for no advantage over async/await + structured 
concurrency

excerpt:
>> There are multiple crates out there that implement coroutines, 
>> but for now the futures ecosystem seems to be some orders of 
>> magnitude more popular.
>
> Right – if you don’t have compiler support, then coroutines are 
> really inefficient (you need to allocate big stacks, like 
> threads) and futures are the only viable path. If you do have 
> compiler support, then they’re equally efficient, and 
> coroutines are simpler and easier to work with.
>
> That’s why async is such a trap for language designers: if you 
> knew from the start that you were going to add 
> syntax/compiler-support for async, then coroutines would be the 
> obvious way to go. But generally by the time you’ve convinced 
> yourself that you need syntax/compiler support, then you 
> already have a large futures ecosystem, and you’ve trained 
> yourself to think in terms of futures. It’s very difficult to 
> step back and realize that as soon as you add async syntax, all 
> your awesome futures APIs, which were important and tricky and 
> crucial, suddenly become unnecessary bloat.