4 ms·
> can break things that there's no way to know until production I would argue that any production system should have enough tests that upgrading a dependency t
by rpep 4y ago
> can break things that there's no way to know until production
I would argue that any production system should have enough tests that upgrading a dependency that breaks compatibility should cause failure of the test suite in some way
- wizofaus 4y agoYou can argue that but I've seen plenty of production systems relying on dynamically typed languages where breaking third-party dependency changes were indeed undetectable until a new version was deployed and particular features stopped working at runtime. It's certainly not unheard of for the same to occur with statically typed languages but at least there's a whole class of potential errors that are caught automatically by compilers/linkers with no extra work on behalf of the programmers. And even when errors do occur at runtime due to JIT compilation etc. they're more likely to have helpful information attached to them. Either way, all the automated tests in the world aren't likely to catch a problem that's related to incorrect library versions being loaded from some global cache that you have limited control over (having moved back from SaaS to on-prem based software recently I've been very quickly reminded of that reality!).
- stevebmark 4y agoThis is a very good argument for why Ruby should never be used for production systems, and neither should Javascript without using Typescript.
- jaredsohn 4y agoWhy specifically Ruby here? How about python, php, etc? Also, many dynamic languages have static type checkers if you want to use them (i.e. Ruby has Sorbet).