4 ms·
Secondly, avoiding mutable state is a general, good advice, which you can apply in your Ruby code. Ditching global state and isolating it when you can’t avo
by im_down_w_otp 10y ago
Secondly, avoiding mutable state is a general, good advice,
which you can apply in your Ruby code. Ditching global state
and isolating it when you can’t avoid is also a really good
general advice.
As an Erlang programmer I agree with the general sentiment here, but wouldn't doing this in Ruby really lean hard on one of the pathologically nasty Ruby runtime issues? Which is that it doesn't release memory back to the system?
When every new operation on a data-structure starts by producing a copy of the previous version it seems like you'd really want a runtime which is efficient and intelligent about how it manages memory?
Unless that idiosyncrasy of Ruby has changed since I last used it several years ago. In which case. Nevermind. :-)
- pdimitar 10y agoRuby's MRI never returns RAM to the kernel, yes. But if you use immutable data structures and release them relatively quickly, the GC will have much easier time releasing their memory back to the pool that MRI is using for allocating new ones. So the inevitable RAM bloat that MRI accumulates over time is still there, but is slowed down. As far as my not-so-big experience with them goes, the immutability programming techniques in Ruby actually help a lot with its sticky RAM problem. Complex object hierarchies of mutable objects and references to them are a nightmare for the GC. Having structures/objects that are used and [quickly] thrown away without (or rarely) being attached to complex object graphs is making the GC work more reliably, and faster.