Building a Zero-Dependency Networking Tool with Go, C++, and Zig

Distributing software is rarely as simple as writing code and sending a binary. The reality is often messy: you have to consider multiple CPU architectures, a variety of operating systems, conflicting system libraries, and an unpredictable set of dependencies. It’s a maintenance headache.

This complexity is one of the many reasons why developers love the Go programming language. Go makes it easy to build statically linked, self-contained executables — no runtime dependencies, no surprises. Just a single binary you can copy to a server and run.

At NanoPing, we wanted the same kind of simplicity for our networking tool: np.

Inside np: Go, C++, and the Zig toolchain

Our np tool follows a similar philosophy to Go, but with a more customized stack under the hood:

• The control plane is written in Go
• The data plane is written in C++

Now, building a combined executable from two different languages is already tricky — but what makes our setup special is the toolchain we use: Zig.

Zig is a modern programming language that also includes a powerful Clang-based toolchain capable of compiling C and C++ code. In fact, Zig can act as a drop-in replacement for GCC or Clang, but with one major advantage:

Zig makes it easy to produce fully statically linked executables that just work on virtually any Linux system.

Here’s an excellent write-up from Zig creator Andrew Kelley explaining how this works: 👉 Zig cc: a powerful drop-in replacement for gcc/clang

One File. Everything Included.

We took it a step further. With np, we bundle everything — from the CLI, dashboard, web UI, and even external dependencies — into a single, self-extracting executable.

That means no installers. No Docker images. No surprises.

Just:

$ sudo np up

…and you’re up and running.

📘 Quick start here

Portability That Just Works

Our distribution strategy means that as long as you have:

• A Linux kernel ≥ 3.10
• Either an ARM or x86 CPU

You're good to go. It runs on everything from Raspberry Pis to cloud instances.

Why We Do This

When you're building low-latency networking services, the last thing you want is for your developers to struggle with dependencies or incompatible environments. They should be spending time testing performance — not debugging build systems.

That’s why we’ve focused on:

• Simple deployment
• Zero configuration
• Maximum portability

You bring the hardware. We bring the networking.

Want to try it?

🔗 Check out NanoPing

📚 Docs and quick start