I actually sat through the "true concurrency" video. Amazing. Now that I've successfully managed to claw apart the wreckage that used to be my perception of a single, linear reality, and put it back together again, I'm still not 100% convinced that it's all assembled with the same original parts. If I notice my colour perception shifting randomly, I'll be in touch to share any useful insights.
Honestly, I'm having a lot of trouble trying to figure out how an event loop would work in an "emulator-as-CPU-core" context. I can't quite map it.
But in the process of thinking through this problem, I realized I didn't know anything about the NodeJS event loop -- so I tried to intuit how it probably has to work, given the constraints of the environment it's working in, combined with what I know about how interpreted languages work and how true multithreading works.
My intuition led me to the conclusion that the event loop probably works by having a single JS "thread" that's constantly pulling callbacks from a queue and executing them. In the process of executing them, "async" operations are executed, which A) calls out to the OS/VM to perform an asynchronous operation such as file read, HTTP request, etc.; B) registers a JS callback against the results of that OS/VM call; and C) returns control back to the JS immediately. When the OS/VM call is completed, the registered JS callback function is asynchronously inserted into the core callback queue, which will be picked up by the event loop.
Can you imagine how fucking cool it was to look it up and discover that I had basically guessed it completely, barring some (very important) implementation details?
The reason I share this is mainly because it underlines the philosophy I share in this post: all these things really do matter more than bootcamps and YouTube Shorts Programming Gurus would have us believe, and they can supercharge our ability to navigate this field in ways we can't possibly predict.
And the joy of realizing you figured something out *before learning how it really works* is an incredibly sticky learning experience. I'm not going to forget how the NodeJS event loop works now.
The more of the foundations we learn, the more we're able to see everything else (such as the NodeJS event loop) in greater clarity: less as the whole thing itself, and more as the *core innovation of that thing* against the backdrop of the foundation it's built upon. Which is much easier to reason about.
Although I do think it uncouth to monetize my video/content without permission, I do at least appreciate that the article itself linked to the blog post and was very clear that they were not the original creators.
Frankly, the main thing which concerns me is that I think I was irresponsible in posting the final video in the post without a preliminary epilepsy warning *inside the video*. I've since updated it to include that, but their YouTube reupload of the video occurred before that time. Especially on a platform such as YouTube, I think this could cause a real problem for at least one person, which is concerning to me.
Absolutely brilliant. The analogy of threads as emulator save states is not only clever but also incredibly illustrative. Implementing multithreading within Super Mario Bros. to demonstrate concepts like mutexes and condition variables is both innovative and educational. It's a testament to how complex computing concepts can be made accessible and engaging through creative approaches. Looking forward to more such insightful explorations!
I actually sat through the "true concurrency" video. Amazing. Now that I've successfully managed to claw apart the wreckage that used to be my perception of a single, linear reality, and put it back together again, I'm still not 100% convinced that it's all assembled with the same original parts. If I notice my colour perception shifting randomly, I'll be in touch to share any useful insights.
Can you imagine how hard it was to get a "decent" recording for the blog?
I'll never be whole again...
Very Interesting! How would you say these threads compare to an event loop like in Node.JS?
Honestly, I'm having a lot of trouble trying to figure out how an event loop would work in an "emulator-as-CPU-core" context. I can't quite map it.
But in the process of thinking through this problem, I realized I didn't know anything about the NodeJS event loop -- so I tried to intuit how it probably has to work, given the constraints of the environment it's working in, combined with what I know about how interpreted languages work and how true multithreading works.
My intuition led me to the conclusion that the event loop probably works by having a single JS "thread" that's constantly pulling callbacks from a queue and executing them. In the process of executing them, "async" operations are executed, which A) calls out to the OS/VM to perform an asynchronous operation such as file read, HTTP request, etc.; B) registers a JS callback against the results of that OS/VM call; and C) returns control back to the JS immediately. When the OS/VM call is completed, the registered JS callback function is asynchronously inserted into the core callback queue, which will be picked up by the event loop.
Can you imagine how fucking cool it was to look it up and discover that I had basically guessed it completely, barring some (very important) implementation details?
The reason I share this is mainly because it underlines the philosophy I share in this post: all these things really do matter more than bootcamps and YouTube Shorts Programming Gurus would have us believe, and they can supercharge our ability to navigate this field in ways we can't possibly predict.
And the joy of realizing you figured something out *before learning how it really works* is an incredibly sticky learning experience. I'm not going to forget how the NodeJS event loop works now.
The more of the foundations we learn, the more we're able to see everything else (such as the NodeJS event loop) in greater clarity: less as the whole thing itself, and more as the *core innovation of that thing* against the backdrop of the foundation it's built upon. Which is much easier to reason about.
This article has been summarized and published on a Japanese website ( https://gigazine.net/news/20250529-what-threads-mario-bros/ ). The video has also been reposted on YouTube and monetized. Have you given permission for this?
I had not been contacted about this, no.
Although I do think it uncouth to monetize my video/content without permission, I do at least appreciate that the article itself linked to the blog post and was very clear that they were not the original creators.
Frankly, the main thing which concerns me is that I think I was irresponsible in posting the final video in the post without a preliminary epilepsy warning *inside the video*. I've since updated it to include that, but their YouTube reupload of the video occurred before that time. Especially on a platform such as YouTube, I think this could cause a real problem for at least one person, which is concerning to me.
Absolutely brilliant. The analogy of threads as emulator save states is not only clever but also incredibly illustrative. Implementing multithreading within Super Mario Bros. to demonstrate concepts like mutexes and condition variables is both innovative and educational. It's a testament to how complex computing concepts can be made accessible and engaging through creative approaches. Looking forward to more such insightful explorations!