For everyone having done multithreading and async programming, it's fairly obvious that the amount of complexity required to (correctly) implement threading and async increases the cognitive requirements to understand the codebase to sometimes unfathomable amounts. Typically, this results in difficult to track down bugs, and over time what we often refer to as "spaghetti code" or "the big ball of mud". To put this into context, I'd like to put forth a statement in regards to this.

Everyone who (falsely) believes they understand threading and async, don't understand threading and async!

Seriously, the above basically "encapsulates" the problem. If you don't believe me, check out the CLR code generated from C# as you create an async method, with a bunch of await statements in C#. I once put a .Net application into production, and after 20 minutes the thing would go 503 on me (service unavailable). The reasons was bad usage of HttpClient, exhausting my server's thread pool, resulting in that the operating system no longer had available threads to serve HTTP requests. It took us a couple of weeks to fix the issue, since the entirety of our web app more or less had to be touched, due to bad encapsulation of our HttpClient instance. In the meantime, we had to create a service that would recycle our application every 20 minutes to simply make sure the thing was partially working. This thing was implemented by a bunch of senior software developers. Add juniors to the mix, and the thing would probably not have been able to salvage at all ...

Multithreading is RIDICULOUSLY complex ...!!

And if you don't agree with me, you haven't done enough multithreading. However, in Hyperlambda, I have reduced the construct down to a handful of "primitives", that you can declare with code as simple as the following ...

join

   fork

      http.get:"https://servergardens.com"

      log.info:Thread 1 finished

   fork

      http.get:"https://gaiasoul.com"

      log.info:Thread 2 finished

   fork

      http.get:"https://dzone.com"

      log.info:Thread 3 finished

log.info:All threads are done

And yup, the thing does exactly what you think it does. Compare the above syntax with the average C# or Java solution doing the same, and you're easily looking at a piece of code, that would dwarf the cognitive capacity of even most of our senior developers. The above thing creates 3 threads, executing all threads in parallel, for then to wait until all 3 threads are done, at which point you have access to the "return value" of all 3 threads.

And, the thing is fundamentally async in nature, implying that as the code is waiting for IO traffic to return from all 3 respective HTTP invocations, the thing is consuming zero threads, implying no more "503 funny stuff" for my web server. And yes, before you ask, it's using IHttpClientFactory to (correctly) instantiate HttpClient objects. In the video below I am demonstrating the concept using Magic's Eval/REPL Hyperlambda thing.

The above construct, at least in theory, basically allows me to create a solution having millions of threads, executing in parallel, without exhausting my web server's thread pool for available threads - Assuming I've got enough memory to actually store the contexts for each of my threads as they're suspended. For the record, I don't recommend it though ...

And of course, since Hyperlambda is fundamentally async in nature, suspending the worker thread on every single IO operation by default, this implies the thing is as scalable as NodeJS, possibly even more - While as fast as .Net Core. Further implying that even though Hyperlambda is a super high abstraction layer, and arguably the most "high level" programming language in the world, it would probably run in circles around things such as PHP, Python, NodeJS, RoR, etc, etc, etc. Or as Winnie the Pooh says.

Scalability, speed, or simplicity? Yes please, all of the above ^_^

Sorry Microsoft, life is simply too short to do multithreading and async stuff in C# - Especially once you add HttpClient to the mix ... ;)