Go is Getting Generic Methods

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 accept that your editor won't surface it when you dot into the type with autocomplete or whatever. Generic methods fix that with no runtime cost.

The part worth thinking harder about is the interface asymmetry. A method with signature Read[T any]([]T) (int, error) will not satisfy io.Reader, even though a pinned instantiation Read[byte] would match perfectly. That's by design and it's a permanent constraint as opposed to a temporary limitation. This feature is betting that generic methods satisfying non-generic interfaces is a problem that will never needs solving, so the gap is acceptable. If that turns out to be wrong, any code relying on a type not implementing an interface through a generic method becomes a silent behavior change. There's no opt-out mechanism in the current proposal.

It's a strictly additive backward-compatible feature that solves a problem without complicating the runtime model. I like it. It's been a long time since I've written C# or Java but it's not that dissimilar. Where it differs is that Go's implementation is at compiler time with no interface satisfaction. C# supports generic interface contracts and Java erases them at runtime. The asymmetry with interfaces seems like a smell, but it's a bounded one. Just don't let the builder pattern examples fool you into thinking that's the reason it landed. 

With regards to security I can't find anything of note that doesn't already exist in existing generics. The implementation compiles to package-level generic function so the attack surface is the same. Type parameters are visible at runtime from compilation, so there is nothing new to probe or leak via reflection. Interface asymmetry if anything acts as a security feature in disguise since you can't accidentally satisfy a security-sensitive interface through a generic method. 

Popular posts from this blog

The Fallacy of Cybersecurity by Backlog: Why Counting Patches Will Never Make You Secure

By a Former Engineer Turned Cybersecurity Leader For much of my twenty years as a software and security engineer, and now as a cybersecurity executive, I have watched organizations cling to a deeply flawed belief: that security maturity is reflected in the length of the patch backlog, the volume of vulnerabilities closed, or the number of tickets resolved in a quarter. Entire cultures are built around these metrics. Dashboards glow green when patch counts dip. Leaders celebrate the deletion of Jira, SNOW, etc. tickets as if the act of closing them somehow hardened the enterprise. But this fixation on downstream remediation creates an illusion of control while masking the fundamental problem upstream, there is an innovation pipeline that lacks guardrails, architectural clarity, and secure defaults. The symptom becomes the scorecard, and the root cause remains untouched often under a guise of promoting freedom. Security teams often find themselves in a perpetual treadmill of “forever f...
Read more

IPv6 White Paper I: Primer to Passive Discovery and Topology Inference in IPv6 Networks Using Neighbor Discovery Protocol

Introduction IPv6 drastically reshapes the surface of network reconnaissance, replacing the narrow 32-bit address space and broadcast semantics of IPv4 with expansive subnets and a multicast-centric control architecture. In this new model, Neighbor Discovery Protocol (NDP), Multicast Listener Discovery (MLD), and ICMPv6 signaling collectively define how hosts announce their presence, interact with routers, form addresses, resolve local neighbors, and verify reachability. Although this model was engineered for efficiency and stateless configuration, its reliance on predictable multicast traffic introduces a rich layer of metadata that can be quietly harvested by a passive observer. This paper explores the extent to which NDP, and its associated control protocols, leaks meaningful information about a network’s hosts, topology, addressing structure, and operational state. It also outlines how these behaviors can be transformed into the foundation of a silent IPv6 reconnaissance system cap...
Read more

This is Cybermancy

Image
Preface This document is a manifesto, not a tutorial. It is written for practitioners who live inside systems rather than around them. It is for those who build, test, trace, break, and repair complex machinery at scale. It is not concerned with tools, techniques, or exploits, but with the way of seeing that precedes all of them. The worldview here is neither criminal nor romantic albeit a bit poetic and whimsical in my own way. It is operational. It emerges naturally in those who understand that modern systems fail not because they are attacked, but because they are misunderstood. What follows is a statement of posture, responsibility, and discipline for those who recognize that sight itself is the rarest capability on the Grid. Cybermancers are not defined by exploits, hardware, or street legend. Those tangentials  are the residue and not the essence. A cybermancer is defined by how they see the Grid  not as fortresses, maps, gates, and walls, but as a breathing lattice of...
Read more