Why not including async/await ?
russhy
russhy at gmail.com
Fri Sep 24 12:53:40 UTC 2021
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.
>> C# Support it.
>> 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
More information about the Digitalmars-d
mailing list