rydonahue

There's an implemented proposal with GOEXPERIMENT adding generic methods to Go, and the reaction is positive in a way that I think slightly misreads what the feature actually does. I couldn't think of a way to trim my thoughts down to 280 characters so here I am.  The change is narrow whereby methods will be allowed to declare their own type parameters, the same way top-level functions already can. No changes to interfaces, dynamic dispatch, or reflection support needed. Under the hood, every generic method call can be mechanically rewritten into a generic function call, which is what made this feasible where it previously wasn't. The examples floating around tend to focus on chaining and builder patterns, but that's not really the point. The actual problem being solved is namespace pollution. Right now, if you want a generic operation associated with a type, you have no choice but to put it at package scope, invent a name that won't collide with anything, and ac...

AI industry hype beasts are spreading one of the craziest narratives I've ever seen. It goes a little something like this... "You don't need open source libraries anymore. Large Language Models can generate the code you need on demand. Why carry the risk of third-party dependencies when you can just synthesize the functionality yourself? Why expose your software supply chain to vulnerabilities in projects like XZ Utils or Firefox when a model can write you something bespoke in seconds?" This argument is being floated implicitly and explicitly by the same companies charging you per token to generate that replacement code. Who would've thought? It's also one of the most intellectually dishonest positions in modern software engineering.  However, the argument does resonate with some as software supply chain attacks have genuinely gotten worse. The XZ Utils backdoor discovered in March 2024 (CVE-2024-3094) is the canonical recent example. A likely state sponsore...

There is a particular kind of madness that sets in around year three of a large software project. The codebase has grown. The team has turned over twice. The original architects, the ones who made the really important decisions, have either been promoted into irrelevance or left for a startup that is definitely going to disrupt something. What remains is their legacy including a monument to everything they knew, everything they read about that one weekend, and every clever abstraction they were proud of at the time and has abused into utter disdain. I have stood in front of codebases like this. I have created the function maps and over-overloaded operators saying, "it's exactly what we need for today." I have stared at template metaprogramming in C++ that would make a mathematician weep with admiration and a new hire weep for different reasons entirely.   I have stared into the abyss of  recursive expression tree transformations  and s ource generators in C# that make de...

Narratives are forming around generative AI claiming it represents a leap in how software is written. The ergonomics are undeniable and the output of mundane things not worth committing to memory is a genuine force-multiplier. Tools built on models like GPT-4 and Claude can scaffold functions, translate between languages, and approximate architectural patterns with fluency that would have seemed implausible a few years ago. In my own workflow, the boring parts of starting something new are gone, which frees up thought for the harder parts of a problem. Fluency is not understanding, and approximation is not correctness. Gaps between those two ideas are where most of the current pitfalls live, and where a lot of production systems are accumulating debt. Under the hood A transformer model is, at its core, a very large matrix multiplication engine. During training, it ingests code and text and adjusts billions of numerical weights through gradient descent until it gets good at predicting t...

Every few years, someone in a conference hallway or a podcast studio declares with great confidence that this is the year of the Linux desktop. It never is, of course, and the phrase has become a kind of inside joke for people who have been around long enough to appreciate the humor in perpetual woulda, coulda, shoulda. IPv6 has had a similar quality to it and I recently joked about it in an interview( Automate or Die Trying ). Those of us who work in this space have been waving our arms about it for the better part of a decade, predicting that organizations would eventually be burned by the protocol they deployed but never fully considered. And every year, the industry nods politely and returns to its regularly scheduled IPv4 firewall tuning. Google has now recorded that IPv6 traffic has reached parity with IPv4, crossing the 50% mark globally( Tom's Hardwar e) , a milestone that has been in slow motion since 1998 when the protocol was first standardized. As of April 2026, countr...

Technology drift is rarely the result of a bad decision, but an accumulation of dozens of reasonable ones. A team chooses Rust for performance in one service, Python for convenience in another, Node for a quick internal API, and Bash for some glue automation. Each decision makes sense in isolation. Over time, however, the organization stops reflecting a strategy and instead reflects history. The appealing principle of “the right tool for the right job” quietly morphs into a fragmented landscape of runtimes, build systems, and operational patterns. Without guardrails, what begins as engineering autonomy slowly becomes engineering entropy. The core problem is not the existence of multiple tools but rather it is the erosion of shared deep mastery. Software engineering is a socio-technical discipline, not just a collection of code artifacts. The maintainers matter more than the syntax. The debugging model matters more than the marginal performance improvement. The right tool must be evalu...