[dnautics]

Obsessive type safety in my opinion is a bit silly, it stems from this thought that you can squeeze out every possible runtime error by defensively coding. The truth is, you can't; there are going to be language errors, os errors, driver errors, and errant cosmic rays. Designing for resilience is not solved by typing, and an obsessive typing pattern can create a false sense of security.

[OtterCoder]

Bah, I've seen runtime errors with dynamic and strict typing, and I'll take type safety any day. Besides, good type systems like Rust's force you to think about all sorts of errors at all points of the program. It's harder to write, but it's harder to break, and much, much easier to fix.

[dnautics]

have you ever programmed in a BEAM language like erlang or elixir? It's easy to write, when there are errors, most of the time it's "no big deal". If something that is outside of your control (someone else's code, or hardware, or a driver, etc) then it's often not a fatal problem. Pushing errors to the edge is great, but "forcing you to think about all sorts of errors", I think is an antipattern. You should code the happy path, anticipate the 80% errors, patch the next 19% error, and ignore the last tiny sliver of errors, and generally be able to refactor easily.

Of course your environment should be able to survive and persist 99.99999% of errors, that's critical... there should be no throw()s or panic()s.

[OtterCoder]

No, and I really should give those a try. That said, when I just want happy-path, idc, just reload on errors, kind of code, it's a sore temptation to just reach for JS.