[elvinj]

I know that at least from my experience debugging our apps in production did become harder as we scaled out in terms of servers, users and code. I do wonder if its something that should be handled at the code level (by being more defensive, taking a more immutable approach) or by having better debugging tools. Anyone knows if this supports Ruby?

[wereHamster]

Or by using a better type system. Or by using the type system that's available in the language. Because it's all too easy to ignore the types and for example call `get` on a Scala Option value, or `fromJust` on a Haskell Maybe. Both will throw an exception at runtime if the Option/Maybe is empty.

[elvinj]

Type safety does help a lot. The real hard ones I found to track down are the ones where you have to chase for a particular state to re-occur and you can't get a repro from ops or qa. At least for me these are the main bummers...

[taeric]

Of course, the retort there is as much "write simpler programs" as it is "use the type system." I've seen and been a part of many a tangled knot in a type system that, while ostensibly safe, was so much more involved to do the simple things that I think it caused more bugs.

[wereHamster]

I'm not saying strongly typed languages are bugfree. But they eliminate whole classes of bugs. The OP was asking about programming techniques to improve code quality or tools to help with debugging. Well, a type system is such a technique/tool that checks for bugs at compile time.

[taeric]

Indeed. Apologies for what was too trite of a response. I can't explain why, but I have been getting heavily lured by the dynamic typing of lisp, lately. I blame that I am finally watching the SICP lectures online. :)

[timdorr]

Passenger Enterprise supports a live irb and debugger: https://www.phusionpassenger.com/enterprise#debugger_support