Programming Language Learning Series on Mi&Bee Blog

Why Go: A Language Built for Engineering

Thu, 15 Jan 2026 09:00:00 +0800

Why Go?

You might ask: why learn Go? There are so many programming languages—Python is simple and easy to learn, Java has a mature ecosystem, C/C++ delivers unmatched performance, and JavaScript is everywhere. What makes Go special?

Go’s value lies in engineering practice: it aims language design squarely at team collaboration and large-scale software development, not at syntactic expressiveness or theoretical purity.

Go was created in 2007 by a team of engineers at Google with one goal in mind: solve real-world pain points in software development. They wanted fast compilation, simple deployment, easy concurrency handling, and maintainable code. They weren’t looking for the “coolest” language—they wanted the most practical one, where developers can write code quickly, compile fast, run efficiently, and keep things simple and maintainable.

Basic Syntax: Variables, Types, and Control Flow

Wed, 28 Jan 2026 14:30:00 +0800

This article is based on Go 1.26.

In the previous article, we discussed Go’s design philosophy and your first Hello World program. This time, let’s dive directly into syntax—variables, types, control flow, functions, composite types, and pointers. The core goal is simple: enable you to read and write basic Go code.

Go’s syntax design philosophy is simplicity over complexity—eliminating unnecessary syntactic sugar while keeping things clear and intuitive. If you’re coming from another language, you’ll find Go’s learning curve relatively gentle because it has few syntactic features, but each one is practical.

Interfaces and Generics: Go's Core Abstraction Mechanisms

Thu, 12 Feb 2026 10:00:00 +0800

In the previous articles, we covered Go’s basic syntax and concurrency model. Now let’s dive deep into the two core components of Go’s type system—interfaces and generics. These two constitute the foundation of Go’s abstraction mechanisms: interfaces provide runtime polymorphism based on behavior, while generics bring compile-time abstraction with type safety.

Go’s design philosophy always emphasizes simplicity. Interfaces adopt implicit implementation, meaning no explicit declaration of implementation relationships is needed. As long as a type possesses the method set required by an interface, it automatically implements that interface. This duck typing style makes code more natural and reduces unnecessary coupling.

Error Handling: Go's Multi-Return Value Approach

Wed, 25 Feb 2026 10:00:00 +0800

Go’s error handling philosophy is “simple, explicit, controllable.” Every function that can fail can return an error value, and the caller must explicitly handle it. No exceptions, no implicit propagation—everything is in plain sight.

The error Interface: One Value, One Method

Go’s error interface is minimal: just one Error() string method.

go


1
2
3


type error interface {
 Error() string
}

This means any type that implements Error() string is an error. The Go standard library provides many built-in error types, most commonly errors.New and fmt.Errorf.

Concurrency: The Art of Goroutines, Channels, and Context

Thu, 12 Mar 2026 14:00:00 +0800

Concurrency is the core feature that distinguishes Go from other languages. Unlike C++/Java’s thread model, and unlike JavaScript’s single-threaded event loop, Go provides a set of concurrency primitives — goroutines, channels, and context — that let you write high-performance concurrent programs with relatively straightforward code.

This article covers the technical details of Go’s concurrency model: the underlying scheduling mechanism, the implementation of channels and context, common concurrency patterns, and performance optimization and best practices.

Standard Library, Testing, and Toolchain: A Panoramic View of Go Engineering Practices

Thu, 26 Mar 2026 09:00:00 +0800

After three articles of our journey—why choose Go, basic syntax and concurrency, interfaces and generics—we’ve reached the finale of the Go chapter, time to connect the engineering practices.

Go’s engineering capacity also shows up in its standard library, testing framework, and toolchain. They make up the daily working environment for Go developers and underpin rapid construction of reliable, maintainable software.

Why Rust: A Language Pursuing Zero-Cost Abstractions from a Go Perspective

Fri, 10 Apr 2026 09:00:00 +0800

This article is based on Rust 1.82 (released on 2026-01-23, current latest stable version). Rust is a modern systems programming language proven in production. Official documentation is at doc.rust-lang.org, and installation guide is at rust-lang.org/tools/install/.

Why Rust?

If you’ve already mastered Go, you might ask: why learn Rust? Rust exists to fill the performance and control gap that Go leaves open.

Go has conquered cloud-native and microservices domains with its extremely low learning curve, excellent concurrency model, and fast compilation speed. But its garbage collector (GC) and fixed runtime make it constrained in systems programming, embedded, and high-performance scenarios. When you need more precise memory control, lower latency, or work in embedded environments without OS kernel support, Go’s GC becomes a burden.

Basic Syntax: Variables, Types, and Pattern Matching

Wed, 22 Apr 2026 14:00:00 +0800

In the previous post, we discussed why Rust is worth learning and how to run your first Hello World. This post dives directly into syntax—variables, types, control flow, functions, and pattern matching. The core goal is simple: enable you to read and write Rust code.

If you have a Go background, none of these concepts will be unfamiliar. I’ll provide comparisons at key points to help map your existing knowledge to Rust.

Ownership and Borrowing: The Core of Rust Memory Safety

Wed, 06 May 2026 10:00:00 +0800

This article is based on Rust 1.80+.

If you have a Go or Java background, the ownership system might be the most confusing concept in Rust. Go has a garbage collector (GC), and you rarely need to worry about when memory is freed. Rust takes a completely different approach—compile-time ownership rules guarantee memory safety, with zero runtime overhead.

The ownership system is the soul of Rust. It solves two classic problems: how to guarantee memory safety without using GC, and how to avoid data races. In other languages, these problems either require runtime checks or require extreme developer caution.

Traits and Generics: Rust's Type Abstraction System

Thu, 14 May 2026 10:00:00 +0800

In the previous articles, we explored Rust’s ownership system, error handling, and module management. Now we dive into the two core components of Rust’s type system—traits and generics. These form the foundation of Rust’s abstraction mechanisms: traits provide compile-time behavioral constraints, while generics bring type-safe parametric programming.

Rust’s trait system has similarities to Go’s interfaces, but the essence is different. Go’s interfaces use implicit implementation with duck typing, while Rust’s traits are explicitly declared contracts. More importantly, Rust’s traits combined with generics enable complete type checking and monomorphization at compile time, achieving zero-cost abstraction.

Error Handling and Lifetimes: Result, Option, and Compile-Time Borrow Checking

Fri, 22 May 2026 10:00:00 +0800

If you’re used to Go’s if err != nil, encountering Rust’s error handling for the first time can be confusing. Go’s philosophy is explicit multi-return values, where errors are just ordinary values. Rust, on the other hand, elevates error handling to the type system level—a function that might fail must declare it explicitly in its return type. This design brings zero-cost abstractions but also introduces the two concepts that give beginners the most headaches: the Result<T, E> enum and lifetime annotations.

Standard Library, Concurrency, and async: Rust Chapter Finale

Sat, 30 May 2026 15:00:00 +0800

After the journey of the first four articles—ownership and borrowing, type system, error handling, and pattern matching—we have now reached the Rust chapter finale, time to tie the scattered knowledge together.

This article focuses on Rust’s standard library concurrency tools and the async/await ecosystem. These are the most interesting comparative points between Rust and Go in the concurrency domain: Go makes concurrency look simple through goroutines and channels, while Rust makes concurrency safe and reliable through strict type systems and ownership constraints.

Why Zig: A New Systems Language from a Go/Rust Perspective

Sun, 21 Jun 2026 09:15:00 +0800

This article is based on Zig 0.16 (released 2026-04-13, the latest stable release). Zig is a rapidly evolving modern systems programming language. Its source repository has moved from GitHub to Codeberg, and the official download page is at ziglang.org/download/.

Why Zig?

If you already know Go and Rust, you might ask: why look at a third systems language? Zig sits between the two, attempting to combine C’s lightness, Rust’s modern toolchain, and Go’s low barrier to entry.

Basic Syntax: Ramp Up on Zig with Your Go/Rust Experience

Mon, 22 Jun 2026 14:30:00 +0800

This article is based on Zig 0.16.

In Part 1 we discussed why Zig is worth learning and how to run your first Hello World. Now it’s time to dive into the syntax—variables, types, control flow, functions, and generics. The single goal is to make you able to read and write Zig code.

If you have Go or Rust experience, none of these concepts will feel entirely new. I’ll draw comparisons at key points to help you map your existing knowledge.

Error Handling: A Third Way Beyond Go and Rust

Tue, 23 Jun 2026 10:45:00 +0800

This article is based on Zig 0.16.

Three Error Handling Paradigms

Error handling is one of the most debated topics in programming language design. Go’s multiple return values, Rust’s Result<T, E> enum, and Zig’s error union type represent three fundamentally different philosophies. This article assumes you have Go or Rust experience and uses that as a reference frame to understand Zig’s design.

Go: Multi-return + if err != nil

Go’s philosophy is “explicit over implicit” — functions can return multiple values, and the convention is that the last return value is error. Every call site must handle it:

Zig Memory Management: The Explicit Allocator Pattern

Wed, 24 Jun 2026 16:20:00 +0800

This article is based on Zig 0.16.

In the previous articles we covered Zig’s basic syntax and error handling. Now we arrive at the most distinctive part of Zig—memory management.

If you come from Go or Rust, Zig’s memory philosophy will feel unfamiliar: it provides neither garbage collection nor an ownership system. Instead, it chooses a fundamentally different path—the Allocator Pattern. The core convention is remarkably simple, yet far-reaching:

Any function that might allocate memory must accept a std.mem.Allocator parameter.

Structs and comptime: The Power of Compile-Time Computation

Thu, 25 Jun 2026 11:00:00 +0800

This article is based on Zig 0.16.

In the previous post, we covered Zig’s error handling and memory management — lightweight try/catch fault tolerance, and the explicit allocator-passing philosophy. Now we enter Zig’s most essential territory: structs and methods, and the soul of Zig — compile-time computation (comptime).

If you come from Go, you’ll appreciate how Zig keeps things simple by defining methods directly inside the struct. If you come from Rust, you’ll see a different take on the impl block pattern. And comptime opens a path to “types as values” metaprogramming beyond Go generics and Rust traits.

Zig Standard Library, the I/O Interface, and Concurrency: Tying It All Together

Fri, 26 Jun 2026 15:40:00 +0800

This article is based on Zig 0.16.

After five installments covering syntax, error handling, memory management, compile-time computation, and the build system — we’ve arrived at the finale. Time to tie it all together.

Version 0.16 is a convergence point of two major changes: the Unmanaged migration of standard library containers, and the introduction of the new std.Io interface. These transformations deeply affect how Zig code is written. This article explores both, closes with three-language comparison cases, and provides a learning roadmap and resources.