DEV Community: lbvf50mobile

The General Mechanism of the UNIX Mainframe and the Go Runtime

lbvf50mobile — Sat, 06 Jun 2026 16:20:23 +0000

Go was created in the same place where UNIX was made — at Bell Labs. And after carefully studying the mechanics of the Go Runtime (the internal structure) of a running Go program, I have come to a conclusion: It is a miniature logical structure of UNIX.

Or to put it another way, more succinctly: Go implements a Mainframe within a single program. This means it gives the programmer the same abstractions that UNIX programmers had in the 70s and 80s, when programs were mean and lean.

Specifically:

A Goroutine is an OS Process-Thread (from back when threads didn't exist yet and there were only processes)
All I/O is blocking
The so-called Channels in Go are Pipes with the abstraction of a Stream (a byte stream)

They gave them different names, but the essence is exactly the same. Processes with 3 states and their own memory, and Streams of data as a means of communication between them.

In other words, a Go program is a tiny 80s mainframe right under your fingertips. Everything is just as simple, clear, beautiful, and designed by the same Bell Labs team.

This is why Go was so loved by grumpy programmers in the 2010s. It returned to an era where a handful of core abstractions solved every problem, instead of drowning developers in a bloated cloud of redundant tools.

P.S.

Why Go? To make the scale of abstractions human-sized again.

In the 70s, mainframes received text and returned text to the user. HTTP servers do the same thing today, but the abstractions have multiplied tenfold: blocking vs non-blocking calls, processes vs threads, dozens of IPC mechanisms.

Go returns the developer to the world of 70s UNIX, but leveraging all the benefits of modern OSes. For goroutines, all calls are blocking. The Go Scheduler handles both blocking and non-blocking operations through the complex G/P/M + NetPoller system - but the developer gets a clean, minimalist interface that echoes the "golden age" of UNIX, where everything was just files and streams.

In short, Go is Plan9 in a single process.

The Mental Model of Go as a Simplified UNIX

lbvf50mobile — Sat, 06 Jun 2026 08:57:56 +0000

The Go runtime is essentially an implementation of UNIX ideas within a single OS process. The OS process becomes the "Host OS", while goroutines act as the process threads from early operating systems, blocking on any I/O operation.

Above all, this perspective provides the developer with a simplified mental model. The developer works with a sort of "Proto-UNIX", where each goroutine is a "process" and "channels" are "byte streams." And all this abstraction operates entirely within a single OS process of the real underlying OS.

This reduction and simplification is necessary as a design model for the programmer. It is like working at the high level of HTTP, where you don't think about packets. In essence, when we write in Go, we are writing for a "good old UNIX", where goroutines are "bash scripts" and channels are STDIN/STDOUT. This achieves complete abstraction from the underlying host OS.

In this sense, a Go program is essentially an interaction with a virtual machine. It is very similar to JS. The Go Runtime is a classic Virtual Machine in Tanenbaum's terminology: a beautiful interface over a complex underlying implementation.

G/P/M Go Scheduler

lbvf50mobile — Sat, 06 Jun 2026 03:58:31 +0000

In the goroutine execution model, any I/O call appears blocking, halting the code execution for the goroutine. However, underneath, network calls in the OS are actually non-blocking. When a network call occurs, the goroutine transitions to a "waiting" state, and the call itself is registered with a Go Scheduler component called NetPoller.

NetPoller itself is a wrapper, an interface over various implementations of non-blocking I/O in the host operating systems Go runs on: Windows, *BSD, Linux. In the case of Linux, NetPoller is a wrapper around epoll. When a response arrives for a non-blocking network call, NetPoller moves the goroutine to a "runnable" state and adds it to one of the queues of runnable goroutines.

However, non-blocking calls are not the only type; there are also blocking system calls. In this case, the goroutine transitions to a waiting state along with the OS thread, which is known as "M" in the Go Scheduler's terminology. The OS thread remains blocked with the waiting goroutine. Meanwhile, the logical processor (P) and its local queue of runnable goroutines look for another OS thread, another M. When the response from the system call arrives, the M thread looks for a logical processor for its goroutine (or, like NetPoller, adds the goroutine in a "runnable" state to one of the queues), while the M thread itself goes to sleep in the OS Thread Cache.

Finally, there is the logical processor, referred to as "P", which was mentioned earlier. It polls the queues of runnable goroutines, drains the local queues of other logical processors (P)—a mechanism known as Work Stealing—and checks the global queue of runnable goroutines. It also leaves OS threads (M) blocked by system calls, seeking out unblocked OS threads (M).

Thus, between a goroutine and a physical core, there are two levels—P and M—which assist each other during different types of goroutine blocking. If a goroutine is paused by a non-blocking call, there is no need to free the OS thread (M); it can simply take another goroutine from the queue. If a goroutine blocks the thread (M), execution can switch to another thread to continue running other goroutines. As a result, the physical processor never idles during I/O-bound tasks.

Based on articles about the Go Scheduler by Bill Kennedy and Daniel Morsing.

P.S. An LLM corrected me, pointing out that when M is blocked by a system call, P detaches, and another M looks for it. It doesn't exactly "leave" on its own. But that's beside the point. In principle, this was already implied, and it doesn't change the overall mechanics.

P.P.S. Here is what I realized: the Go runtime scheduler is not needed to "avoid physical cores going idle". It is needed to avoid a process written in Go falling into a waiting state, or avoid expensive context switching due to another system call or network request.

Goroutines and G/P/M defragment the OS process. As a result, the OS process falls into the "wait" state less often, and context switches at the OS level happen less often. Because the M/P pair allows constantly feeding RUNNABLE units of execution (G) onto a running M. Context switching of goroutines in Userspace is cheap.

Golang G/M/P Time Scale

lbvf50mobile — Wed, 08 Apr 2026 09:09:43 +0000

If we imagine that 1 millisecond is one “day”, then 1 second becomes about 3 years.

1 s ≈ 3 “years”
1 ms = 1 “day”
2 µs ≈ 1 “minute”
10 ns ≈ 1 “second”

Thus, the RTT over 5000 km (~56 ms) is about 2 “months”.

And G/M/P scheduling (context switching), which takes ~1000 ns, is about 30 “seconds” in this scale.

The Archetypal Go Program: Servers, Goroutines, and Scheduling

lbvf50mobile — Thu, 02 Apr 2026 17:08:55 +0000

This post gives an answer to the question: why Go is optimized for concurrent I/O-intensive systems such as network services.

A programming language is not only syntax, but also a runtime implementation. Runtime is the part of the executing program where data structures and algorithms that support syntactic constructs of the language are implemented. Namely, the implementation of dictionaries (maps), sets, asynchrony, parallelism, and concurrency (which are not the same thing).

Golang is unique, and for the 2010s revolutionary, in its implementation of the Syntax + Runtime combination for an ARCHETYPICAL program design. An archetypical Go program is a server running in a single OS process on multiple OS threads, which handles a flood of HTTP requests while maximizing the utilization of OS threads.

As is known, the execution of a program’s algorithm can be blocked algorithmically (something is waiting for a response), or physically when an OS thread waits for I/O. In Go, both types of blocking are reduced to a minimum through the implementation of a virtual processor layer and lightweight goroutines. In this way, virtual processors are switched between OS threads, and goroutines that are waiting and ready to execute are shuffled, so that the real CPU is practically not idle. And the entire mechanism is described with simple and clear syntax.

Thus, Go is designed for writing programs that, within a single OS process, process the maximum number of requests above the Transport Layer in the most optimal way. The archetypical program design is: a listening goroutine that launches handler goroutines for each connection. Everything else is delegated to the runtime. And the runtime, in turn, manages the execution sequence of goroutines across different virtual processors and different OS threads.

    // Core of the Archetypical Go Application 
    listener, _ := net.Listen("tcp", ":8080")  
    for { 
       conn, _ := listener.Accept() 
       go handle(conn)`  
    }

The Go scheduler model is called G/P/M — Goroutine / Processor Virtual / Machine Thread, or alternatively N:M, where N goroutines are executed on M OS threads. Sometimes it is also called M:N, but I prefer to keep the letter M for OS threads.

The essence in one paragraph from ChatGPT:

Go is designed to simplify the development of concurrent I/O-intensive systems. This is achieved through the built-in goroutine model and a runtime scheduler that distributes their execution across a limited number of OS threads (M:N scheduling). As a result, the developer writes simple synchronous code, while concurrency and task switching are handled by the runtime.

Golang HTTP handlers in Middleware

lbvf50mobile — Sat, 28 Mar 2026 06:30:28 +0000

IT IS A DRAFT CONSIDERATION. May has ERRORS.

UPD: The main inside of this text is that Middleware mechanis in Golang is not write a chain of method that call each other. But! Return one method, that in it's core a wrapped "onion" of one closure calls anoter. If it's correct to say. We return a method, that calls a method, that calls a method, and all these methods are required from arguments of the call, and all are in Closure Scope.

If start to consider OS Server Process as an average UNIX OS Process (using very rough simplification): that Process has STDOUT to Write Respond, and STDIN to Read Request from a client. That's clear STDOUT to Write and STDIN to Read.
Next let's wrap these STDOUT and STDIN in Objects described by Interfaces. STDOUT would be http.Respnose to Write, and STDIN would be http.Requst to read from.
Eventually the handling of the request will be a single method ServerHTTP(w http.Responce, r * http.Request). It is a singe method with just two argument one for write and one for read.

Having one method we able to add wrapping methods f1(w,r){ f2(w,r){ f3(w,r){ ServeHTTP(w,r)}}}}.

Also we could put w and r in closures that not writing methods all the time in one place but share them among each other.
// w and r in the Closure.
f1 := func(handler1){ do1(); handler1();}
f2 := func(handler2){ do2(); handler2();}
f3 := func(){ do3(); ServeHTTP(w,r);}
f1(f2(f3()));
Something like hat in a draft with a simplification.

Something like hat in a draft with a simplification.
Yes, it Has Errors. Need to clarify the way a Handler Called. And the way it Return. But the Idea is Correct.

The main thing is: We just create a new Handler method by chain of calls of Middlware - that wrap, wrap, wrap, wrap initial ServeHTTP by Methods with Clouser. Middleware not a function to call, it is a funtion that crate function for call.
That's it. Thanks God, Jesus Christ! The main issue of understanding is closed.

Mental Models from my Diary

lbvf50mobile — Fri, 06 Mar 2026 13:38:41 +0000

Just over viewing my Diary since September 2025 to March 2026 - I extracted next crucial mental models. These mental models are sharped during hard battles in local communities.

Kernel <= SysCalls => UserSpace;

Kernel(TCP) <= Socket => UserSpace(TLS)

Kernel(OSI[1..4])<=Socket=> UserSpace(OSL[5..7])

In common all these models tell about one concept Interface-Contract, that is implemented and kept for decades in UNIX TCP/IP stack. Where the socket interface is a contract between Kernel internal implementation and UserSpace internal implementation. As It is possible to observe these models [Internal]<=Interface=>[WorkingGround] are very similar, and could be found in different areas of Networks and Web Development.

(HTTP.1/HTTP.2/QUIC)<==[request/response interface]==>(Ruby/PHP/Perl/Python frameworks)

Starting from OS and keeping exploring up to App implementation it is required to do the same thing - define Interface-Contracts that would be stable for a long time.

The Golang

lbvf50mobile — Tue, 03 Mar 2026 07:48:04 +0000

After some thought about Golang and Schedulers, comparing with a Ruby scheme I made a next conclusion:

The purpose of the Golang is to combine HTTP server with Business logic in bounds of one OS Process.

Where as in Ruby, Python, PHP - HTTP server is a separate Process that requires expensive IPC.

Golang model changes focus from the Process to Threads - because Threads are execution pathes, Process are more metadata structures that comprises shared data environment among several Threads. And Golang invents ultra light Threads called Goroutines - that allows to reduce cost of injecting new extcution path into the game.

The key part of Golang is Scheduler that take a time-sharing burden of the programmer's shoulders. Now it is easy to write IO-bond programs, because Go Scheluer will manage all these suspended Goroutines automatically.

Go solves a problem that rouse in 1960-1970 in the Mainframes: Optimal usage of CPU during IO-bound tasks, when a program just waits for an user input. Now it is the same condition - program just waits a response from the network.

P.S. It is an overview of a language roots, back in 2009 Golang has it's architecture for that purpose, those times it was a common solution to separate HTTP server from the framework by a socket- or something like that. Today there are a plenty technologies to run all components in one process.

For me it is an explanation of the Standard library model in the Golang.

Eventually I feel the true Essence of Go

lbvf50mobile — Sun, 25 Jan 2026 22:59:43 +0000

The core Idea - Go Scheduler is a Key to an entire Go structure: std lib and an app architecture.

Long story short: I get into G/P/M model of the Go Scheduler, and found the back-bone model of the all Go programs: Separate Goroutine for each TCP connection. One Listening Goroutine with a "listening Socket", and bunch of others serving "connections Socket". Look at that model from the OS perspective and LRQ for P. Got aha moment of AUTO full-filling all CPU-cores with a Job and wrote the next post:

Eventually I feel the true Essence of Go

From the Scheduler mechanics I pick up the real essence of the TOOL - a server with multiple connections and automatic usage of all hardware-threads of a CPU cores. Only through the Scheduler I understood why the Go is really necessary. Go is a tool like an Axe, and I find what and how to chop wood by this axe. Go is a tool for creating a one executable file that starts well optimized server, and each connection to that server is handled by a light-weight UserSpace Thread.

The Idea of Go itself - to write a server that going to handle multiple TCP connections and automate the process of selecting next goroutine to be executed, and leaving for a while goroutines that stalled in waiting of Network response or any other kind of IPC activity. Here is a Root - to create a server where goroutine would handle a connection, and when to execute that goroutine the Go Runtime would decide, Scheduler if be precise.

This Idea become natural and could be literally touchable only after getting into the G/P/M model - where a Logical Processor P is an abstraction level between UserSpace Thread (a goroutine G) and OS Thread (M). Because each OS Thread M is halted/stopped when it waits for SystemCall to response, mean while P with it own G-swarm keep on "billowing". Thus Go - is a "swarm" or "club" of goroutings that pushed into CPU-cores by the Go Scheduler using P as middle slab abstraction of Logical Processor.

All essence of this model, all value of Go as a language is covered inside the Scheduler that allows bot NOT SO AWARE about how to handle new TCP connection cheap. As the algorithm minimize amount of expensive M (OS threads), substituting them by cheap G (Goroutines).

Go is not a modern C - how it use to be explained, Go is not a "Python". First of all Go is a cheap Goroutiens that are fit perfectly for serving HTTP requests. The aim of the Go is to reduce cost of a Concurrency Component on different platforms.

Uh... it was Tough! Love you mates. I love Go and William Kennedy and Kavya Joshi

Concurrency is a pattern, not execution.

lbvf50mobile — Sun, 14 Sep 2025 04:49:18 +0000

Concurrency is a pattern, not execution.

I just read Jonathan Sande's book about Dart. And found there an explanation of concurrency as a running code on one core, when parallelism execution on multiple cores. It is a "half-true" that may be useful for super-beginners who have Dart their first ever language, and have no CS background at all.

But concurrency is a pattern you separate your pieces of code to be able run them independently.

Here is a quote from Jonathan Bodner's "Learning Go" book:

Concurrency is the computer science term for breaking up a single process into independent components and specifying how these components safely share data.

I find it brilliant.

Should You Learn Perl in 2025?

lbvf50mobile — Fri, 05 Sep 2025 06:38:49 +0000

Perl in 2025 🐪

In 2025, I unexpectedly find myself enjoying Perl again — after years of Ruby and Go.

It sounds strange, but Perl hasn’t aged the way many people think. It’s not trendy, elegant, or fashionable — and yet, for certain kinds of work, it feels perfect.

Don’t Learn Perl. Learn UNIX.

Should you learn Perl in 2025?

Honestly — no. At least, not directly.

Start with UNIX system programming:

Work in the shell.
Understand file descriptors and streams.
Learn how processes are born, end, and communicate.
Get comfortable with Bash and other UNIX tools.

Once you understand these things, Perl becomes automatic.

You don’t “study” Perl — you realize you already understand it.

Perl Looks Messy — Until You See the Process

Here’s the key insight:

If you look at Perl from a syntax perspective, it looks messy.

But if you look at it through the lens of UNIX processes and streams, it suddenly becomes crystal clear and intuitive.

Perl isn’t designed like Python or Go, where you build large structures full of imports, frameworks, and abstractions.

A Perl script is simply a process:

born by the OS,
with three streams (STDIN, STDOUT, STDERR),
communicating with other processes,
manipulating files, signals, and descriptors.

When you see programs this way, Perl’s “cryptic” operators and shortcuts stop looking weird — they become beautifully compressed UNIX primitives.

Perl Is a Tool, Not a System

Modern languages — Python, Ruby, Go — often push you toward designing systems.

Perl isn’t like that.

Perl is a sharp tool for solving tasks quickly:

Renaming hundreds of files? One-liner.
Parsing gigabytes of logs? Two-liner.
Automating a messy workflow? Done before lunch.

You don’t worry about architecture, imports, or frameworks.

You just write the code, run the process, and move on.

Perl feels less like a language and more like an extension of your UNIX shell.

Why Perl Lost Popularity

Perl didn’t die — it simply stepped aside. The web changed.

In the early days, the web was simple: HTML pages, images, and tables.

Perl thrived because it could glue things together effortlessly.

But today’s web apps are massive, layered systems with complex UIs, APIs, and distributed backends.

Perl was never designed for this — so it faded from the spotlight.

Why Perl Will Never Fade Away

Perl still matters because it’s tied to UNIX itself.

Its syntax mirrors UNIX primitives directly.
It doesn’t hide processes and streams behind abstractions.
It becomes intuitive only after you understand the OS.

For sysadmins, DevOps engineers, and anyone who works close to the system, Perl remains reliable, concise, and insanely useful.

Perl doesn’t chase trends.

It doesn’t ship breaking changes every six months.

It’s like a ballpoint pen and a squared notebook: simple, stable, always ready when you need it.

Final Thought

Perl developers don’t see programs as abstract algorithms or piles of imports.

They see them as processes — living entities with streams, signals, and descriptors, talking to other processes in a UNIX world.

When you shift to this perspective, Perl syntax suddenly becomes obvious.

It’s not cryptic anymore — it’s just UNIX in shorthand.

Perl isn’t a language you learn.

It’s a language you grow into.

And once you do, it feels like home. 🐪