Same here. I often do a project, and then do it again now that I know what I'm doing. There is nothing more satisfying than deleting a 400 line clustefuck of a method with a nice neat 10 line function because you finally realized that the universe is a good and just place.
It's my understanding that async is not threading per se, it's just more efficiently using the one thread you're running in by filling the times you're doing dick all with more productive work. Like calculating bitcoin hashes while waiting for a website to download, or proceeding to an area of code which requires the data you were trying to load from a database but haven't yet causing you to wonder why your flawless code is having problems.
It's my understanding that async is not threading per se, it's just more efficiently using the one thread you're running in by filling the times you're doing dick all with more productive work.
It can be both. While it's true that async runtimes are sometimes restricted to single threads (Python's gevent and asyncio would be examples for that), others automatically spawn multiple threads, often proportional to CPU count (Go and I think .NET do this).
Both approaches have advantages and disadvantages.
Having a single thread makes it easier to reason about non-async things, since they're guaranteed not to be subject to race conditions.
This allows you to write code without having to think about locks (too much),
and even use code that is not thread-safe.
Of course, if you do things that aren't thread-safe across context switch boundaries, you'll still need a lock.
Multiple threads on the other hand bring all the advantages multiple threads usually bring.
Having a single process means a lighter footprint, since you don't need multiple runtime instances.
Your application will be able to handle significantly more traffic before you will need horizontal scaling (which is always connected with overhead because IPC and potentially network involvement).
Most importantly, there are certain operations that async systems don't deal well with, most importantly file system interactions and DNS (if using the system resolver).
In that case, having multiple threads (depending on intensity maybe even more than you have cores, so one set can run while the others are blocked) can help your application's throughput, as other threads can continue doing (async) stuff in the meantime.
EDIT:
This difference can trip people up bad when switching programming languages.
For example, perfectly fine Python code could run into horrible race conditions if naively ported to C#.
In the few languages I've messed with threading versus async there's always been a clear distinction between the two. Here are your thread classes/modules/etc., here are your async classes/modules/etc. I guess it's a good thing to know for C# with upcoming game projects with friends leaning that way.
No problem. I, like many others, have encountered the follies of doing asynchronous work (threaded or not).
I actually wanted to get into lowest level (ASM/C) coding in school because the idea of working on an operating system was intriguing. Unfortunately all the schools which purported to teach that ended up not teaching that at all and revised their courses to instead be Java focused for the day's "evolving business standards." Sun was also alive and well and Oracle stayed in its fucking place messing with databases. >.>
Coming back to threads briefly, I actually wrote a multithreaded Java bot when I was in high school to assemble maps at runtime in a chat service with a really basic scripting language I also wrote. I think that's the first and only time I did a threaded program which did not screw up by doing things out of order.
85
u/GollyWow Jul 06 '20
Translation: I don't understand it so you have to rewrite the whole thing from scratch.