• zoujiaqing (4/4) Sep 23 2021 Swift 5.5 including async/await.
• jfondren (24/28) Sep 23 2021 And Nim, and Rust, and Zig. I think of it as a lot like garbage
• russhy (27/55) Sep 24 2021 adding vibe as dependency = make your project much much slower to
• jfondren (10/13) Sep 24 2021 The X that I'd like is faster compilation of vibe and std.regex
• Paul Backus (4/7) Sep 24 2021 It seems like this problem (dependencies leading to ecosystem
• SealabJaster (3/4) Sep 24 2021 Let's call it `std.experimental.xxx` where for some reason it
• Tobias Pankrath (7/11) Sep 24 2021 Python and C# went the generator => async route and if the

zoujiaqing <zoujiaqing gmail.com> writes:

Swift 5.5 including async/await.

TypeScript support it.
Kotlin support it.

jfondren <julian.fondren gmail.com> writes:

On Friday, 24 September 2021 at 03:16:36 UTC, zoujiaqing wrote:
 Swift 5.5 including async/await.

 TypeScript support it.
 Kotlin support it.

And Nim, and Rust, and Zig. I think of it as a lot like garbage 
collection:

1. deadlocks (memory errors) are too hard to deal with! Why can't 
software handle this instead of us poor programmers?

2. async funcs (GC-using functions) are cleaner and easier to 
write. Don't mind the invisible extra work.

3. huh, this new cure-all comes with surprising downsides like 
'colored functions' (GC-assuming APIs) that are annoying to 
expose to the C ABI, and that want other functions to share their 
'color' (also use/avoid GC), and extra overhead, and--

Past the trivial client-side examples and synchronous callback 
hell, you start caring about the actual concurrent architecture 
of your program, but you no longer have any control to architect 
anything with. That's my limited experience, anyway. If you know 
of a good salespitch, "Erlang devs! Stop letting mailboxes hold 
you back! Join the new order!", I'll watch it.

Meanwhile:

https://code.dlang.org/packages/dawait

That's using core.thread.fiber directly, but by removing that you 
could make it compatible with a simple `import 
vibe.core.concurrency;` and then 
`setConcurrencyPrimitive(ConcurrencyPrimitive.workerTask);` to 
use vibe-core's fiber scheduler.

russhy <russhy gmail.com> writes:

On Friday, 24 September 2021 at 06:00:30 UTC, jfondren wrote:
 On Friday, 24 September 2021 at 03:16:36 UTC, zoujiaqing wrote:
 Swift 5.5 including async/await.

 TypeScript support it.
 Kotlin support it.

 And Nim, and Rust, and Zig. I think of it as a lot like garbage 
 collection:

 1. deadlocks (memory errors) are too hard to deal with! Why 
 can't software handle this instead of us poor programmers?

 2. async funcs (GC-using functions) are cleaner and easier to 
 write. Don't mind the invisible extra work.

 3. huh, this new cure-all comes with surprising downsides like 
 'colored functions' (GC-assuming APIs) that are annoying to 
 expose to the C ABI, and that want other functions to share 
 their 'color' (also use/avoid GC), and extra overhead, and--

 Past the trivial client-side examples and synchronous callback 
 hell, you start caring about the actual concurrent architecture 
 of your program, but you no longer have any control to 
 architect anything with. That's my limited experience, anyway. 
 If you know of a good salespitch, "Erlang devs! Stop letting 
 mailboxes hold you back! Join the new order!", I'll watch it.

 Meanwhile:

 https://code.dlang.org/packages/dawait

 That's using core.thread.fiber directly, but by removing that 
 you could make it compatible with a simple `import 
 vibe.core.concurrency;` and then 
 `setConcurrencyPrimitive(ConcurrencyPrimitive.workerTask);` to 
 use vibe-core's fiber scheduler.

adding vibe as dependency = make your project much much slower to 
compile

dependencies are bad by design, you don't want to depend on 3rd 
party, you want use language to empower your project

dependencies should serve to play nice with services, for ex: 
postgresql driver, gpu abstraction, aws api etc etc

if people define language constructs as "dependencies", consuming 
them feels bad, because there will not be a common denominator 
between "dependencies"

you'll end up like Rust, where certain io operation will require 
different paradigms because it is implemented as crate

then you have crates that depends on crates that depends on 
crates etc

you end up watching crates downloads for 5 minutes when you want 
to "try the language"

same story for typescript and NPM, even though they have async 
support already, other aspects are affected


Go doesn't have this problem, because goroutine is a language 
feature


One must watch other languages and learn from their successes and 
avoid mistakes of others


If your language can't do X, ask why it can't, if it could be 
doable with language, and then, and only then you can start to 
workaround the problem by consuming a dependency, but even then, 
one must always remember that it'll feel bad to depend on a 
dependency

jfondren <julian.fondren gmail.com> writes:

On Friday, 24 September 2021 at 12:53:40 UTC, russhy wrote:
 adding vibe as dependency = make your project much much slower 
 to compile

...
 If your language can't do X, ask why it can't,

The X that I'd like is faster compilation of vibe and std.regex 
and such :)

VibedScheduler is just a much better fiber scheduler than the 
deliberate placeholder implementation in Phobos. There's still 
language support, with `shared`, `immutable`, thread-local 
storage, etc. I keep looking for this information in the spec but 
https://tour.dlang.org/ shows it off in the Multithreading 
drop-down.

Paul Backus <snarwin gmail.com> writes:

On Friday, 24 September 2021 at 12:53:40 UTC, russhy wrote:
 if people define language constructs as "dependencies", 
 consuming them feels bad, because there will not be a common 
 denominator between "dependencies"

It seems like this problem (dependencies leading to ecosystem 
fragmentation) could be solved by a good standard library module, 
without necessarily requiring a new language construct.

SealabJaster <sealabjaster gmail.com> writes:

On Friday, 24 September 2021 at 15:30:19 UTC, Paul Backus wrote:
 ...

Let's call it `std.experimental.xxx` where for some reason it 
goes there only to die.

Tobias Pankrath <tobias pankrath.net> writes:

On Friday, 24 September 2021 at 03:16:36 UTC, zoujiaqing wrote:
 Swift 5.5 including async/await.

 TypeScript support it.
 Kotlin support it.


compiler can automatically rewrite your code to state machines 
async becomes a runtime feature.

That rewriting (ala C++ coroutines?) is the useful/enabling thing 
I'd see usefull for D. Would wonderfully interop with ranges as 
well.