4 ms·

I've found that the kinds of errors that static typing guards against are often things that would have been trivial to debug and fix in the first place (mostly

I've found that the kinds of errors that static typing guards against are often things that would have been trivial to debug and fix in the first place (mostly things like typos). Given that you have a good system for monitoring errors in production and a low friction deploy process so you can quickly and easily fix errors when you discover them, I feel these kinds of errors are honestly not worth guarding against in most contexts outside of those where getting everything perfectly right the first time is a hard requirement (health, fintech, other safety-critical industries, etc). Of course, most companies lack either or both of these ( a good system for monitoring errors in production and a low friction deploy process), so they use static typing as a clutch to try to reduce the chance of errors making it into prod simply because they know they'd be slow to fix/detect those errors. That's a poor reason to choose static typing IMO, but I think that's by far the most common reason.

almostdeadguy 7y ago
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.
- lewisl9029 7y ago
  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
  - almostdeadguy 7y ago
    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).
    - lewisl9029 7y ago
      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).
      - hderms 7y ago
        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.
  - root_axis 7y ago
    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.
  - smt88 7y ago
    Dear god this process is insane. It’s the closest thing to malpractice that I’ve heard of in our industry lately.
cdeutsch 7y ago
I used to think like that, until I was forced to use TypeScript at a new company. Now I avoid using regular JavaScript. I'm impressed how many bugs it prevents, and it prevents them early. Refactoring in TypeScript is literally magnitudes easier and quicker.
- siempreb 7y ago
  > I used to think like that Such arrogance.. ..and unfortunately so typical for TS proponents..
koolba 7y ago
> I've found that the kinds of errors that static typing guards against are often things that would have been trivial to debug and fix in the first place (mostly things like typos). Sure but unless you have coverage of all error cases, it’s nice to have that check at build time vs some untested corner case in production. > Given that you have a good system for monitoring errors in production ... Runtime errors are a totally different beast. > ... and a low friction deploy process so you can quickly and easily fix errors when you discover them, I feel these kinds of errors are honestly not worth guarding against in most contexts outside of those where getting everything perfectly right the first time is a hard requirement (health, fintech, other safety-critical industries, etc). Of course, most companies lack either or both of these ( a good system for monitoring errors in production and a low friction deploy process), so they use static typing as a clutch to try to reduce the chance of errors making it into prod simply because they know they'd be slow to fix/detect those errors. That's a poor reason to choose static typing IMO, but I think that's by far the most common reason. Fixing things earlier is cost effective regardless of your deploy speed. Sure it’s worth more the longer the cycle, but not having to run unit tests because the compiler knows “foo” is not “fo0” saves time as well.
- lewisl9029 7y ago
  That's totally fair. I'm not saying detecting errors earlier through static typing has no value of course. Just that there is a spectrum of value a team can derive from static typing that scales based on the length of their deploy and error detection cycle, and at the lower ends of that scale it's not always clear that static typing provides enough of value to justify its costs. And that if a team doesn't already have them, investing to minimize the deployment and error detection cycle is often much more valuable than investing in static typing because it's an effective tool for both dealing with runtime errors as well as errors that could have been statically determined.
  - hderms 7y ago
    I've worked in a number of languages and fwiw I've never written such error-free code as I have in Scala when embracing the type system (to a reasonable degree) and embracing immutability/fp patterns. We write only the tests that truly matter, something I've never felt is possible in a dynamic language as I personally feel you need lots of tests which are more or less provided for free by the type checker.

almostdeadguy 7y ago

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.

lewisl9029 7y ago
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
- almostdeadguy 7y ago
  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).
  - lewisl9029 7y ago
    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).
    - hderms 7y ago
      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.
- root_axis 7y ago
  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.
- smt88 7y ago
  Dear god this process is insane. It’s the closest thing to malpractice that I’ve heard of in our industry lately.

cdeutsch 7y ago

I used to think like that, until I was forced to use TypeScript at a new company. Now I avoid using regular JavaScript. I'm impressed how many bugs it prevents, and it prevents them early. Refactoring in TypeScript is literally magnitudes easier and quicker.

siempreb 7y ago
> I used to think like that Such arrogance.. ..and unfortunately so typical for TS proponents..

koolba 7y ago

> I've found that the kinds of errors that static typing guards against are often things that would have been trivial to debug and fix in the first place (mostly things like typos). Sure but unless you have coverage of all error cases, it’s nice to have that check at build time vs some untested corner case in production. > Given that you have a good system for monitoring errors in production ... Runtime errors are a totally different beast. > ... and a low friction deploy process so you can quickly and easily fix errors when you discover them, I feel these kinds of errors are honestly not worth guarding against in most contexts outside of those where getting everything perfectly right the first time is a hard requirement (health, fintech, other safety-critical industries, etc). Of course, most companies lack either or both of these ( a good system for monitoring errors in production and a low friction deploy process), so they use static typing as a clutch to try to reduce the chance of errors making it into prod simply because they know they'd be slow to fix/detect those errors. That's a poor reason to choose static typing IMO, but I think that's by far the most common reason. Fixing things earlier is cost effective regardless of your deploy speed. Sure it’s worth more the longer the cycle, but not having to run unit tests because the compiler knows “foo” is not “fo0” saves time as well.

lewisl9029 7y ago
That's totally fair. I'm not saying detecting errors earlier through static typing has no value of course. Just that there is a spectrum of value a team can derive from static typing that scales based on the length of their deploy and error detection cycle, and at the lower ends of that scale it's not always clear that static typing provides enough of value to justify its costs. And that if a team doesn't already have them, investing to minimize the deployment and error detection cycle is often much more valuable than investing in static typing because it's an effective tool for both dealing with runtime errors as well as errors that could have been statically determined.
- hderms 7y ago
  I've worked in a number of languages and fwiw I've never written such error-free code as I have in Scala when embracing the type system (to a reasonable degree) and embracing immutability/fp patterns. We write only the tests that truly matter, something I've never felt is possible in a dynamic language as I personally feel you need lots of tests which are more or less provided for free by the type checker.