Single-Threaded vs. Multi-Threaded Execution

When building a new application, one of the important decisions you make is the technical stack. This involves many considerations, one of them being the backend programming language. How flexible is it? What is the paradigm – FP or OO? Strictly-typed, loosely-typed, or no types? How has the language evolved? Is it still evolving? How extensible is it? How broad and passionate is the developer community? How does the language handle concurrency? Oh, concurrency.

In computer science, concurrency refers to the ability of a program to handle multiple instructions simultaneously. This is where multi-threaded languages excel. In a single-threaded language, achieving pseudo-concurrency (non-blocking operations) requires an event-driven architecture or asynchronous I/O.

My role at Liberty Supply requires a high degree of concurrency. The problem is that I'm not good at concurrent execution. My brain is single-threaded. For the most part, I think in linear phases of execution. I think in terms of dependencies and an orchestrated order of operations. Concurrency is at odds with this.

But, I acknowledge and adapt to the constraints of my internal runtime. I definitely work off an event loop... and man, is that queue deep. Perhaps that's why I gravitate to Node. I have a familiarity with and affinity toward its architecture.

Ironically, Node itself is mostly written in C++. Its association with JavaScript is due to Chrome's V8 runtime. Node is a C++ wrapper around Google's lightning-fast JavaScript runtime. All these years later, it still feels strange to write JS on the backend. At the same time, it feels thematically familiar to being an out-of-place developer in an industry architecture that is easily ten years behind.