Where Generic Abstraction Stops Helping: Framework Ergonomics in Systems Languages

#Abstract

Two microservice frameworks written in Rust were abandoned for the same reason, and the reason was not the borrow checker. This note argues that an abstraction which re-exports its decisions as type parameters has not hidden them, proposes counting empty interface implementations as a measurable design signal, and reports that the author made the same error three times across three languages.

#Observation

Framework code sits at the boundary between the generic and the concrete. In a language where that boundary is expressed in the type signature, the signature accumulates the framework's internal decisions.

In the systems examined, a request handler that resolved two services from a container and returned a response carried four generic parameters, two lifetimes and a trait bound exceeding a line. The author could read it. No user could, and a framework whose signatures only its author can read has failed at the function frameworks exist to perform.

#The criterion being violated

Parnas states that a module should be characterised by the design decision it hides [1]. A type parameter for every internal variation point does the opposite: it makes the decision visible in the signature and requires every user to satisfy it.

Brooks separates the essential difficulty of a problem from the accidental difficulty introduced by tools and representation [2]. Distributed service lifecycle is essential. Four generic parameters to express a request handler is accidental, and eighteen months were spent on the accidental part.

#A measurable signal

Direct measurement of abstraction quality is difficult. This note proposes an indirect one that is easy to compute and, in the author's experience, predictive.

where M is the interface's required methods and P its implementations. A trivial implementation is one returning a zero value with no other effect.

The claim is that a high emptiness ratio indicates the interface has bundled independent concerns, and that the correct response is to split it into one required method plus optional capabilities detected at runtime. An implementation that then declares an optional capability is communicating something, whereas an empty required method communicates nothing.

#Evidence

Three frameworks by the same author shipped an interface with seven required methods. In each case the majority of implementations satisfied the majority of methods trivially. In the third case the interface was reduced to one required method and the emptiness ratio fell to zero by construction, since optional capabilities are only implemented when used.

This is a single author across three projects, which is the weakest form of evidence. It is reported because the repetition across three languages suggests the error is not obvious, and organisational and representational factors of this kind are known to shape the artefacts that result [3].

#Scope of the claim

This is not an argument against expressive type systems. The compiler correctly identified real lifetime errors in a service registry that would otherwise have appeared under concurrency, which is a genuine benefit.

The argument is narrower: for code that is extended by users rather than merely used by them, decisions surfaced in signatures are decisions transferred to users. A gateway with no user-authored handlers in its signatures does not have this problem, which is why the author continues to use the same language for that class of program.

#Limitations

The emptiness ratio has not been validated against any independent measure of design quality. It is proposed as a cheap heuristic with a plausible mechanism, and testing it would require classifying interfaces across a corpus of frameworks by an independent quality judgement, which has not been done.

Language features have changed since the systems described were written, and a version written today would face a weaker form of the same constraint.