Hacker News Reader

Comment by almostdeadguy | Hacker News Reader

I think “debugging errors in prod” is not generally how I like to spend my working life, with or without excellent logging and tooling for surfacing errors.

View on HN

How this works in practice is usually 1) deploy some change, 2) errors start showing up that correspond to that change, 3) click a button to revert the change instantaneously (some systems can even do this automatically), 4) debug the change in dev

There is no way any of this process takes less time to solve than "I got a red squiggle in my editor and fixed the variable spelling". I don't think typos are really the only things type systems fix (type systems provide powerful ways of preventing screw-ups by allowing you to encode invariants about a piece of data and how it may be used), but if typos are indeed the extent of it, it seems unimaginable to me that the process to fix would be faster by going through code review -> CI pipeline -> deploy and then back again, no matter how fast it is to revert a change in production. Honestly that's just the compile-time safety advantage of types, half the time saved in typescript is just not spending time having to read someone else's source code to figure out how a function may be used because cowboy js devs were too lazy to document them (knex is an especially egregious offender in this regard that I thankfully don't have to use anymore).

I never claimed it was "faster". Of course static types allow you to catch errors earlier in the process than without.

Whether or not that delta is worthwhile compared to a dynamically typed codebase with a well-optimized deployment/error detection system is not always clear however. Especially considering the costs of a static type system in limiting expressiveness compared to dynamic code and the mental overhead required when building abstractions that require layers upon layers of generics and higher order types to fully specify statically (library authors probably feel this pain the most).

Some patterns or abstractions are more difficult in statically typed code but after a while you start to realize you probably shouldn't use them most of the time. Static typing makes it very easy to be _precisely_ abstract, and have some proof that things which claim to be that abstraction actually satisfy a certain structure. Dynamic typing may make it easy to be abstract in all kinds of crazy ways (I'm looking at you ruby metaprgroamming) but without safety abstraction can easily be more of a liability than a benefit.

I'd encourage you to keep your mind open to it's potential benefits as I've felt it has been a truly transformative experience that I'd like others to share.

Monitoring is a tool to help you know when something is already broken, it does nothing to prevent problems, unlike a type system. If your error rates are spiking in production then real customers are getting a bad experience with your product, i.e. hurting sales, your brand image, and generating more work for your colleagues in the form of customer-support tickets that a human still needs to resolve even though you "instantaneously" rolled back the changes.

It's also common to encounter errors in production that are difficult to reproduce in the development environment, this is especially true of data-type errors in dynamic languages where some unusual edge case creates a strange data structure that would simply be impossible with static types.

There's also a chance that the developer fixing the code didn't actually fix it and instead only introduced enough guard logic to handle that one specific case based on their best guess regarding the shape of data that can come through, thus redeploying with a 30% error rate instead of a 60% one, repeating the cycle of attrition testing against the production environment until the error rate is "noise" but maybe not completely fixed.

Dear god this process is insane. It’s the closest thing to malpractice that I’ve heard of in our industry lately.

Reply on news.ycombinator.com