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...

For many new software engineers, debugging is perceived as a rite of passage measured by tool progression: first print statements, then logging frameworks, and eventually a full-featured debugger. This framing is misleading. Debugging does not begin with tools at all. It begins with the ability to reason about a system for what it is supposed to do, how it is structured, where invariants should hold, and which assumptions are most likely to be wrong. Tools merely amplify that reasoning. Without a targeted methodology, even the most advanced debugger becomes a slow and unfocused microscope pointed at the wrong place. The reality is whether setting a print statement or well-placed breakpoint doesn't imply what is or isn't more correct. Both cases demonstrate the ability to reason the question into hypothesis. Personally I like recommending a setting a breakpoint and stepping a proper debugger for assumptions. In this way, as a mentor, it imposes a consciousness of the stack and ...

Preface This article was inspired by recent investigative reporting of  Brian Krebs , whose December 2025 analysis, Most Parked Domains Now Serving Malicious Content , synthesizes empirical research demonstrating a decisive shift in how parked and typo-derived domains are used in practice. That work, drawing on large-scale measurements by Infoblox researchers, establishes that domain parking is historically a low-risk monetization practice which has become a dominant vector for malware delivery, scams, and traffic laundering. This article extends that finding by placing it within a broader technical, economic, and defensive framework, with the goal of informing both operational security teams and policy-oriented stakeholders. Abstract Typographical squatting (typosquatting) is a long-standing abuse of the Domain Name System (DNS) in which adversaries register domains that are visually or syntactically similar to legitimate ones in order to exploit human error. While traditionall...