Turns out it’s incomparably more involved. Exploring practical networking patterns meant going beyond code: testing across different AWS instance types, experimenting with system-level tunings, validating behavior on multiple operating systems, and chasing edge cases that only show up under real traffic.

It’s been a deep dive—equal parts technical and exploratory. The work isn’t finished, but I’ve decided it’s worth sharing its current state. Honestly, I’m a bit tired and want to pause the guide writing for a while.

If you’re building high-throughput services, tuning TCP, or just trying to push Go’s networking stack further, you might find something useful here: goperf.dev/02-networking

Feedback, benchmarks, and counterexamples are always welcome.

The initial part of my guide is complete and relatively polished based on the feedback I have received. The next step is to develop the networking section because I believe Go is fundamentally about networking apps. Therefore, I’m not planning to post anything here for a while, at least until my new project reaches a reasonable state.

Birch Grove is just 40 minutes from Bishkek. Although I was concerned about the strong, foggy weather, it was an amazing opportunity for photography!

C++ is a powerful language, and I genuinely love it, but sometimes, even in modern versions, it lacks some surprisingly simple features. One such missing feature is switch on std::string. You’d think that by now, we could use a switch statement on strings just like we do with integers or enums—after all, Go has it! But no, C++ keeps us on our toes.

Why Doesn’t C++ Support switch on strings? Because “you only pay for what you use,” which is the standard C++ mantra. The switch statement in C++ relies on integral types. Under the hood, it works by converting the case values into jump table indices for efficient execution. But std::string (or even std::string_view) is not an integral type—it’s a more complex data structure. That’s why you can’t simply do:

So… how do we work around this? We need a way to turn strings into something switch can handle—like an integer. And that’s where hashing comes in. If we can map strings to unique integer values at compile time, we can switch on those instead. To do so, we need a user-defined literal operator and compile-time hash function. Something like this:

And, no magic, we have switch on strings!

There are some downsides to using this approach, specifically regarding hash collisions. Hashing introduces a small, but non-zero, risk of collisions. The proposed hash function, which multiplies the current hash by 131 and adds each character, is sufficiently effective for this use case. It provides a fast, compile-time method to map short, distinct string literals to unique integer values.

The choice of 131 as a multiplier contributes to achieving a reasonable distribution of values, thus reducing the likelihood of collisions, especially for a limited set of keywords like “topology,” “broadcast,” and others. The number 131 is commonly used in simple hash functions because it is a prime number. This helps to spread out the hash values more evenly across the available space, minimizing clustering and improving distribution properties. Additionally, it is small enough to maintain fast calculations while ensuring sufficient entropy accumulation over short strings.

Since the hash is computed at compile-time (using constexpr), there is no runtime overhead, and the resulting integer comparisons in switch statements remain O(1). This makes this approach both efficient and practical for situations involving a limited number of predefined strings. Furthermore, the risk of hash collisions is exceedingly low for a small number of strings. Using the Birthday Problem approximation, we can estimate that even with 1,000 unique strings, the collision probability remains below 0.000003%, making it practically irrelevant for most real-world applications where a switch statement would be used.

It’s ridiculous that in 2025, we still have to hack our way around something as basic as switch on strings in C++. But on the bright side, this was a perfect excuse to use a user-defined literal (operator””) finally! It’s one of those C++ features you rarely use, but it feels like a wizard when you do.

From a weekend trip to a nearby gorge. Why is it here? Because I love the mountains of Kyrgyzstan!

Mark Zuckerberg recently made a bold statement: AI will soon take over the work of mid-level engineers (Forbes). While this may sound like another tech CEO hyping AI, my latest experience with OpenAI’s o3-mini-high model suggests he might not be too far off.

Thanks to DeepSeek, OpenAI was compelled to make o3-mini-high available in a regular ChatGPT subscription instead of locking it behind a steep $200 paywall. I would never pay original $200 for a model, but since I already have the regular ChatGPT subscription, it was an obvious choice to try it out. With this in mind, I decided to experiment: Could o3-mini-high generate a functional Go codebase for my GFSM library?

The experiment

For context, GFSM is my Go Finite State Machine library, and I needed a new generator to extract and save state machines in formats like PlantUML and Mermaid. Writing such a generator requires a solid understanding of Go’s Abstract Syntax Tree (AST) package, something I hadn’t used in years.

Instead of writing the code myself, I handed most of the heavy lifting to o3-mini-high. The result? Almost all the code for the generator was AI-generated, with minimal manual adjustments. You can check out the generated code in this GitHub commit.

Code Quality: Mid-Level Engineer Competency (But Better Documentation)

The AI-generated code was not just functional—it worked on the first attempt! Unfortunately, it still needed some refinements:

• Improving logging and error handling
• Refactoring functions for better readability and maintainability

Overall, the output quality was comparable to that of a solid mid-level engineer—not perfect, but good enough. But here’s the kicker: Mid-level engineers usually suck at writing documentation (if they write any at all), while the documentation generated by o3-mini-high was actually pretty nice—clear, structured, and covering all the necessary details.

My productivity gains may not be impressive, but they are reasonably good for a first attempt:

• Time spent “coding” with ChatGPT: 3 hours
• The time it would have taken manually (my estimation): 6+ hours

The biggest time-saver? AI handled the AST package interactions, which would have required me to refresh my knowledge.

The Future of Software Engineering

What does this mean for engineers? I see this as an evolutionary shift rather than a revolutionary one—similar to previous transitions from Assembly to C or from C to Java. AI isn’t outright replacing engineers; it’s redefining what it means to be one.

The reality is that “boot camp engineers” and all other types of IT specialists without fundamental education are likely obsolete. Learning how to piece together APIs or follow tutorials won’t be enough when AI can do it better and faster, with approximately the same number of mistakes. Instead, fundamental Computer Science education—actual deep IT knowledge—becomes more critical than ever.

Why? Because understanding how and why a system works will distinguish those who can drive AI-assisted development from those who are replaced by it. Engineers with a strong foundation in algorithms, data structures, OS internals, networking, cybersecurity, and distributed systems will remain invaluable.

The AI-driven migration process will not be fast or simple. Even at first glance, there are a significant number of challenges ahead.

The crucial part of the AI migration challenge is system verification. If AI is going to generate more and more of our code, who is going to verify that it actually works? This is where Software Development Engineers in Test (SDET), or rather their next evolution—Software Verification Engineers (SVE), become indispensable. SVE will focus not just on functional correctness but also on formal verification, property-based testing, and system reliability. AI can generate code, but it doesn’t inherently know if it’s correct, secure, or efficient—that’s where human engineers must step in.

Another major challenge? AI-generated code will include security vulnerabilities. It’s not a question of if but when. AI models don’t “understand” security—they just generate plausible-looking code. This means:

• Secure coding practices must be enforced at the architecture level.
• Penetration testing and threat modeling will be more crucial than ever.
• Automated security analysis tools will need to evolve alongside AI-generated code.

Security engineers will no longer be an “optional” hire for big enterprises. Every AI-assisted development team will need a strong cybersecurity presence, or they risk shipping highly vulnerable software.

And the ultimate pain in the ass? AI suggests solutions for AI-generated code. This is where I start crying Right now, AI is great at creating “reasonable-looking” code but lacks true reasoning about correctness and intent. This means:

1. AI suggests code that works—but may be subtly wrong.
2. The engineer spots a bug and asks AI for a fix.
3. AI proposes a fix—but does it actually solve the problem, or does it introduce new ones?
4. Repeat until frustration kicks in.

This loop is already frustrating enough when debugging human-written code. With AI generating both the problem and the solution, we might end up in an infinite AI-fix cycle, in which engineers waste more time validating AI’s reasoning than fixing it manually.

How do I see my future? It’s perfectly incredible! With AI tools, I can do more, build faster, and focus on higher-level problem-solving instead of getting bogged down in boilerplate coding. AI is an amplifier, not a replacement—it extends my capabilities rather than diminishing my value.

And as for job security? I’m not worried in the slightest. With my specialization and experience in system architecture, distributed computing, and software engineering at scale, I will always have a place in this industry. If anything, AI clears the way for me to work on more interesting, complex problems—things AI alone can’t solve.

Using the maelstrom-challenges project as a starting point, I’ve extracted a C++ library called maelstrom-node. This library has been set up to work seamlessly with both Bazel and CMake, giving us a hands-on comparison of their approaches, strengths, and quirks.

The Project Structure

Here’s what the final directory layout for maelstrom-node looks like:

With this structure in place, the library could seamlessly integrate with both Bazel and CMake while maintaining clarity and modularity.

Building with Bazel

Bazel provided a relatively straightforward approach to compile maelstrom-node. The key was to define two critical files: MODULE.bazel and BUILD.bazel.

MODULE.bazel

The MODULE.bazel file in Bazel serves as a central place to define project metadata and manage dependencies. In this file, we use bazel_dep for some dependencies like spdlog and nlohmann_json, but not for rules_boost. Why the difference? It all comes down to how these dependencies are distributed and managed in Bazel’s ecosystem.

The bazel_dep function simplifies dependency management by fetching dependencies from the Bazel Central Registry (BCR)—a curated collection of Bazel-compatible packages. Dependencies like spdlog and nlohmann_json are available in the BCR, which makes adding them straightforward and efficient. Using BCR ensures version consistency and eliminates the need for custom configuration.

Why Not Use bazel_dep for rules_boost?

While popular, the rules_boost library is not often updated in the Bazel Central Registry, and while we have 1.86 release publicly available, BCR includes only 1.83. That’s why, we may need to configure its source using archive_override manually. This involves specifying details like the URL of the archive, the integrity hash, and the strip prefix.

Using bazel_dep wherever possible simplifies project configuration by leveraging the Bazel Central Registry, ensuring that dependencies are well-maintained and easy to integrate. However, when libraries like rules_boost aren’t available in the registry, Bazel’s manual configuration options, like archive_override, allow us to include them. This dual approach showcases Bazel’s flexibility and ability to adapt to different project needs.

BUILD.bazel

We cannot proceed without BUILD.bazel, as it serves as a location to store the actual app or library information.

The includes = [“include”] directive ensures Bazel can resolve headers using shorter paths like #include “maelstrom-node/message.hpp” instead of full paths like #include “include/maelstrom-node/message.hpp”.

To build the library, simply run:

Building with CMake

Adapting maelstrom-node for CMake brought its own set of challenges and solutions, exposing the limitations of this ancient technology. Despite its widespread use, even a straightforward migration effort highlighted CMake’s inherent bottlenecks and inefficiencies, reinforcing the idea that it might be time to consider moving on from it entirely.

Managing Includes

This is the first challenge you’ll face when trying to move from Bazel to CMake. CMake assumes #include paths are relative to the include directory, so you write:

Bazel, on the other hand, often requires full paths from the project root unless explicitly configured using the includes property in the cc_library rule:

While CMake’s shorter paths may appear cleaner within the source code and more natural for C++ developers, they abstract away the file hierarchy, making it harder to understand the project structure at a glance. As Bazel requires, full paths provide better context by explicitly showing where a file is located in the directory tree, making navigation and maintenance easier, especially in larger projects.

Setting Up CMake and VCPKG

Using vcpkg as the package manager is one of the ways to simplify dependency management if you are a CMake fun. After installing vcpkg, I initialized the project and added the necessary ports. The following command will create vcpkg-configuration.json and vcpkg.json files:

Another option for CMake dependency management is Conan. However, based on my experience, it’s even more complex than VCPKG, so I won’t discuss it in this post.

Making a CMakeLists.txt

Managing dependencies was relatively streamlined using the vcpkg package manager. The toolchain file was included dynamically to ensure compatibility, allowing for flexibility when configuring the build environment. This setup reduces manual configuration efforts while ensuring that dependencies are correctly integrated:

The main part of the CMakeLists.txt file is standard for CMake projects. The maelstrom_node library is defined as a static library with its core functionality implemented in message.cpp and node.cpp. Dependencies such as Boost, nlohmann_json, and spdlog are configured using find_package, ensuring they are available during the build process.

The find_package command works seamlessly in this setup because the vcpkg toolchain file is integrated into the project configuration. This file, specified as CMAKE_TOOLCHAIN_FILE, ensures that CMake knows the paths to all dependencies installed via vcpkg. When find_package is called, it searches these paths for the necessary configuration files, allowing dependencies like Boost, nlohmann_json, and spdlog to be located and linked automatically. This integration eliminates manual dependency management and ensures consistency across environments.

Finally, the installation section of the file ensures that the library can be packaged and reused in other projects. This includes specifying where the compiled library should be installed and ensuring that headers are copied to the appropriate directories:

This setup ensures the maelstrom-node library is compiled correctly and packaged in a way that makes it easy to integrate into other projects. While CMake offers much flexibility, its verbosity and reliance on external tools like vcpkg highlight some of its limitations in managing dependencies efficiently. CMake provides multiple approaches to configure and build the project. Ideally, you could use a preset configuration for simplicity, such as (based on the official documentation):

This approach is clean and convenient, leveraging a preset defined in CMakePresets.json. However, due to a defect in Visual Studio Code’s CMake Tools, environment variables like $VCPKG_ROOT cannot be directly used in CMakePresets.json. As a result, the preset may fail to locate the toolchain file correctly.

To address this issue, the following manual configuration proves reliable despite its ugliness:

Both methods ultimately lead to the same result, but the manual approach is necessary in environments where preset limitations or toolchain file paths are not resolved automatically. This highlights a minor inconvenience in the CMake ecosystem that can complicate workflows when integrating with tools like vcpkg.

Let’s integrate it!

Let’s integrate maelstrom-node into our application! This is the final step to bring everything together, and it’s where the differences between Bazel and CMake really stand out in terms of setup, dependency management, and usability. Here’s how each approach handles this critical task.

Bazel Integration

In Bazel, the integration is streamlined by declaring the maelstrom-node library as a dependency using bazel_dep and providing a git_override to fetch the library from its repository:

The library is then added as a dependency in the build rule for the application:

Bazel’s approach to dependencies is more declarative and centralized. Dependencies are fetched and managed globally at the repository level, ensuring consistency across the project. The use of bazel_dep and overrides simplifies versioning, and Bazel’s caching mechanism avoids redundant downloads and builds, leading to faster iterations.

The compilation process is still very straightforward for the final app:

CMake Integration

The CMakeLists.txt file for the integration is relatively standard, with one notable addition: the use of FetchContent to fetch and include the maelstrom-node library directly from its Git repository. This setup is straightforward, as shown below.

This snippet looks pretty and allows the library to be built alongside the application. But, it’s not without its drawbacks. Unlike Bazel, CMake relies heavily on external tools like vcpkg for dependency management. Unfortunately, vcpkg requires a complete list of dependencies to be declared for every project (is it a defect? It looks so to me.). In this case, both echo-cpp and maelstrom-node must redundantly list their dependencies in echo-cpp’s vcpkg.conf file. This duplication can be tedious and error-prone, especially in larger, more complex projects.

Another significant limitation is CMake’s lack of integration with other ecosystems like Rust and Cargo. If you already have existing integration tests written in Rust, as I have, CMake cannot reuse them natively. This inability to leverage cross-language infrastructure is one of CMake’s most significant downsides and a stark contrast to Bazel, which excels in mixed-language project support.

While this integration approach works, it highlights the challenges of relying on CMake for projects beyond simple use cases, especially when dealing with multiple dependencies or mixed-language ecosystems.

Recently, I decided to extend my Maelstrom challenges with a C++-based test to explore how Bazel can simplify managing multi-language dependencies and streamline development workflows.

Why Bazel for Multi-Language Projects?

Bazel’s design philosophy emphasizes performance and scalability, making it an excellent choice for projects that involve multiple languages. With its support for Bazel modules, adding dependencies is as simple as declaring them in a MODULE.bazel file. For example, integrating the popular logging library spdlog is straightforward:

However, not every library supports Bazel modules natively, which can complicate things. A case in point is BOOST, a widely used C++ library. Adding BOOST required a bit of additional setup, fortunately, we have rules_boost project:

While the setup for BOOST is less elegant than for spdlog, Bazel’s flexibility ensures that even complex dependencies can be integrated efficiently.

Improving Code Navigation with Hedron’s Compile Commands

Another critical aspect of C++ development is code navigation. Generating a compile_commands.json file makes life easier for developers using tools like Vim or Emacs. Thankfully, Bazel has a powerful solution: Hedron Compile Commands Extractor.

It’s pretty easy to set it up:

1. Add the dependency to your MODULE.bazel file:

2. Generate the compile_commands.json file by running:

This simple addition dramatically improves the developer experience, making it easy to navigate and understand the C++ codebase. What I love even more there is NeoVim’s lsp-config provides excellent navigation and auto-completion with the generated compile_commands.json.

Building C++ Support in Maelstrom challenges

The process of adding C++ support to the Maelstrom challenges project involved several key changes. In this commit, I outlined the required modifications to the MODULE.bazel file to set up the necessary dependencies. This provided the foundation for implementing a basic Maelstrom protocol in C++.

The implementation itself, along with a simple echo app as a proof of concept, can be seen in this commit. This example showcases how Bazel simplifies managing dependencies and building multi-language projects while allowing for robust testing and experimentation.

Harnessing Cargo-Based Dependency Management

Bazel’s ability to integrate with Cargo, Rust’s native package manager, is a standout feature. This approach preserves compatibility with the Rust ecosystem while allowing projects to benefit from Bazel’s powerful build features. By using rules_rust, a Bazel module can seamlessly import dependencies defined in Cargo.toml and Cargo.lock into its build graph.

It was pretty easy to feed dependency information from Cargo to Bazel. The only tricky part is Cargo workspaces. If you use a Cargo workspace like I do, you should list all Cargo.toml files under the manifests section in MODULE.bazel file.

This setup allows Bazel to parse and manage dependencies from multiple Cargo.toml files. The crate_universe extension ensures that Bazel respects the dependency versions specified in the lockfile, providing reproducible builds. This approach is particularly practical in projects with nested crates or submodules, as Bazel automatically consolidates them into a unified build graph.

Integrating with Cargo in this way provides the best of both worlds. Developers can continue using Rust’s native tooling for development while leveraging Bazel for its scalability and advanced dependency management. Although this dual-system approach adds some complexity, the flexibility it offers is invaluable for scaling projects and ensuring compatibility with the broader Rust ecosystem.

Migrating from Cargo.toml to BUILD.bazel

The next step after making a proper MODULE.bazel file is to create BUILD.bazel. It’s basically a translation of all component-level Cargo.toml files into BUILD.bazel one-by-one.

In Bazel, each bin section from Cargo.toml should be translated into a rust_binary definition in BUILD.bazel. Another important part here is @crate_index which refer to crate.from_cargo(name = “crate_index”, …) command from the MODULE.bazel described above.

This shift ensures that Bazel can handle the entire build lifecycle, from compiling dependencies to linking final binaries. While Cargo.toml defines dependencies and build metadata, BUILD.bazel brings this into Bazel’s optimized dependency graph. This transition is seamless for developers familiar with both systems and ensures scalability as the project grows.

Simplifying Integration Testing with Bazel

Integration testing is another area where Bazel simplifies workflows compared to Cargo. In Rust’s native system, it’s not straightforward to ensure that an application is built before a test requiring that application is executed. With Bazel, this process becomes effortless.

Consider a BUILD.bazel setup for integration tests:

This configuration defines a rust_test that explicitly depends on the //echo binary. Bazel ensures that the binary is built before the test is executed, avoiding any manual coordination. Shared utilities used during the tests are included in a rust_library, promoting code reuse. Additionally, test resources like :maelstrom/lib/maelstrom.jar are specified as data, ensuring they are available during execution.

It took some Googling to figure out how to access external resources like maelstrom.jar for the Rust integration test. However, it’s simpler than it appears at first. We basically need to retrieve the value from the RUNFILES_DIR environment variable, which points to a temporary Bazel-managed directory, and then add the “_main” folder on top of it.

Bazel’s approach eliminates the need for custom scripts or workarounds, streamlining the test lifecycle and ensuring reliable, reproducible results. This simplicity becomes increasingly important as projects grow, where manual processes can hinder productivity and introduce inconsistencies.

Why Go is My Default Choice

For most non-performance critical scenarios, Go is my default, no-brainer choice. It has a clean build system, excellent tooling, and a developer experience that doesn’t make me dread the setup process. Go’s simplicity allows me (and any level team) to focus on solving the problem rather than wrestling with the environment. Yet, this time, I decided to take a different path.

Revisiting Rust

My relationship with Rust has been a journey of highs and lows. I was initially drawn to it during its early days, around Rust 0.1, when the language was brimming with potential. What captivated me back then was its promise to be a kind of “Erlang on steroids”—a language that combined Erlang’s lightweight concurrency model and fault-tolerant programming paradigms with the performance and control of a systems language.

Unfortunately, with the release of Rust 1.0, much of that original vision shifted. Green threads—a key feature that enabled lightweight concurrency and aligned closely with the “Erlang on steroids” dream—were abandoned. The decision to remove them in favor of direct integration with the OS threading model made sense for speeding up the 1.0 release. Still, it marked a significant departure from the language’s earlier aspirations.

Adding to the change was a complete overhaul of Rust’s memory model, which moved toward its now-iconic ownership system. While the new model introduced unparalleled safety and performance guarantees, it also made the language more complex and less approachable, particularly for those who were excited about its initial simplicity.

These shifts left me feeling that Rust had transformed into “just another overcomplicated C++-like language,” albeit with better safety features and tooling. Over time, I moved away from Rust, drawn instead to more straightforward and developer-friendly languages for most of my work.

But now, years later, I’m giving Rust another shot while having plenty of free time. Its strong presence in emerging fields like Web3 has made it impossible to ignore. The language has clearly matured, and while its evolution may not have aligned with my initial hopes, I’m curious to explore how its modern ecosystem can contribute to my work. Rust may no longer be the “Erlang on steroids” I once envisioned, but it’s carving out a unique space for itself, and I’m eager to see how it fits into my technical journey moving forward.

Comparing Tooling and Developer Experience

My return to Rust brought some pleasant surprises—and a few frustrations. Here’s a breakdown of my observations:

Cargo vs. Build Systems

• Cargo, Rust’s build system and package manager, is undeniably better than CMake—but then again, that’s not a high bar. Let’s be honest: CMake is an exercise of frustration for most developers.
• Comparing Cargo to Bazel: Cargo feels more straightforward and approachable, but it requires more power and flexibility than Bazel. In that sense, Bazel is still the gold standard for me in large, complex projects.
• Go’s build system, however, remains my favorite. Its simplicity and convention-over-configuration philosophy are unmatched.

IDEs and Editor Support

Tools like RustRover have evolved to deliver an exceptional development experience, far surpassing the likes of CLion or most other C++ IDEs. The level of integration with Cargo, code analysis, and developer assistance is simply stellar.

Compiler Diagnostics

One of Rust’s standout features is its compiler diagnostics. The clarity and detail in Rust’s error messages are leagues ahead of what you get with Clang or GCC. It’s an area where Rust truly shines, making debugging and iteration smoother. However, it’s not all perfect.

When it comes to borrowing-related errors, the story changes. These errors often feel nonintuitive, even for developers familiar with Rust’s ownership model. Despite the compiler’s best efforts to provide explanations, deciphering and resolving these errors frequently requires external help. You’ll find yourself Googling extensively or turning to tools like ChatGPT (model 4.0 preferred) to figure out what’s going wrong and how to fix it. This aspect of the Rust learning curve remains a significant hurdle for newcomers and a source of frustration even for experienced developers.

While the error diagnostics are still better than those offered by C++, the borrowing system’s complexity can sometimes undermine the excellent developer experience.

Reflections and Future Plans

Sometimes, stepping back into an ecosystem with a fresh perspective can reveal how much has changed—for better or worse.
Rust is no longer just the “overcomplicated” C++ sibling I left behind. It’s still a language with comparable complexity to C++ (which means it’s overcomplicated) but with a critical difference: compile-time sanitizers you need in C++ baked into its Rust core. This feature transforms those complexities into tools that actively guide you toward safer, more robust code.

Last but not least, as I’d mentioned above, I do not want to setup a proper C++ pipeline either

What Constitutes Minimal CI?

For a project to benefit from CI without excessive complexity, it should include the following essential components:

1. Project Compilation: Verify that the codebase is always in a buildable state.
2. Unit Test Execution: Ensure the core functionality works as expected.
3. Static Code Analysis: Catch bugs and enforce coding standards before they become an issue.

Why GitHub Actions?

GitHub Actions offers a simple yet powerful CI/CD platform that integrates seamlessly with GitHub repositories. Its ease of use makes it accessible even for developers without extensive DevOps experience. In fact, with just a few workflows, you can have a robust CI pipeline for small projects.

For example, for my small open-source Go library GFSM, three workflows—build, static-check, and publish—are sufficient.

Setting Up Your Workflows

1. Build Workflow

The build workflow ensures your code compiles and passes tests on every push or pull_request to any branch:

2. Static Code Analysis

Static analysis helps maintain code quality by catching potential issues early. The best Go linter at the moment – staticcheck, provides an excellent integration with GitHub actions out of the box. Like the build workflow, this workflow runs on every push or pull_request:

3. Publish Workflow

Publishing a new version to pkg.go.dev ensures that users always have access to the latest updates. The tricky part is triggering the pkg.go.dev proxy to update its cache for new versions. On comparison with build and static-check workflows, we should trigger new version publication only on a new tag push in a semantic versioning format. Here’s how you can set up this workflow to track new tags and ping the proxy:

Reusable Composite Actions

Both the build and static-check workflows require the same environment setup. To avoid duplicating this logic, use GitHub Actions’ composite feature to create a reusable setup action:

This composite action ensures consistency and simplifies workflow maintenance.

Looking Ahead

Go currently relies on the tools.go file for dependencies, which I find a too ugly approach and prefer to have some extra go get/install/generate in my environment setup yaml file. But Go 1.24 promises a much cleaner approach with its “track tool dependencies in go.mod (#48429)” feature. Once available, it will streamline dependency management much more excellently.

Final Thoughts

Implementing minimal CI with GitHub Actions requires minimal effort but yields significant benefits. By automating builds, tests, and static analysis, you can ensure your project maintains high quality and is always ready for deployment. For small projects, this setup is a no-brainer, and GitHub Actions makes it easy to get started.

Real-World Use Case: Two-Phase Commit Protocol

1. Define Your State Machine

graph TD;
    Init-->Wait;
    Wait-->Abort;
    Wait-->Commit;

2. Enumerate All Possible States

3. Define State Behaviors

– OnEnter: Called when entering the state.
– OnExit: Called when leaving the state.
– Execute: Handles events and determines the next state.

For example, the initState implementation might look like this:

4. Build the State Machine

Here, coordinatorContext holds transaction details, such as the number of participants and the commit ID.

5. Run the State Machine

Learn More