Hacker News Reader

Comment by mwcampbell | Hacker News Reader

I wonder if RubyMotion is much better when it comes to memory management. According to the website, RubyMotion objects are platform native objects (ObjC objects for iOS/Mac, java objects for Android), so each platform's native memory management scheme applies, rather than having two GC's or GC plus reference counting.

I'd probably use RubyMotion for an upcoming project at work if it had a port to WinRT for Windows universal apps.

View on HN

Judging by the docs [1], RubyMotion does indeed not seem to use a GC on iOS but instead relies on ref counting, reusing auto-release pools. That means cyclic refs are an issue. You have to explicitely use weak references throughout your code.

They are not on Android, where RubyMotion uses the Dalivk/ART GC.

So, your cross-platform Ruby code has to deal with two different types of memory management systems. I'm not sure this qualifies as a better option to what Xamarin provides.

[1] http://www.rubymotion.com/developers/guides/manuals/cocoa/ru...

Doesn't seem like a problem to me. The occasional weak reference to break cycles wouldn't hurt anything on Android, would it?

I guess not. But it's going to be tough to use normal Ruby gems on iOs that aren't aware of the ref counting.

Here's a recent extensive benchmark against popular cross-platform toolkits: https://medium.com/@harrycheung/cross-platform-mobile-perfor... (including memory usage)

Reply on news.ycombinator.com