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.
Top comments (0)