https://youtu.be/x3hOiOcbgeA?t=3650
Thoughts? It's very different from the previous idea, the new idea is that async should be a standard library feature instead.

Async shouldn't exist at all.

>>105849716
He literally says you can pick an implementation based on threads and blocking IO

>>105849746
I choose implementation where asyncslop doesn't waste my time.

>>105849685 (OP)
Here's the example usage
https://gist.github.com/andrewrk/1ad9d705ce6046fca76b4cb1220b3c53

i do not like async

why should i be for or against async

>>105849805
>@"async"
>@"await"
what is this shit? macros?

>>105849805
I hope that syntax is temporary

>>105849974
>>105849896
That's because currently async and await are language keywords, but they're going to be removed, so in the future it's going to be just io.async()

>>105850183
Already done
https://github.com/ziglang/zig/pull/24362

>>105849685 (OP)
Zig is like a testing playground for shit that should be put into C99

>>105849685 (OP)
>that async should be a standard library feature
lol, ziggers are gonna be cursed by this transitively infecting everything or they'll have to NIH their own standard libs

>>105850333
why is that

>>105849746
took them long enough
video games already solved this crap, they always have separate dedicated threads for IO, audio and other important stuff
making IO interface similar to the Allocator API was a good idea, now you can just switch implementation and have whatever behavior you want

>>105850289
>>105851416
Already solved years ago with
#pragma omp parallel

In pro-grade/supercomputing/computer science

>>105850333
Just like C-shart :(

Drew looks unhinged. Did he start HRT?

>>105849685 (OP)
>Zig
Nig

>>105854074
He is going Rust mode

>>105850744
if anything interacts with an async function, it has to become async too.
Just ask rustoids how their async is going

i can't believe language designers still keep falling into the async trap

a promise is just a buffered channel with capacity for 1 item
i repeat: a promise is just a buffered channel with capacity for 1 item
to reiterate: a promise is just a buffered channel with capacity for 1 item

>>105849685 (OP)
>"async"
>look inside
>multithreading
why is this so common? C# too has multiple ways to do async and half of them are just multithreading in a trenchcoat
It's fine to not know what concurrency is, just don't implement it on your flawed understanding

>>105855934
language designers do this silly thing where they refuse to look at any history or prior research on important CS topics and instead just copy existing langs that also practice this.
so it's one big chain of blind languages leading eachother in circles

>>105849685 (OP)

>>105849685 (OP)
You zigged, when you should have Rusted. Thanks, but I'm sticking with Rust.

>>105849685 (OP)
Real zig has never been tried

>>105856086
zig is basically a snowflake C with some QoL, C programmers do this every day with their elaborate macro and header library ecosystems

>>105855984
Well, everyone has to start somewhere.

>>105855897
In the context of other languages, what's the alternative? Don't suggest stackful coroutine nonsense (e.g. goroutines), we don't need that shit

>>105856512
how do you think async is implemented?

>>105856542
In most other languages with stackless coroutines

>>105856548
now explain why you find the presence of a stack offensive

>>105856560
First it typically makes C FFI slower (see cgo). Second it requires some runtime to resize allocated stacks when needed (or use segmented stacks) and to potentially rewrite pointers if you have pointers pointing to a variable in the stack, unless you're planning on spawning every green thread with a large stack and at that point why even use these green threads? Third it's typically not even as flexible for custom usage as async is, i.e. I have a WebAssembly module running in an environment where the host exports an io_uring inspired API to perform asynchronous operations and you can make this API work with, for example, Rust's async/await by implementing a Future that submits ops and implementing a task scheduler that also occasionally polls the completion queue and wakes up tasks that are waiting on an operation. And that's exactly what I did and now you can have cooperative multitasking in a threadless Wasm environment, with every op being an async function that just submits an op using the host API, then suspends itself so that other tasks can run, then the task scheduler will put the task back into the run queue when an completion queue entry arrives with the result of the operation. You can't do that with goroutines as easily at all

>>105856662
yeah you can

>>105856701
How? You can't really put the CQ poller in a goroutine and run runtime.Gosched after each poll in a loop because once there are no goroutines to run except that one, the Go runtime will most likely schedule the same goroutine to run immediately after the Gosched call, which will pretty much turn that loop into a busy loop. You can't really use the host API to block until an CQE arrives either because the CQ poll goroutine never actually knows if there are any other goroutines that can run at any point - I suppose one can use some kind of heuristic that if Gosched returned 3 times in a row really quickly, then use the blocking call, otherwise don't, but that feels very fragile

>>105849685 (OP)
Go got it right
looks good

>>105856776
just chill out and use channels, man

>>105856840
What, do you not realize that calling an imported function from the Wasm host environment blocks all goroutines or something? What are you talking about?
>>105856560
So in the end, what do you propose that doesn't rely on stackful coroutines, if not async/await?

>>105856873
>wasm
sneed

>stackful
also sneed

>>105855897
Wrong
A future is a resumable bundle of data + direction where to resume at, that can either return a final value or a "wait more" guard
You can block receiving on a channel and wait for a result but that doesn't execute the sender side, so unless that's done in a different thread, you will block forever.
If your "async" can't run on a single thread it's not async

>>105855897
>gotard doesn't understand his webshitter language for midwits hides returns to sheduler inside of his code to force it into being async
at least JS pajeets are self-aware enough not to try and participate way above the scope of their kiddy lang, gotards see syntax that's vaguely similar to C and start thinking they're low level

>>105856873
he's a gotard
he doesn't understand what you're talking about

>le async bad
nocoders should be shot

Also this implementation is shit. But zig is literally peak midwit in terms of PLT design and goals.

>>105856934
I would have thought all atomics being sequentially consistent ordering was enough to dispell the low level claim of golang. They do be retarded though.

>>105857026
>There are only two kinds of languages: the ones people complain about and the ones nobody uses.

>>105856891
>>105856934
hey i'm just repeating kevlin henney

>>105849685 (OP)
>base your marketing on appealing to midwits
>try to do something slightly sophisticated
>midwits seethe
Lmao, kek. This is what happens when you choose mediocrity over meritocracy.

>>105857350
>async

>>105849685 (OP)
use case?

>>105849685 (OP)
is v1 on any roadmap?

>>105860506
Async is the last big item remaining apparently before v1, but no

>>105861881
at this point we might have a successor to rust, which we don't know about yet, come out before zig becomes stable

>>105861920
zig priorities are very much on the "let's build neat stuff" camp and catering to esoteric devices than actually making the language stable/feature complete for general use
See the ridiculous effort spent on moving away from llvm: sure it's nice and has its benefits, but it wouldnt be necessary at all for the language.

It's similar to nixos where they have a great idea about reproducible builds and got distracted making up their own language

bump68 has downed

>>105849716
>>105849824
low iq morons

>>105857350
daily reminder

For the people who say that they hate async what is a better replacement?

>>105865448
threads

javascript is single threaded, it's understandable that they need extra language feature to deal with blocking IOs.

no such excuses for other languages. why the fuck does C# need async.

>>105857051
the irony of quoting a literal nocoder about language use

>>105865689
Threads require OS

>>105865689
async/await is much faster and scales better than green threads
>>105865736
he's talking about user space threads

>>105865689
>threads
Literal mental retard.
You're the kind of faggot who defends 10k requests per second file serving like we're living in the C10K decade. It's hilarious how bad threads are and yet midwits still think it's good enough. I'm just glad both Windows and Linux agreed that the future of FS IO is io_uring.

>>105855934
what do you think OS multitasking is?

>>105865766
>async/await is much faster and scales better than green threads

What are you building, the next Amazon? Oh wait, they are using Threads, in JAVA!

Async is the wrong abstraction, and that's the end of story. Need I say more? You don't want to become one of those faggots who virtue signals over runtime costs (muh zero overhead abstraction) by torturing themselves with subhuman languages.

>>105849685 (OP)
Async shouldn't even be a feature. Just let me allocate function calls and dispatch as I please.

>>105866171
LLM-using jeet detected

>>105866171
You are an idiot. Stop posting if you have no idea what you are talking about.

>>105855934
C# added async for marketing, because async was the hype at the time, following nodejs' explosive popularity among faggots.

Nobody really fucking needed it or needs it outside javascript.

>>105866224
You shit your whole codebase with async/await everywhere, for what? It's fucking cancer.

>>105849685 (OP)
Buy an ad. No one wants to use your fag memelang.

>>105866068
not multithreading
It's preemptive multitasking, where the hardware itself pauses the execution, saves the context and enters the handler in kernel, which then saves more of the context, loads context of another program, and jumps into it to resume from where it was interrupted (this is called context switching)
unless you're running your webserver as a driver (or rather kernel itself), you don't have access to that, so you need to do cooperative multitasking, where your "units of execution" can detect when they can't continue without waiting and can pause themselves are return to outer scope ("scheduler", not the OS one)
OSes had multitasking before multithreading and hardware preemption, by exposing an API for cooperating to applications, and making them cooperative, issue being that if you encounter a bug in a program that prevents it from returning to OS scheduler, the computer just hangs
>>105866241
>It's fine to not know what concurrency is, just don't implement it on your flawed understanding

>check zig repo out
>CoC, major red flag
>see a video of the creator
>hair dyed bright pink
I'll stick with C, thank you!

It's crazy how /v/ is still too midwitted to appreciate async / await. If you don't understand the problem its trying to solve, why do you even type in these threads?

>>105867970
correct
/v/ is full of college aged children,
they have no idea how computers work

>>105866241
>needs it outside javascript
why is javascript special in this case? are you admitting there are usecases to async?

>>105865766
>he's talking about user space threads
Yeah and async doesn't need user space threads, it can run on bare metal.