pingtrace 1.0: why I rewrote from npm to Go

#cli #go #networking

In March I shared the first version of pingtrace here on DEV.

That version answered the initial question: could I make the first minutes of a network troubleshooting session clearer by combining the commands I already run every day?

The answer was yes.

But after building more features, I realised the most important design decision was no longer the table layout or another flag. It was how a troubleshooting tool reaches the machine where it is needed.

Today, pingtrace reaches its first stable release as a Go CLI distributed as standalone binaries, with v1.0.1 being the current release.

The npm version proved the idea

The original TypeScript/npm version was useful, not a mistake. It let me iterate quickly and validate the workflow:

run ping and traceroute from one command;
accept a host, several targets, a CSV file or a CIDR block;
enrich results with DNS and network information;
export what happened instead of copying terminal output into a note.

It became obvious that the problem was real: during troubleshooting, I do not want to manually run ping, then traceroute or tracert, then reverse-DNS checks for individual hops, then copy results into a report.

But a network utility is frequently used in environments where adding a runtime is friction: a jump host, a clean workstation, a temporary diagnostic VM, or a controlled corporate endpoint.

Asking someone to install Node.js and a global npm package before they can diagnose the network felt backwards.

Why I moved pingtrace to Go

This rewrite is not a criticism of Node.js. The npm version helped pingtrace become a real project.

Go was simply a better match for the product I wanted to ship.

1. A diagnostic tool should be easy to carry

The Go release can be delivered as a standalone binary. The GitHub release already contains Linux packages, macOS archives and a Windows zip, plus checksums.

That matters for a tool intended to be used when something is wrong. The installation path should not introduce another runtime dependency before the first probe can run.

2. Bulk network probes are a natural concurrency problem

pingtrace can be pointed at a CIDR block or a CSV target list. In the Go version, bulk mode uses a worker pool and shows live progress while targets are processed concurrently.

The purpose is not to invent new probing logic. It is to make a repetitive diagnostic task practical when the input grows beyond one host.

3. A terminal tool deserves a terminal-native interface

The new version uses the Charmbracelet ecosystem for interactive terminal output:

streaming ping replies and traceroute hops;
a live MTR view with --mtr;
an interactive pingtrace config TUI;
width-aware tables so the important columns remain readable.

It still feels like a command-line tool, not a dashboard forced into a terminal.

What did not change

A design principle remains important: pingtrace does not replace the operating system probing tools.

It uses the system ping and traceroute tools on Unix-like systems, and ping plus tracert on Windows. It parses their output, executes work concurrently when useful, enriches the results, and presents or exports them cleanly.

The underlying probe remains the tool you already trust on that machine.

What is available in the Go release

The stable Go baseline includes:

ping + traceroute in one command, streaming results as they arrive;
live MTR mode with configurable cycles and interval;
single, multiple, CSV and IPv4 CIDR targets;
bulk mode with concurrency and an end-of-run summary;
public and private DNS enrichment, including split-horizon use cases;
optional ipinfo.io and PeeringDB enrichment for public hops;
CSV and JSON reports for analysis, evidence and why not future automation;
Linux, macOS and Windows support.

Try it

The recommended installation path for users is to download the appropriate pre-built package or archive from the latest GitHub release:

Download the latest pingtrace release

For developers who already have Go installed:

go install github.com/skhell/pingtrace/cmd/pingtrace@latest

Then:

# Configure it
pingtrace config

# Ping + trace with readable output
pingtrace 8.8.8.8

# Live MTR
pingtrace 1.1.1.1 --mtr

# Probe a CIDR block
pingtrace 10.0.0.0/30

# Export structured results
pingtrace 8.8.8.8 --export ./reports --json

What I learned from rewriting it

The lesson was not “rewrite everything in Go.”

It was this:

The right implementation choice depends on where a tool must run, how it must be distributed, and what users are doing when they need it.

For a network troubleshooting CLI, reducing the distance between “I have a connectivity problem” and “I have structured evidence” became more valuable than preserving the original runtime.

The npm version validated the idea. The Go version is the version I can confidently carry into real troubleshooting sessions with my team.

The project is open source and I would genuinely appreciate feedback from people who diagnose networks for a living.