4 ms·
Even the JVM has a fair number of issues if you use class reloading to do Weird Stuff (tm), especially with advanced debugger tricks added into the mix. That's
by zbentley 9y ago
Even the JVM has a fair number of issues if you use class reloading to do Weird Stuff (tm), especially with advanced debugger tricks added into the mix. That's one of the reasons some of the folks I know who use Scala switched in the first place.
I think any hot-reloading solution for a big, complex, introspective/reflective language is going to have some warts* and places where it stops working in some scenarios. The trick is just to minimize those to where they don't get on your nerves on a daily basis. C# will hopefully get there soon.
* Unless, that is the language is designed from the ground up to support code reloading. Erlang/Elixir's runtime inspection/injection/behavior alteration capability is second to none, and largely replaces the role of a true/traditional debugger. And you can do other cool stuff with it like zero-downtime in-place deployments, though that doesn't exactly come for free.
- _sdegutis 9y agoI ended up with a pretty sweet workflow that involved hot code reloading in a Clojure web app where I rarely needed to restart the dev JVM. It involved Emacs and CIDER and designing the app’s architecture in a certain way but I felt it was really worth it. That said, if I was using a language with faster start up time then I’d have just restarted after every major change and not even worry about this, but this has some benefits that don’t exist in that scenario.