Just trying to cut through biased bullshit benchmarks, and walls of Reddit nonsense here:Are Goroutines lighter than using asynchronous C++ in a framework like Drogon or not?I don't want to start committing to an entire new language or particular framework just to find out way down the road that it was the inferior choice.
Maybe.
C++ coroutines are allocating dogshit unfit for any use. Worthless misfeature. Unironically they should have copied Rust's async/await which is actually lightweight.
>>102137825What do you even _mean_ by lighter? Almost all programming languages can spawn OS threads, they're quite sufficient for workloads that aren't heavily concurrent. Some of them can _only_ do OS threads, like C# or Rust. You thus have N:N threads-- for every N amount of threads available, you can spawn N threads.Languages which have a runtime AND have implemented green threads can spawn much, much more threads, (all JVM languages, all Erlang languages, Go) 2because they're managed by the runtime. When a green thread is pinned (blocking in general) the OS thread moves to another green thread to do that work. This gives them a distinct advantage for heavy concurrent workloads like web servers where your threads can take like 25 ns to handle the response (useful work) and 75ms waiting for one (wasted work, thread pinned) so the real OS thread can do more work while the green thread is blocked
>>102137918C++ already copied Rust's async/await by not having a working implementation for it.
>>102138324kek
>>102138036You are wrong about JVM. JVM Threads are OS threads they are not green threads. Only with JVM 21 it got green threads (so called virtual threads) and you have to specifically configure a thread to be one, the default when creating threads is still OS threads.
>>102138036Well supposedly a single OS thread is a lot more RAM than a "green thread" spawned by Go. Supposedly, by using Go, you get concurrency for a lot less RAM and a higher performance application also.
>>102138324well, you are not wrong
>>102138324Rust async / await works fine and is conceptually simple retard.
>>102138687hell yeah we ACKin 2nite
>>102138393Even before Loom, Java jeets had other tools to provide concurrency such as the proliferation of observer patterns in a lot of code and stuff like vert.xGreen threads aren't the only way to concurrently execute on a thread and in fact is probably the worst way of doing it unless you're a lazy jeet who can't code.
>>102138477It comes down to stackful vs stackless coroutines. There are pros and cons. Go uses stackful coroutines, which has the main benefit of not requiring async/await keywords.
The lighter the routine, the less things that can go wrong
Speaking of memory leaks, I have quite a weird one I have yet to identify>re-did a fresh win 10 install>installed one program at a time>waited hours for each to see if it happens>doesn't happen even after installing everything>a week or so later>the leak starts happening againIt's driving me crazy at this point. And the weirdest of all is that every single exe and dll that runs on the system starts leaking leaving the "unused" part accumulate until it crashes making it hard to know what's causing it.
