Rants on cache cascade

Why I Chose Go for grlx Instead of Rust

tai@taigrr.com (Tai Groot) — Wed, 11 Jun 2025 22:31:25 +0600

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

Frontend FOMO: A Hype-Driven Ecosystem

tai@taigrr.com (Tai Groot) — Tue, 12 Sep 2023 18:19:25 +0600

Ah, JavaScript development, the ever-evolving frontier of web development. New runtimes, package managers, libraries, frameworks, module systems, and packages pop up like mushrooms after a rainstorm. Every week, it feels like a tech carnival, with flashy new tools and configurations tempting you to hop aboard the latest hype train.

Let’s start by acknowledging that innovation is a positive force for good. The JavaScript ecosystem is a hotbed of creativity, where developers are constantly pushing the boundaries of what’s possible. New libraries and frameworks emerge to solve real-world problems, making developers’ lives easier and applications more powerful.

Innovation itself is not the problem. The problem is the collective behavior of developers, often resembling a herd of lemmings, that can lead to chaos. Front-end (and consequently Full-Stack) developers seem to be particularly susceptible to FOMO and analysis paralysis. Once (or even before) a developer starts to feel comfortable with a tech stack, a new kid on the block arrives, and some begin suddenly questioning every decision they’ve ever made.

Imagine this scenario: you’ve been working with React for a while, building beautiful (let’s be honest, janky but functional) user interfaces, and you’re finally getting the hang of it. But wait, Svelte comes along and promises to revolutionize the way you think about front-end development. You start to wonder if you’ve been living in the Stone Age and if Svelte is the key to enlightenment.

Perhaps you’re knee-deep in Node.js, happily coding away server-side, when Deno makes its grand entrance, boasting improved security and a new approach to runtime environments. Suddenly, your Node.js project feels like last year’s news, and you can’t help but question if Deno is the future. Nota bene: Bun was released right before this article was published, and its release only makes my point stronger.

FOMO leads to a never-ending cycle of tool evaluation, configuration tweaking, and second-guessing. It’s like being stuck in a revolving door that never stops spinning. You find yourself constantly switching between libraries and frameworks, never truly mastering any of them, and your deliverables suffer from analysis paralysis.

I’ve been picking on Front-end developers, but let’s be fair: backend developers face choices too; I’m all too familiar with the Go / Rust / Zig argument (and I’ll save Ruby on Rails and PHP for a future date). There are so many general-purpose languages (GPLs, as opposed to domain-specific languages, DSLs) that, of course, there is bound to be arguing, evangelizing, and a general lack of consensus.

However, I would posit the arguments that arise over which backend language to use are of an entirely different class than the arguments that arise within the JavaScript ecosystem.

Your average Go developer and Python developer get into an argument over whose language is Better. What are their talking points? Typically, the Python developer will criticize Go for having a smaller package ecosystem, and no significant support for Machine Learning, praising Python for ease of development – it’s often faster to get a prototype out the door for Python than for Go.

The Go developer will then come back complaining about Python’s slower speed, dynamic typing, and runtime package management. If both parties are reasonable, they may agree that while both languages are “General Purpose,” there are still “domain preferences” for each language. In other words, there are problems and use cases where one language is the better tool for the job, even if both could work. (I’m aware the comparison between a compiled and interpreted language may be more extreme than between Go and Rust or Python and Julia, but the point still carries.)

Now look at an argument between a Vue user and a React user. The Vue user might complain about JSX syntax, the corporate backing (Meta), and the relaxed project scaffolding (the strict 1:1 component to file rule means all Vue projects end up organized somewhat the same, without requiring developers to search across files to find where a component is defined.) Conversely, React developers insist ‘the future is React’, more developers know React (hiring talent is easier), and complain the strictness of Vue’s scaffolding leads to verbose, sprawling directories and ReallyLongAndSpecificComponentNames.vue (getting Java flashbacks, anybody?)

Of course, I won’t pretend all arguments about these libraries are the same. React does mobile better (thanks to React Native). Vue does incremental adoption better. (React and Vue have gone back and forth on which has better performance.)

So, while there are Domain arguments to be had across JavaScript frameworks, the point I am making here is that the loudest and oft repeated disagreements over JavaScript stacks are about Developer Experience (DX) and preference, rather than which stack can do the job better in production.

I still don’t think these arguments over preference are The Problem With The JavaScript Ecosystem™. Different developers will make judgment calls for one choice over another. But if the tools can all (mostly) get you to the same, functional result, and it’s really a DX and preferential choice question, FOMO is the problem. The most important factor for seamless DX is the stability of the ecosystem: building components and shipping changes to production should become muscle memory over time. This muscle memory can never develop when the developer is constantly switching between tools and libraries.

Backend developers listen to the arguments over which JS stack does what and how. Inevitably overwhelmed, they retreat back into their caves to write some of the finest, purest Haskell ever conceived, then sit back with a glass of brandy admiring their monads (or something like that, I don’t know, I don’t write Haskell) leaving the Scary Frontend World alone.

It’s generally acknowledged that Linux “distro hopping” is an unhinged practice fit for masochists and the clinically deranged. It’s high time we collectively agree stack churn in the JavaScript Ecosystem is a comparable vice. What is the solution then? Where’s a good tradeoff between stifling innovation and maintaining stability?

Be pragmatic. If you’re a library maintainer, keep building awesome tools, but don’t expect everyone to use them right away. There are already so many moving pieces. If what you’re building is truly revolutionary, it will stand the test of time and eventually become a standard (whether you like it or not!).

If you’re building a product, you need to ship. Leave the bleeding edge, the framework wars, and library hopping to the maintainers of the tools. Chances are you don’t need to be an expert in every new library that comes out.

Stop, settle, and pick something to move forward. If you can’t decide where to start, then vox populi vox dei: start with Next.js. Get really good at it. Only switch up your stack if there’s a feature your platform can’t function without. It’s time to focus on shipping, not deliberating. I regretfully inform you, that even if you can’t take advantage of the latest shiny, you’ll be ok!