How do you guys even do asynchronous code in your programming language? It seems like everyone is copying C#'s method of doing it and even then it's not as good and easy as C#'s way. Why is everyone copying and still playing catch up?
 |
 It's All Fucked Shirt $22.14 |
|
>copying C#'s method of doing it
lol
lmao
rofl
Using async/await is the simplest thing of the world. Make you write your code as if it was synchronous. What is this moronic question?
Not every language has it, and those that do, aren't as simple and efficient as C#'s async await.
>Using async/await is the simplest thing of the world.
Some languages have even easier options that let you get all the benefits without having to scatter async/await all over.
The trade-off is that they need more explicit context management; in particular, you need to say where the outer boundary of the yieldable context is. That's more overhead in the most trivial cases, and less when things get more complicated.
(The totally other approach is rewriting everything in continuation passing form with lots of little callbacks. That's much harder; let the compiler do that shit for you!)
>Some languages have even easier options
>Proceeds to explain something more complicated
Nah ill stick with async/await thanks.
>Some languages have even easier options
>The trade-off is that they need more explicit context management
it can't be easier if it requires more context management.
Callbacks existed for decades. But I agree, async/await (or similar concept) is way better than fricking callbacks. The error handling alone in nested callback is nightmare. By the way, can you switch threads with async/await in C#? Probably you can, but if for some reason you can't then it's pretty bad. In Kotlin (which I use) you can easily switch from one thread to another and then back to the caller thread in suspend functions (aka red/blue functions).
>can you switch threads with async/await in C#?
kind of
awaiting an async method will switch from background thread to the caller thread, which can be optionally disabled
also all async methods run synchronously until they hit await, you can forcefully create another thread by using Task.Run()
Read about async/await synchronization contexts.
lame, come back when you have zero cost async/await like Rust.
Rust is truly the greatest programming language of our generation.
No nighly required. Rust stabilized zero cost async/await 2 years ago.
Microsoyboys on suicide watch right now.
C# did it in 2011. Rust is about 9 years late to the party and is still copying C#.
uh oh, C# still can't copy Rust's zero-cost async await.
Keep up, boomer
What does zero cost mean in this case?
just says that it's a wrapper around an existing structure in Rust, but that structure still has a cost.
Noooo nothing in Rust has a cost you bigoted racist hater!
What cost?
I don't know, that's why I'm asking what they mean by zero cost. Doing something asynchronously requires some kind of context switching to go back to the caller without losing the state of the function. If they are saying there is zero cost compared to using the existing Future implementation then that's useful for Rust devs to know but it doesn't really compare it to other language's implementations of the same concept in terms of cost.
Can you produce the asm for the similar snippet in
?
For C# the output does include all the state machine boilerplate - https://godbolt.org/z/Tjsjzj8x5
However, if you look at the rust snippet the compiler just figured out that all the async stuff was unneeded and the function has a static return value of 9,. What would a Rust example do with something like this:
using System;
using System.Diagnostics;
using System.Threading.Tasks;
namespace Test
{
internal class Program
{
static async Task func()
{
int i = 0;
Random random = new Random();
Action task = () => { lock (random) { i += random.Next(); } };
Stopwatch watch = new Stopwatch();
watch.Start();
for(int j = 0; j < 10; j++)
{
await Task.WhenAll(Task.Run(task), Task.Run(task));
}
watch.Stop();
Console.WriteLine(watch.Elapsed);
}
static void Main(string[] args)
{
for (int i = 0; i < 5; ++i)
{
func().Wait();
}
}
}
}
I'm actually wondering if the Rust compiler would pick up on being able to inline the async calls because of the lock, C# doesn't seem to:
https://godbolt.org/z/97rzvzTcb
>What does zero cost mean in this case?
In that case, it means that the compiler turned a bullshit simple example into a constant. I'm not sure how useful that would be in the real world; most async code isn't going to be just producing a constant.
>In that case, it means that the compiler turned a bullshit simple example into a constant.
Can C# compiler do the same? No?
lmao seething
>Can C# compiler do the same? No?
I have literally no idea; I don't touch that shit. I just don't think it is a very valuable optimization. It's a show-off for benchmark purposes, but won't help any real code.
Zero cost means you don't pay for it if you don't use it.
Async in go for instance isn't zero cost because it requires a run time to always be active for managing threads. It also has variable stack sizes (or did when I last checked) so it needs to insert checks to allocate more stack space even in synchronous functions.
In the rust version, the only source of overhead for an async function is at the point of the async/await in the code. All other code will execute as it normally would.
Zero-cost isn't actually about something being fast to call, it just means that it will be fast to not call. It's just a part of the huge set of buzzwords that rust users pathologically plaster everywhere, like safety or blazing fast.
When did rust get so based, bros? I thought it was supposed to suck
it never did.
never sucked*
sorry i just realized the ambiguity
unreadable garbage
>unsafe {
kek
every time
>i-is that an unsafe block
>Unsafe
Doesn't that basically mean you breaking rust rules and doing C/C++ stuff?
C/++ does bot have any async await.
yes it does - the standard library support in C++20 is shit though. Hopefully proper library support will arrive in C++23.
Using a third party library you can do stuff like: https://github.com/netcan/asyncio
similar to python's asyncio
>Yes it does just wait for c++ gorillion lmao
Rust has it now, not 15 years down the line cnile
>yes it does, just not really
cool
No, it does not mean that.
All unsafe does is allows you to:
- Dereference a raw pointer
- Call an unsafe function or method
- Access or modify a mutable static variable
- Implement an unsafe trait
- Access fields of unions
Good luck chaining multiple tasks and error handling them with that method.
The `?` operator does that for you.
Rust is the most powerful programming language.
?
error handling is literally just a '?'
chaining you can either bind them to a variable (the second line handles errors)
let someAsyncReturn = asyncOp().await;
let someOtherAsyncReturn = asyncOp2(someAsyncResult).await?;
or if the types have some async methods
let someAsyncChainResult = asyncOp.await.thenDoSomething().await.thenSomethingElse().await
>suspended
what? i thought the whole point was that it runs in the background?
Then it wouldn't be zero-cost.
I guess the idea is that you can manually pass the future to another thread which awaits it. C++ did the same thing with std::launch::deferred.
The foreground is suspended while something happens in the background.
Pretty good bait, fren
>syntactic sugar
frick this gay shit. if assembly language was invented today these gays would call it syntactic sugar
This is cheaper in zig. In zig you can also make the async stack size the same as the function stack size so "green threads" in zig are smaller than even go, so zig is better for writing servers than rust and go if you care about handling many clients concurrently
Async/await model is outdated and overrhyped. Look at Kotlin/Go coroutines
Goroutines are not coroutines and Go inserts stealth yields back to the scheduler into function calls. It's a good way to make sync code async without any effort but it does make your unpredictable
I never minded the concurrency system in Go, using C# most of the time currently and I don't think the async/await automatic state machine building is all that amazing. It's quite productive though.
I've looked at co_await / co_yield type stuff in C++ and it does not look enjoyable to use without the language support you get in c#.
what's wrong with promises
Real languages have these things called "threads", you'll learn about it when you grow up
real languages implement their own threading abstractions though, boomer.
Real languages don't need a thousand moronic abstractions on top of basic features because they're used by real programmers.
>How Do People Deal Without Async/Await?
>How do you guys even do asynchronous code in your programming language?
I'm not a dev, though I can program. I've never needed or used async/await in my life. see
Async/Await and starting new threads are two completely different things. It's moronic and useless to start a new thread for an i/o request to an external service.
>Async/Await and starting new threads are two completely different things
can you explain then, what's the difference between an async "task" and a "thread"? if you say async tasks aren't parallel, then what is even the point?
>if you say async tasks aren't parallel
async tasks are concurrent. They may or may not be parallel depending on the implementation.
>what is even the point?
Spinning up an OS thread takes a significant amount of processing and memory compared to an async task. You can have far more async tasks running concurrently than you can have threads.
Async tasks aren't a concretely defined thing. Every language has its own implementation.
JS comes with a hidden event loop that starts the next task whenever previous one returns/awaits.
C# comes with a thread pool managed by the language runtime.
From what I understand, when using old fashioned threading, management of parallelization (switching thread) is mostly pushed down to the OS, which is costly. When using async-await / Task / async or mailbox in F#, management (switching task or async) is done mostly in the Framework/App, which is not costly.
Look up how IO and interrupts work. Also look up thread pools. You may want to also look up thread local storage and task local storage.
Yeah, C# had those a long time ago too, still does. Task.Run() and a new thread is spinned off.
Does C# not have actual threads?
use std::thread;
let thread_join_handle = thread::spawn(move || {
// some work here
});
// some work here
let res = thread_join_handle.join();
>Does C# not have actual threads?
Don't be stupid, of course it does have it since 2003.
futures
stackfull coroutines
etc... none of this is really new.
Async/await is literally the worst async model there is. Anyone with a brain uses the reactive model.
(OP)
>Async/await model is outdated and overrhyped. Look at Kotlin/Go coroutines
>Async/await is literally the worst async model there is. Anyone with a brain uses the reactive model.
You two shitheads have never done this before. I'm just waiting for you to push Python. Go on, do it. I'm not going to look at Kotlin/Go because nobody gives a literal frick about Kotlin/Go. Go and Swift are the two worst pieces of israeli cope I have ever seen.
>By the way, can you switch threads with async/await in C#? Probably you can, but if for some reason you can't then it's pretty bad.
Being able to switch threads is the number one productive use of C# async/await and was in the very first examples in 2011 but you have to know how to ref-count threads properly if you want to return to the starting context or else you can never let the threads terminate. There's a perfect pattern to this and no framework gets it right because the little boys and girls who "love tech" and flood the industry can't think three-dimensionally. See the quoted comments up top.
But one small app team who understands it can scale so hard and fast they'd conquer wide swaths of the software industry like only a central bank could. C# nailed it. The only reason other languages have async/await is because Microsoft evangelized it.
>Async/await is just stackful coroutines but shit.
>Why would I use them when I could just use stackful coroutines but not shit
They are stackless routines and the call frames are stored in the heap. If threads were absolutely free, they would still be worse than async/await, impossible to compose with any real complexity, and prone to deadlocks.
>I've looked at co_await / co_yield type stuff in C++ and it does not look enjoyable to use without the language support you get in c#.
There are a lot of tiny heap allocations to keep track of when doing an await transition, and having to manage them without a GC is a nightmare.
>Microsoft shill is back
What's up. Are you going to ban me again, exposed Microshill? KEK https://desuarchive.org/g/thread/87318479/#87319317
Also top kek
>because nobody gives a literal frick about Kotlin/Go.
Both languages have a better ecosystem than your dead shill forced .NET scam kek
Guys. Whenever you see someone defending Microsoft/.NET with a shitload of reddit spacing, you know it's him.
Go back to /x/ and take your meds. Is this Microsoft shill in the room with you right now? Can you point where he's standing?
>t. microsoft shill
>They are stackless routines and the call frames are stored in the heap.
So you're saying async/await is just stackless coroutines but shit?
My point stands, why would I use them when I could just use stackful coroutines but not shit?
In fact, my point stands even moreso, because why the frick would I use even a *good* implementation of stackless coroutines, when I could use even a *bad* implementation of stackful coroutines instead.
Because stackful is not "zero cost." And comes with some real FFI challenges.
>They are stackless routines and the call frames are stored in the heap.
You're keeping a linked list of call frames when you do async/await. That's a stack, even if not *the* stack.
(The principles of async/await aren't too bad, but the pretending it is stackless is disingenuous. It only gets close to stackless in the most trivial cases.)
Async/await is just stackful coroutines but shit.
Why would I use them when I could just use stackful coroutines but not shit
C++. At work we have a handwritten thing using pthreads. Everything via callbacks. A bunch of threads wait on assigned events. Most importantly "on message" event to decode udp messages. Some threads are pinned to CPUs because want low latency. Honestly idk how it works, and it's a huge shit since every object is derived from "has a callback" class, and we use raw ptrs and destruction is fricked, delete gets called in another thread so object has a chance to finish processing events in the queue, but often people either just let memory leak or crash at end of program.
i slam async in front of my javascript when it's not working. then it works. and i move on. not really sure how it works, but it does. i'm not a webdev guy but my boss asked me to do some.
Absolutely based
It's like threads without locks and sleep, but single threaded and the language runtime does the scheduling
async/await c#
what?
I've never used async/await in c# i thought that was a javascript thing. I just used threads and eventqueues
this is how my c# solution wound up looking
public async static Task<string> getMeme(string meme)
{
string memeFile = Path.GetFileName(meme);
if (! File.Exists(memeFile))
{
Console.WriteLine(String.Format("getting {0}", memeFile));
await getIt(meme);
} else {
Console.WriteLine(String.Format("found {0}", memeFile));
}
return memeFile;
}
private static async Task getIt(string meme)
{
string memeFile = Path.GetFileName(meme);
var client = new HttpClient();
using var response = await client.GetAsync(meme).ConfigureAwait(false);
using var responseStream = await response.Content.ReadAsStreamAsync();
using var fileStream = File.Create(memeFile);
await responseStream.CopyToAsync(fileStream);
}
That looks kinda comfy tbh and I'm not even a OOP. I might just have to try out C#.
C# and .net are great, all hate derives from its origin at Microsoft. If you really want to blow your mind, start using PowerShell - you’ll hate it at first but give it time
Javascript didn't get async await until ES7 in 2016 which it lifted from C#.
The first real implementation of the asynchronous programming paradigm was in F# actually. C# only introduced the async/await keyword, quickly followed by Haskell.
Haskell introduced it in 2012. C# did it in 2011.
That's what i said, learn to read homosexual.
>1- F# introduces the 1st implementation of the asynchronous programming paradogm
>2- C# takes the feature and improves on it by creating async/await
>3- Shortly followed by Haskell.
Yes
i didn't realize ms was also paying for content here
await asyncFunction().then().then().then().then().then().then().then().then().then().then().then().then().then().then().then().then().then().then().then().then().then().then().then().then().then().then().then().then().then().then().then().then().then().then().then().then().then().then().then().then().then().then().then().then().then().then().then().then().then().then().then().then().then().then().then().then().then().then().then().then().then().then().then().then().then().then().then().then().then().then().then().then().then().then().then().then().then().then().then().then().then().then().then().then().then().then().then().then().then().then().then().then().then().then().then().then().then().then().then().then().then().then().then().then().then().then().then().then().then().then().then().then().then().then().then().then().then().then().then().then().then().then().then().then().then().then().then().then().then().then((res)=>{console.log(res)})
And then()?
just use loop and poll
what's this influx of MS shill threads?
Wow, seeing these two threads made me realize C# is actually pretty based.
yep. so based that microsoft feels the need to pay people to post multiple threads about it in this board.
>Microsoft paying people to point out how much other languages lack features
Yeah, okay buddy.
Eric, is that you?
If you actually really believe what you just said (that a multi Billion dollar corporation paid people to go to IQfy of all place) then your place is in /misc/ or /x/.
pretty sure I've read this exact same posts before, maybe just similar.
anyway...
yes: corporations do pay people to post on social media and internet forums, no mater how shady they are. see: reddit.com, where subreddit mods have made bank shilling for companies, at least until they were found out.
>t.miguel de icaza
What is it with your morons railing against .net/c# just because it was developed by Microsoft? .net is cross platform and open sourced.
If people realized how many feature and speed C# has while doing it, other programming languages would die because of how far behind they are.
It’s really interesting how this place hates c#/.net when it’s clear most have never given it a shot. BUT OH YES PYTHON IS GOAT. Oh and all the discussions about how superior functional programming is best programming but let’s ignore how c# is probably the most functional programming compatible imperative language out there
.NET is absolute garbage, ESPECIALLY identity. I'd rather get cartel flayed than having to work with that shit again.
Identity is the easiest thing on earth.
Not starting consuming OS threads when you need to wait for a response that comes from outside of your Application instead of starting thousands of very consuming OS threads that do absolutely no computation. They just wait for the DB to serve them with a response.
Meant for:
That doesn't matter. They're so deep in their tribal mentality that MS could invent a cure for cancer and FTL travel tomorrow, and they'd find a way to shit on it.
It's just what these "people" do. It's why they're unemployed, and live in their mom's basements, desperately trying to keep their Sandy Bridge shitpoststations alive with parts they dig up at the city dump.
I've tried it, not worth the lack of standardized implementation like java and the jvm has
This
I'm starting to believe in shill threads.
Starting to? Everything in this fricking board is either a shill thread or a schizo thread. There is no in between.
Nooo! People are realizing how based C# is! I can't believe my language doesn't have Async/Await and LINQ. Why are they not in every programming language?
>do you guys even do asynchronous code in your programming language
>All that convoluted shit in picrelated
Lmao, imagine needing more than 4-5 lines of code for basic shit like this
suspend fun concurrentSum(): Int = coroutineScope {
val one = async { doSomethingUsefulOne() }
val two = async { doSomethingUsefulTwo() }
one.await() + two.await()
}
You can use that style in C# if you want, the problem is just when you want to call another async method inside of yours and then do something with its result before returning a result to your caller.
public async Task func(){
await Task.WhenAll(
Task.Run(doSomethingUsefulOne),
Task.Run(doSomethingUsefulTwo)
);
}
>the problem is just when you want to call another async method inside of yours and then do something with its result before returning a result to your caller.
Lmao
awaitAll(async {
awaitAcknowledge()
}, async {
sendData()
})
Again, you can do it this way if you want to put all your operative code in separate functions:
public Task<Result> MyTask -=> Task.Run(awaitAcknowledge).ContinueWith(task => sendData())
The actual function doesn't really need to be async at this point since you're not awaiting anything, the caller would be doing that. What I'm saying await is useful for is something like this:
public async Task<SendDataResult> func(){
var ack = await acknowledgeAsync();
if(ack.isSuccess){
return await sendData(ack.client);
}
else{
return new SendDataResult();
}
}
That looks comfy.
This doesn’t need async/await, just return the Task.WhenAll result
Looking again at what the other guy did I guess what it actually should have been was this:
public async Task<int> func(){
Task<int> a = Task.Run(doSomethingUsefulOne),
b = Task.Run(doSomethingUsefulTwo);
return (await a) + (await b);
}
I think you need the parenthesis around await which is awkward.
suspend fun is right, where's the fun in that ugly syntax?
It's a Google language that is used inside an Oracle product/vm. What did you expect?
>It's a Google language
Holy frick what a brain let take. It's literally made by based Slavs who had to deal with shitty java on a daily basis, so they made a gigacomfy alternative.
>made by hohols and mongol rapebabies
Imagine my surprise
In my limited experience it sucks and its the sole reason not to use nodejs as a backend.
In my non limited experience, it isn't async that sucks in and of itself but node.js that does and its entire way if handling asynchronous programming. In C# it consists of adding two moronic keywords in their appropriate field. How much more dumbed down and abstracted away do you need it to be?
I read you don't even have to do async if you use multiple threads. Ideally I'd want to use something that doesn't require promises its just terrible.
If you just need to push lots of items through a pipeline independently, then you don't need async. Just make a threadsafe queue and have worker threads consume it.
Async and other tools are for when threads really need to communicate with each other (usually involves a GUI that you mustn't block).
Say you get 1000 concurrent requests. You will have to create 1000 different threads for that which is a noticeably consuming performance hit since you consumes OS threads. But the data you will does not require work on your application. It will be queried in a database. So you created 1000 threads for nothing. You should not create new threads for external i/o calls which is something like 70 to 80% of what a web server is all about.
shit I don't know. I just used async to make a javascript multiplayer game and I had to drop it cause it was getting hellish. I'd just do complete guesswork and put async next to functions and await next to variables until I got the thing to work.
In my semi limited experience, node is fine and you can stop being such a Black person about it
You will have to use asynchronous programming anyways unless you want to create 1000 threads each time you get 1000 concurrent requests. All for nothing since nothing is being processed on your application. The response comes from an external source (your database). The only case where you should use multithreading is CPU bound work.
>The only case where you should use multithreading is CPU bound work.
You should measure on your target system and tune the async/thread balance to get the best overall performance.
By programming in a language that doesn't run on top of a single threaded event loop.
Multithreading is not an alternative to async.
superior languages like go and java are using virtual threads. maybe cshard will catch up in a decade
In fact Rust and C#'s implementations of async/await are completely compatible with parrallelism. A combination of async/await with yield.
Goroutines equate to a combination of async/await tasks with yield in C#.
you mean you don't need to do async await at all?
ACTOR MODEL, Black person
Async/Await is moronic shit that is a workaround for moronic languages that are singlethreaded.
The point of async is not about making single threaded languages work moron. It's about not having to start consuming OS threads when all you do is literally wait for data to be processed and set in another application (the created OS thread would just be created to wait). Or, alternative, it's used for UIs.
>The point of async is not about making single threaded languages work moron. It's about not having to start consuming OS threads when all you do is literally wait for data to be processed and set in another application (the created OS thread would just be created to wait). Or, alternative, it's used for UIs.
> calling others moronic because too primitive to understand the other guys' point
He's clearly referring to dumb idea that most coooders have nowadays of, "why yes i can do everything in a single thread, if i have a native library spawn a frick ton of threads arbitrarily, because lol." Abused as an io model in everything from glibc posix io to node.
>He's clearly referring to
He said what he was referring to, and it's not what you seem to have decided it was. Maybe learn English before you try giving instruction on code.
>you try giving instruction on code.
> conflating IO and scheduling with code
> still can't see the connection between OP
complaining about "single-threaded languages" and the point preceding "Abused as an io model in [...] node"
It’s about making the code easier to write and follow using a synchronous coding format. It’s syntactical sugar.
M O N A D S
O
N
A
D
S
gevent
based and monkeypilled
>It seems like everyone is copying C#'s method of doing it
Imagine having your head so far up your own butthole to think that's true. Can you see your tonsils yet?
Cfarts
Ass poo.NEET Coom
>.neet
Would be funny but it’s really the exact opposite, tons of great paying .net jobs out there. It’s widely used in the enterprise space
microshit shills are real
>mfw
Why would Microsoft need to shill .net when it’s fully implemented for Linux? How does Microsoft make money from you writing .net applications?
>Why would Microsoft need to shill .net when it’s fully implemented for Linux?
not that anon, but, who the frick is even talking about linux? what the frick does one thing has to do with the other?
this.
Read the rest of the post, moron. The accusation is pro-.net/c# posters are Microsoft shills. The question is how does Microsoft financially benefit by pushing c#/.net when they can be used on non-Microsoft platforms that make no money from Microsoft (thus no benefit to shilling it)
>The question is how does Microsoft financially benefit by pushing c#/.net when they can be used on non-Microsoft platforms
there is no such question, you made it up in your mind. moron.
Dude. I like c# too. But you're pushing it a bit too for don't you think? You really do sound like someone who's trying who force things (a shill).
I’m not OP or many of the other posters. Anons advocate for many languages in this cesspool yet only c# advocates get called shills. I’m perfectly fine with using a less popular stack and lang here
>I like language/stack
>therefore i HAVE to defend it on anonymous internet forums!
hmm, yeah...
No one has to post anything here you disingenuous twat. Why does anyone post about python? Why aren’t they called shills
>Why aren’t they called shills
Who would pay them?
Python has so much marketshare that anti-python shills are infinitely more likely.
Meanwhile, m$ shilling is well-documented. At least now you m$ shills don't even try to mention azure in your shill threads.
Honestly if you aren't using go, an erlang, or python with gevent, you're probably making your life unnecessarily hard. go sucks but m:n multiplex and lang level concurrency is legit
replying to myself but I'll just add in my experience a pool of 4-8 threads can handle just about everything I've ever needed.
This thread is cargo cult
Dotnet is the new Apple (the Apple of the 1980s and 2000s. People who use it behave like a sect who try to get you into the group by all means.
>How do you guys even do asynchronous code in your programming language?
By writing as you normally would. Clojure was built with concurrency and asynchronous programming in mind.
>and even then it's not as good and easy as C#'s way
JS is actually better, though.
Not even close. It's objectively inferior on all measurable aspects.
Such as?
Seeing all these replies made me realize how advanced C# is and how outdated and far behind all the other languages being shilled here really are.
You really need to improve your larping skills. You're not there yet
I thought Python and Javascript were the god languages until I realized they don't even have async/await and linq and simple stuff like that.
>Javascript
>don't even have async/await
It doesn't have linq either.
...
t picrel
>Async
Backrooms Amogus Sus
SUS
huh
>he dozen know Kane Pixels
When I need to wait for something I spin up a a thread with a infinite loop checking whatever I need.
so whats the big deal with async/await and running the same code in another thread IN Java ?? is it a performance gain using async?
It's so weird seeing all the traction rust gets on IQfy. Nobody in my company has ever heard of it, let alone would be willing to implement any kind of project with it.
How many people in your company heard of gentoo/arch and would be willing to use it?
We already do.
how does it compare to signal and slots? Pretty sure signals are easier to implement.
what is the point of async i dont get it
to confuse you by pretending that your async code is synchronous, and to give the opportunity to morons to only implement async version of methods that you want to use in synchronous code
Thread = CreateThread(&Function);
WaitForSingleObject(Thread);
No free functions allowed.