News for hackers. Stuff that matters.
Re:Projects That Are Making Fast Ruby a Reality by pmarreck on Thursday February 11, 2016 @02:05PM (#11082276)
When you work on any medium-to-large Rails project, and you want to run a quick unit test to test some new functionality for your new class that inherits from, say, something in ActiveSupport, and AS pulls in a bunch of gem code that is opaque to you, and your class names a module that wasn't loaded yet and so it gets dynamically loaded (warning: global mutable state has been altered, causing weird load-order bugs), and then THAT module triggers other loads of things it depends on, and one of those monkeypatches a bug in an old version of some gem which has actually since been fixed but is still being monkeypatched with old code and causes a corner-case bug that you haven't discovered yet (shameless self-plug: I actually wrote a gem to help manage that stuff: https://github.com/pmarreck/pachinko), and your unit test ends up taking, like, 30 seconds to just load your stack of dependencies... (I've actually seen 40 sec stack loads, in the wild, at past jobs)

... Ruby is still slow.

Sure, there are band-aids to assist with that stuff (Guard, Zeus, etc.), but you're still dealing with spaghetti-dependency, mutating-global-state, side-effecting hell.

Which is exactly why I now want to work with Elixir and Phoenix instead.

Note: It IS possible to write Ruby in such a way that almost none of this stuff actually comes to pass. But even if you do, you'll have to deal with an entire library of code that does not.

There are no comments on this comment yet.