3 ms·

> Of the bugs that I've experienced in large-scale, Rails production systems, typing is a small subset. Really? Are you counting errors where a value turned ou

> Of the bugs that I've experienced in large-scale, Rails production systems, typing is a small subset. Really? Are you counting errors where a value turned out to be nil when it wasn’t expected to be? Because that’s a type error. It’s not a type error that many statically typed languages fix (Java is notorious for null pointer exceptions) but it’s a type error that can, in principle, be fixed with static typing.

dlisboa 3y ago
In the app I work on a huge percentage (60% in the timeframe I analyzed) of the errors are errors a type system would catch. Nil references, long method chains where the middle call returns a different object than expected, bad refactorings changing the return type of methods… It’s staggering really. These could be solved with better programming practices, they’re not errors usually experienced programmers make, but they exist nonetheless. An exception/error system, with checked exceptions or handling of errors via result monad/errors like in Go, would solve the vast majority of other errors. Type systems also encourage other things like contracts on API endpoints and typed messages, serving as a early warning system when writing those bugs. Purely business logic bugs are actually not common. I guess we haven’t had the opportunity to create those “higher order” bugs while wading through the others.
- sethherr 3y ago
  Do you have tests? I feel like 60% of the errors I encounter is high for type errors. I also feel like with testing, fixing those errors occupies less than 5% of my debugging time.
nicolas_t 3y ago
I'm always surprised by that, I've worked with 10-15 people team on relatively large rails codebase and, yes, the bugs we usually see are not type related bugs (including nil when it's not expected). I keep reading people saying that type systems eliminate a huge class of bugs but, it's not been my experience with languages that use poor type systems (java, rust... ). Languages that have much better types like OCaml are different and I've had great luck with OCaml in particular (my favorite language to use when I can) but, there's also the fact that devs who use ocaml tend to also be much better than average (in the same way that in my experience devs working with php or nodejs exclusively tend to be much worse than average). Note before I'm downvoted for my last comment, there are exceptions but looking at the average candidate applying for a php, nodejs position compared to one for rails and one for ocaml.
thih9 3y ago
In this case, I guess you can create some ruby gem/library/convention/dsl/architecture that makes it harder to accidentally pass nils - and be more efficient than a popular language that has static typing. I’m writing that to address the “just not in ruby” remark[1] from earlier. [1]: https://news.ycombinator.com/item?id=38385890 https://news.ycombinator.com/item?id=38385890

dlisboa 3y ago

In the app I work on a huge percentage (60% in the timeframe I analyzed) of the errors are errors a type system would catch. Nil references, long method chains where the middle call returns a different object than expected, bad refactorings changing the return type of methods… It’s staggering really. These could be solved with better programming practices, they’re not errors usually experienced programmers make, but they exist nonetheless. An exception/error system, with checked exceptions or handling of errors via result monad/errors like in Go, would solve the vast majority of other errors. Type systems also encourage other things like contracts on API endpoints and typed messages, serving as a early warning system when writing those bugs. Purely business logic bugs are actually not common. I guess we haven’t had the opportunity to create those “higher order” bugs while wading through the others.

sethherr 3y ago
Do you have tests? I feel like 60% of the errors I encounter is high for type errors. I also feel like with testing, fixing those errors occupies less than 5% of my debugging time.

nicolas_t 3y ago

I'm always surprised by that, I've worked with 10-15 people team on relatively large rails codebase and, yes, the bugs we usually see are not type related bugs (including nil when it's not expected). I keep reading people saying that type systems eliminate a huge class of bugs but, it's not been my experience with languages that use poor type systems (java, rust... ). Languages that have much better types like OCaml are different and I've had great luck with OCaml in particular (my favorite language to use when I can) but, there's also the fact that devs who use ocaml tend to also be much better than average (in the same way that in my experience devs working with php or nodejs exclusively tend to be much worse than average). Note before I'm downvoted for my last comment, there are exceptions but looking at the average candidate applying for a php, nodejs position compared to one for rails and one for ocaml.

thih9 3y ago

In this case, I guess you can create some ruby gem/library/convention/dsl/architecture that makes it harder to accidentally pass nils - and be more efficient than a popular language that has static typing. I’m writing that to address the “just not in ruby” remark[1] from earlier. [1]: https://news.ycombinator.com/item?id=38385890 https://news.ycombinator.com/item?id=38385890