sometimes we joke but a “fuse for software” seems like a really accurate metaphor for static builds:
5 replies
@zachleat ... wait is the static build the fuse? Like you keep around a static build, that if it stops working you know your system has changed in unsafe ways that the interpreted, or dynamically linked binary didn't yet notice? This is the opposite of common mode failure. The static build is quickly *outside* of the common mode (unless it's updated in lock step with the dynamic systems).
@codonell I think you and I may use static builds in different ways, given your description there!
@zachleat 😂 We all build systems, of one kind or another. A system can be static (not updated while handling loads) or dynamic (updated while handling loads, or reconfigures under load) (or in-between). Does your form of "static build" (static site generator, generating static binary artifacts) mean the system is not updated while handling loads? If it fails under load, while other dynamic systems don't, then... is it a form of observability instrumentation?
@codonell I *think* I understand what you’re saying, that the fuse metaphor applies to the runtime behavior? Rather, I’m thinking about it as the *build* being the fuse — where failure in the build can prevent damage/outage in the production system!
@zachleat Oh!? Interesting. Yes, you got me right. Yes, in a static site generator, just like with static linking, you need *all pieces* to be present and assembled correctly or it fails to build. While a dynamically linked application can be built with undefined references to be resolved at run time... and then just fail in production. I agree, and the analogy applies downstack too. That is to say that the act of having to assemble the whole thing statically is proxy for correctness.
