DEV Community: Juma Evans

Goroutines vs. Promises: Why Go and JavaScript Look at Concurrency Completely Differently

Juma Evans — Mon, 25 May 2026 07:43:46 +0000

Handling concurrency is one of the most critical decisions in modern software architecture. When applications need to handle thousands of simultaneous tasks—like serving HTTP requests, streaming data, or background processing. The design of a language’s concurrency model dictates how easily developers can write fast, safe, and maintainable code.
Go is famous for making concurrency a native, deeply integrated primitive through goroutines and channels. To truly appreciate Go's design, it helps to contrast it with JavaScript, which handles concurrency using a completely different philosophy: a single-threaded Event Loop fueled by asynchronous non-blocking I/O.
Here is an architectural deep dive into Go's multi-threaded concurrency engine and how it measures up against JavaScript's single-threaded asynchronous model.

Part 1: The Foundations of Go Concurrency
Go’s concurrency model is based on a paper by C.A.R. Hoare called Communicating Sequential Processes (CSP). The core philosophy of CSP in Go can be summarized by its most famous mantra:
"Do not communicate by sharing memory; instead, share memory by communicating."
Instead of having multiple threads fight over the same piece of memory using complex locks, mutexes, and semaphores, Go encourages developers to run independent processes (goroutines) that pass data back and forth through safe conduits (channels).

Primitives: Goroutines and Channels
Go replaces heavy, operating system-level threads with goroutines.
Goroutines: They are incredibly lightweight, starting with a stack size of just a few kilobytes (typically 2KB), which can grow and shrink dynamically. Because they require so little overhead, a single Go application can easily spin up hundreds of thousands of concurrent goroutines without exhausting system memory.
Channels: These are typed pipelines that allow goroutines to synchronize and exchange data. By default, channels are unbuffered, meaning a sender will block until a receiver is ready to take the data, creating natural synchronization points without manual locks.
The Magic Under the Hood: The M:N Scheduler
Go achieves this high efficiency using its internal Go Runtime Scheduler, often referred to as the GMP Model:
G (Goroutine): Represents the goroutine, its stack, and current status.
M (Machine): Represents a physical, OS-level thread managed by the operating system kernel.
P (Processor): Represents a logical resource or context required to execute Go code. The number of Ps usually matches the machine's physical CPU cores.
The scheduler assigns multiple goroutines (G) onto a smaller pool of OS threads (M) via the logical processors (P).
If a goroutine performs a blocking action, such as waiting for a network response or a file read—the Go runtime is smart enough to swap out that blocked goroutine, move the remaining active goroutines to a different OS thread, and keep the CPU busy. This concept is known as work-stealing, and it happens completely automatically behind the scenes.

Part 2: Go Concurrency in Action
Writing concurrent code in Go requires very little boilerplate. You simply prefix a function call with the go keyword.
Here is a practical pattern: a worker pool where multiple concurrent workers process jobs sent via a channel, and report their progress safely.

package main

import (
"fmt"
"sync"
"time"
)

// worker processes incoming jobs from the jobs channel
func worker(id int, jobs <-chan int, results chan<- int, wg *sync.WaitGroup) {
defer wg.Done() // Signal completion when the worker exits

for job := range jobs {
    fmt.Printf("Worker %d started job %d\n", id, job)
    time.Sleep(time.Millisecond * 100) // Simulating an I/O task
    results <- job * 2
}

}

func main() {
numJobs := 5
jobs := make(chan int, numJobs)
results := make(chan int, numJobs)

var wg sync.WaitGroup

// Spin up 3 concurrent workers
for w := 1; w <= 3; w++ {
    wg.Add(1)
    go worker(w, jobs, results, &wg)
}

// Send jobs to the channel
for j := 1; j <= numJobs; j++ {
    jobs <- j
}
close(jobs) // Closing tells workers no more jobs are coming

// Wait for all workers to finish in the background
go func() {
    wg.Wait()
    close(results)
}()

// Collect all results
for res := range results {
    fmt.Printf("Result processed: %d\n", res)
}

}

Part 3: The Contender
How JavaScript Handles Asynchrony
While Go provides a multi-threaded runtime that automatically abstracts away hardware limitations, JavaScript takes an entirely opposite approach. JavaScript's core philosophy is single-threaded simplicity driven by an Event Loop.
JavaScript operates on exactly one thread of execution (the main thread). It cannot natively execute two mathematical formulas simultaneously on different CPU cores. To prevent this single thread from freezing when downloading data or reading files, JavaScript relies on Asynchronous Non-Blocking I/O.

Primitives: Promises and Async/Await
Instead of lightweight threads, JavaScript relies on Promises and state management.
Promises: A Promise is an object representing the eventual completion (or failure) of an asynchronous operation. When a network request is fired, JavaScript leaves a Promise placeholder and immediately frees up the main thread to handle other UI interactions or requests.
Async/Await: Syntactic sugar built over Promises. When you mark a function as async, it pauses execution inside that specific function when it hits an await keyword, returning control of the main thread back to the runtime execution engine until the background task is ready.

The Engine: The Event Loop
Because JavaScript doesn't have a multi-threaded scheduler, it passes heavy lifting (like cryptography, network calls, or disk interactions) off to its container environment (the browser's Web APIs or Node.js background thread pool).
Once those background operations finish, they drop their callbacks into a Task Queue. The Event Loop constantly monitors the main thread. If the main thread is empty, it grabs the next task from the queue and executes it.
Let's look at how JavaScript achieves a similar worker execution strategy using Promises and Promise.all:
// Simulating an asynchronous job
async function worker(id, job) {
console.log(Worker ${id} started job ${job});

// Simulating an I/O task (like a database query) using a non-blocking timeout
await new Promise(resolve => setTimeout(resolve, 100));

return job * 2;
}

async function main() {
const jobs = [1, 2, 3, 4, 5];

// Map our jobs into an array of concurrent Promises.
// JavaScript kicks them all off immediately in the background.
const workerPromises = jobs.map((job, index) => {
const workerId = (index % 3) + 1; // Distribute across 3 simulated workers
return worker(workerId, job);
});

// Wait for all background tasks to finish and collect results
const results = await Promise.all(workerPromises);

results.forEach(res => {
console.log(Result processed: ${res});
});
}

main();

Part 4: Head-to-Head Comparison
To understand which paradigm fits a project best, we have to look at the architectural trade-offs between Go's implicit multi-threaded runtime and JavaScript's single-threaded execution queue.
a. Primary Model & Execution Strategy
The Go Way: Uses Communicating Sequential Processes (CSP). Concurrency is handled by spinning up independent, lightweight threads (goroutines) that communicate safely by passing data through typed conduits called channels.
The JS Way: Uses an Event-Driven Architecture. Concurrency is handled on a single main thread via an Event Loop that relies on Promises and callbacks to manage tasks asynchronously.

b. Hardware & CPU Utilization
The Go Way: Multi-threaded by default. Go’s built-in scheduler automatically distributes workloads across all available physical CPU cores, allowing for true, simultaneous hardware parallelism.
The JS Way: Single-threaded by default. It executes code on only one CPU core. While it can handle thousands of tasks concurrently by overlapping wait times, it cannot execute tasks simultaneously on the same thread.
c. Task Mechanism & Memory Overhead
The Go Way: Driven by Goroutines, which are managed entirely by the Go runtime rather than the OS. They are incredibly lightweight, starting with a tiny memory footprint of just around 2KB per goroutine.
The JS Way: Driven by Promises and Async/Await. These are not threads, but rather JavaScript object state machines that track the progress of a background task, carrying the memory overhead of the V8 JavaScript engine.

d. Handling Heavy Math and Computation
The Go Way: Excellent. Because it can utilize multiple CPU cores, heavy computations, data processing, or cryptography can run in the background without affecting or slowing down the rest of the application.
The JS Way: Weak. Because everything runs on a single thread, any heavy mathematical calculation or CPU-bound task will completely freeze the Event Loop, stalling the entire application until the calculation finishes.

e.Inter-Task Communication
The Go Way: Features Native Typed Channels. This built-in primitive allows goroutines to pass data to one another seamlessly, acting as a natural synchronization barrier without needing manual memory locks.
The JS Way: Relies on patterns like EventEmitters, Streams, or Async Generators. Because there is only one thread, tasks don't need to coordinate memory access, but streaming data requires using event-based libraries.

f.Task Control and Preemption
The Go Way: Supports Preemption. The Go runtime scheduler is highly intelligent; if it notices a single goroutine is acting greedily and hogging a CPU core for too long, it will forcefully pause it to give other tasks a turn.
The JS Way: Has No Preemption. JavaScript code is strictly cooperative. If a function contains a long, synchronous loop that doesn't include an await keyword, it will hold the entire main thread hostage until it completes.

True Parallelism vs. Non-Blocking Concurrency The ultimate mechanical difference is Parallelism vs. Concurrency. Go is capable of parallelism. If you have an 8-core CPU processor, Go can run 8 different computing tasks at the exact same millisecond. If one goroutine goes rogue and gets stuck in an infinite mathematical calculation loop, Go's scheduler will forcefully step in (preemption), pause it, and use the other CPU cores to keep your application running smoothly. JavaScript is strictly concurrent but serial. It excels at waiting without locking things up. If 1,000 users request data from a database at once, JavaScript fires off all 1,000 queries to the OS database drivers immediately, moves on to do other things, and handles the results one by one as they crawl back. However, if you give JavaScript a heavy mathematical equation to calculate, it cannot delegate it to another core—the entire server or UI freezes completely until that calculation finishes.

2. Synchronization and Data Safety
Because Go shares memory across actual physical CPU threads, it introduces the danger of Data Races (two threads trying to change the exact same memory address at the same time). Go provides channels to prevent this, but if developers get careless, they must use manual mutex locks (sync.Mutex) or run Go's runtime race detector (go run -race) to find hidden multi-threading bugs.
JavaScript completely bypasses data races by design. Because everything ultimately executes on a single main thread, you never have to worry about two blocks of code altering a variable at the exact same millisecond. This completely eliminates a massive category of complex, hard-to-track multi-threading bugs.

3. Memory & Resource Footprint
Go's goroutines are remarkably lightweight (~2KB), but they still carry the overhead of an active, multi-threaded runtime scheduler and an internal Garbage Collector that scans heap allocations across threads.
JavaScript's basic Promises are incredibly cheap state objects, but because JavaScript runs inside engines like Google's V8, its base memory baseline per application instance is significantly larger than a compiled, lean Go binary.
Conclusion: Which tool is right for the job?
Choose Go if you are building data-intensive microservices, streaming platforms, heavy background computing tools, or high-throughput network APIs. Go gives your application the muscle to exploit your hardware's full multi-core capacity effortlessly.
Choose JavaScript if you are building fast I/O bound applications like standard CRUD web APIs, web sockets, or real-time chat apps where the vast majority of execution time is spent passing data back and forth from databases. JavaScript keeps code straightforward, predictable, and exceptionally easy to debug.
Both ecosystems solved the ancient problem of traditional, clunky OS multi-threading, Go by building a highly advanced multi-threaded coordination engine, and JavaScript by proving exactly how much you can achieve on a single thread if you just learn how to wait effectively.

Regulalar Expression

Juma Evans — Wed, 13 May 2026 01:47:34 +0000

Mastering Regular Expressions in JavaScript: From Basics to Real-World Validation

At first glance, a regex pattern looks like a cat walked across your keyboard,a chaotic string of slashes, brackets, and symbols. However, once you decode the syntax, it becomes one of the most powerful tools in your developer toolkit.
Below is the break down of how regex works in JavaScript and build a robust pattern to validate something we use every day: email addresses.

What is a Regular Expression anyways?

A Regular Expression is an object that describes a pattern of characters. In JavaScript, you can create them in two ways:

Literal Notation: /pattern/flags
Constructor: new RegExp('pattern', 'flags') ### The Core Building Blocks Before we tackle the email login, we need to understand the "alphabet" of regex:
Character Classes:
- \d: Matches any digit (0-9).
- \w: Matches any alphanumeric character (letters, numbers, and underscores).
- \s: Matches whitespace (spaces, tabs).
- .: The wildcard—matches any character except a newline.
Quantifiers:
- +: Matches 1 or more of the preceding element.
- *: Matches 0 or more.
- {n,m}: Matches between n and m times.
Anchors:
- ^: Forces the match to start at the beginning of the string.
- $: Forces the match to end at the end of the string. ### Deep Dive: Validating an Email Address When we log in to a platform, the first line of defense is ensuring the input actually looks like an email. Let’s build a regex for a standard email like zone01.recode@company.co.ke. #### 1. The Local Part (zone01 .recode) We want to allow letters, numbers, dots, and underscores.
Pattern: ^[a-zA-Z0-9._%+-]+
Explanation: We start at the beginning (^) and allow a set of characters inside the square brackets. The + ensures there is at least one character. #### 2. The "@" Symbol We just need the literal character.
Pattern: @ #### 3. The Domain (company) Similar to the local part, but usually without the special symbols.
Pattern: [a-zA-Z0-9.-]+ #### 4. The TLD (.co.ke or .com) We need a literal dot, followed by letters. Since a dot . is a wildcard in regex, we must escape it with a backslash ..
Pattern: .[a-zA-Z]{2,}$
Explanation: This looks for a dot and at least two letters at the very end of the string ($). #### Putting it all together:

const emailRegex = /^[a-zA-Z0-9._%+-]+@[a-zA-Z0-9.-]+\.[a-zA-Z]{2,}$/;

const testEmail = "dev_user123@zone01.edu";
console.log(emailRegex.test(testEmail)); // Output: true

Common Use Cases in Web Apps

Beyond login forms, regex is used everywhere in full-stack development:

Password Strength: Checking for at least one capital letter, one number, and one special character.
URL Parsing: Extracting slugs or IDs from a browser's address bar.
Data Scrubbing: Removing formatting from phone numbers (e.g., changing +254 712-345-678 to 254712345678).
Search and Replace: Swapping specific words across a whole document using the global /g flag. ### Helpful Methods in JavaScript To use your patterns, you’ll mostly use these two methods:
regex.test(string): Returns true or false. Perfect for form validation.
string.match(regex): Returns an array of matches. Great for extracting information from a large block of text. > Pro Tip: Use tools like RegEx101 to test your patterns in real-time before putting them into your code. It provides a "flavor" setting—make sure to select ECMAScript (JavaScript). > ### Conclusion Regex might feel like a steep climb, but it is a "learn once, use everywhere" skill. Whether you are working on a Go backend or a JavaScript frontend, the logic remains largely the same. Keep practicing by trying to validate other common inputs like phone numbers or postal codes!

Docker Unlocked: What I Wish I Knew earlier.

Juma Evans — Wed, 18 Feb 2026 20:20:02 +0000

When I first heard about Docker, I thought it was something extremely complex that only senior developers used.

Until recently, that is. When I finally started learning Docker, I found out how amazing it is, and I want to share what I've learned.
If you're just starting out, this is for you.

So…
1. What Is Docker?
Docker is a tool that lets you package your application with everything it needs to run:-dependencies, libraries, system tools, and your code;into something called a container.
2. What Problem Does Docker Solve?
Think of it like this:
"It works on my machine" stops being an excuse.
With Docker, if it works inside the container, it works everywhere.
Before Docker, this is what used to happen:
Developer X runs the application successfully.
Developer Y tries to run it, and it breaks.

Developer X tells Developer Y: “But it works on my machine!”

Why?
Different environments:

° Different operating systems
° Different versions of NODE or Go or Python
° Different installed dependencies

Docker solves this by creating a consistent environment that travels with your application.

3. What Is a Container?
A container is like a lightweight, portable box for your application.
But unlike a full virtual machine:

° It starts fast—usually in seconds
° It uses fewer resources
° It's easy to share and move around

How It Works:

You define how your application should run in a file called a Dockerfile (a blueprint for your environment).
Docker uses that file to build an image (a snapshot of your app and everything it needs).
Then that image runs as a container (the live, running version of your application).

When I first installed Docker, created my Dockerfile, built an image, and it actually worked…
I felt like I unlocked a new level in development 😂.
That was the moment I realized:
This is how real-world applications are deployed.

Why Every Beginner Should Learn Docker
Here is why I believe Docker is worth learning early:

It Makes You Think Like a Backend Engineer You begin to understand: ° Ports and how applications communicate ° Services and how they connect ° Environment configurations ° How production setups differ from local development
It Improves Your Project Structure You naturally start organizing your apps better when you know they'll run in containers.

🛠 Things That Confused Me at First
To be honest:
° Images vs. Containers: I couldn't keep them straight. (Think of an image as a recipe and a container as the actual cooked meal.)
° Dockerfile syntax: It looked scary at first glance.
° Ports: Mapping ports from the container to my computer didn't make sense initially.

But after building just one simple container for a Go app, everything started connecting.

What Next?
Now that I understand the basics, I plan to:

° Containerize my Go projects
° Learn Docker Compose (for running multiple containers)
° Understand how containers are used in production

One step at a time.

Summary
Imagine you bake a cake 🍰 at home.
You pack:
°The cake
°The ingredients list
°The exact oven settings
°The instructions

Then you put everything inside one box.
Now, no matter where that box goes, Nairobi, Kisumu, or New York, anyone can open it and get the exact same cake.
That is exactly what Docker does.

It puts:
. Your app
. The tools it needs
. The correct settings
Inside one “box” called a container.
So instead of saying:
“It works on my machine.”
You can confidently say:
“It works everywhere.”