Why Not Rust?

There’s been a lot of debate lately about language choices, especially after Microsoft announced that the new TypeScript compiler is being rewritten from TypeScript to Go. This sparked a fresh round of questions on social media: why Go, and why not Rust? It’s a fair question, and one that applies to grlx as well. The answer, in both cases, is rooted in pragmatism.

I’ve written extensively in the past on why I chose Go over Python, but many of those arguments for Go over Python also apply to Rust over Python! Between Go and Rust, Go continues to be the language of choice for teams that prioritize development speed, ecosystem maturity, and operational simplicity. Let’s take a look at why.

Familiarity and Developer Productivity

Let’s be honest: I’m a Go developer by trade. That familiarity translates directly into productivity. When building grlx, being able to quickly write, test, and maintain code is more important than chasing theoretical speed or memory guarantees. My experience with Go allows me to implement features quickly and pivot when needed. I’ve written production Rust, and I respect it, but Go is where I’m fastest.

Performance in Practice

Rust shines when you need tight control over memory and raw performance. But, grlx isn’t compute-bound. It shells out to system commands, modifies configuration files, and reacts to asynchronous events. The bottlenecks are I/O and process orchestration, not CPU or memory allocation. While Rust’s performance profile is technically superior, those benefits wouldn’t be realized in a tool like grlx. In practice, Go’s performance is more than sufficient.

Type Systems and Safety Guarantees

Rust’s type system is more advanced. That’s a fact. But for grlx, it’s not a clear win. Much of grlx’s core functionality involves invoking and managing external processes, tasks that don’t gain much from advanced type guarantees. In many cases, to maintain portability across distributions, the safest way to perform a task is to shell out and handle the output explicitly. Trying to enforce strict safety via Rust’s type system often leads to awkward wrappers and, ironically, more unsafe code. If you’re already bypassing the compiler’s guarantees, the rest of the system doesn’t benefit much from theoretical safety.

Iteration and Flexibility

The grlx project is still actively evolving. In this phase, fast iteration is key. Go’s lightweight syntax and forgiving compiler make it easy to prototype, refactor, and shift architectural decisions as the product matures. Rust’s compiler enforces rigor early on, which can be helpful in large, stable systems—but it often gets in the way during the creative stage. Go lets me move faster.

Ecosystem and Tooling

Go’s ecosystem is mature and focused, especially in the realm of system tooling. From HTTP servers to CLI libraries, the tools I need already exist and are well-maintained. For missing pieces, writing custom packages is straightforward. I’ve built wrappers for systemd, SysV Init, and OpenRC support. In Go, this feels natural. Rust’s ecosystem for system-level orchestration is improving but still lags behind in simplicity and breadth.

Readability and Auditing

The grlx sprout runs with root permissions, so transparency is critical. Go’s straightforward syntax and lack of metaprogramming make it easy to understand and audit. Other developers, ops engineers, and security reviewers can all look at the code and follow what’s going on. Rust, while expressive, often introduces cognitive overhead via macros, lifetimes, and traits. This makes security reviews more complex. With Go, what you see is what you get.

Security via Simplicity

Using Go’s standard library reduces reliance on external dependencies. That matters. Every third-party package increases the surface area for supply chain attacks. With Rust, even basic functionality often comes from external crates, which need to be audited, version-locked, and maintained. Go includes batteries for most common tasks, making it easier to write secure, auditable, and maintainable code from day one.

Conclusion

Rust is an excellent language, and I wouldn’t hesitate to use it in the right context. But grlx isn’t a performance-critical game engine or a systems kernel. It’s a fleet orchestration tool. For that purpose, Go’s fast iteration cycle, strong ecosystem, simple deployment model, and security-minded standard library make it the better choice. This isn’t about hype or language tribalism. It’s about building the right tool with the right technology—and for grlx, Go is it.

If you want to learn more about the tradeoffs between Go and Rust (or TypeScript!), you can check out my course on LinkedIn Learning. It’s free!

Comparing Golang vs Rust from Choosing the Right Back-End Language: TypeScript, Go, or Rust for Your Greenfield Project by Tai Groot