
Why I'm Not Using RubyMotion in Production - Veraticus
http://joshsymonds.com/blog/2013/06/26/why-im-not-using-rubymotion-in-production/
======
ef4
I'm happy that the RubyMotion guys can charge money for what they're doing.

But if you're going to stay closed source, you're asking me to just trust you
that important (to me) bugs are going to get fixed fast enough. That is very
hard to do.

That is the real value of open source. It's not about the money -- an extra
$200 is nothing in a development budget. It's about being able to fix the bugs
myself when they matter enough.

~~~
scribu
... or at least hire someone to fix the bugs for you.

I wonder if there are any closed-source software shops that have a "pays us a
premium to fix bug X first" option. Doesn't seem like it would work too well.

~~~
x0x0
I worked for one and it works very well. They build one of the most common
electronic medical record systems plus a bunch of associated software. Any
large client, in this case a hospital, hospital chain, or large ambulatory
clinic, pays a $mm annual fee for the right to call and notify of a breaking
bug and get engineers to issue a fix asap.

~~~
ef4
This basically highlights why there's no comfortable middle ground in pricing
software.

At a high price, you can get strong service guarantees.

At a zero price, you can use open source and manage the critical service
yourself.

At a low but nonzero price, you get neither.

~~~
dylangs1030
Some of it is client-side.

By that I mean, clients with budgets will opt for enterprise services. That's
not necessarily fair, but humans like expensive stuff, especially when it's
not their money.

The thing is, engineers who move into SaaS and try to tackle that middle
ground tend to be shafted. This is why people like 'patio11 so often recommend
aiming for the enterprisey folks - that's where you make a living.

------
sjtgraham
I've been using Ruby for some years now, and let me tell you something: just
learn Obj-C. It's not hard to learn, is actually a pleasure to write, and will
surprise you with it's elegance sometimes, e.g. KVC collection operators
([http://nshipster.com/kvc-collection-operators/](http://nshipster.com/kvc-
collection-operators/)).

RubyMotion would have been awesome a few years ago, but now that Obj-C has
ARC, literals for dictionaries and arrays, and blocks (yes!), I can't help but
think that RubyMotion has missed the boat. Learn Obj-C. Go to iTunes U, get
Stanford CS193P, and have a bunch of fun.

~~~
easyd
I agree, Obj-C has improved a lot. But it's not just Obj-C vs. Ruby:

\- you can use the editor of your choice and the terminal instead of Xcode

\- you can use the interactive console to debug your app or to live test new
code

\- you get all the great wrapper gems like BubbleWrap which are heavily
influenced by the "rails way" of doing things

~~~
sjtgraham
Do you know these to be facts or are you just regurgitating something you've
read or heard elsewhere?

Because:

> you can use the editor of your choice and the terminal instead of Xcode.

This is possible with Obj-C, but using Xcode is a far superior experience to
RubyMotion and any editor.

> you can use the interactive console to debug your app or to live test new
> code

Ditto for lldb in Xcode

> you get all the great wrapper gems like BubbleWrap which are heavily
> influenced by the "rails way" of doing things

There are plenty of powerful 3rd party Obj-C abstractions too.

~~~
adriand
> using Xcode is a far superior experience to RubyMotion and any editor.

XCode is not ideal for people accustomed to, say, vim. I love the static code
analysis and the autocomplete and storyboards are pretty cool too. But having
to edit text like a normal human instead of using vim sucks and the split pane
handling is garbage. I would rather do all my dev in vim.

~~~
sjtgraham
Did you know you can have Vim keybindings in Xcode?

~~~
mharju
As it happens, ViEmu has just launched their product on XCode as well. From
the couple of days in use, I'm quite pleased with it in comparison with
Vicious that I used before that.

[http://www.viemu.com/download-xcode.html](http://www.viemu.com/download-
xcode.html)

~~~
adriand
Thanks for the tip, I'll check it out!

------
zachgersh
I have been waiting for a post like this for a long time. There seems to be a
distinct lack of "I use rubymotion and here are my thoughts" type posts that
provide concrete details.

Really appreciate the article and I am interested to see where this leads for
RubyMotion.

~~~
spartango
If you're curious to hear more perspectives on using RubyMotion in production,
you might check out Clay Allsopp's blog posts (e.g.
[http://clayallsopp.com/posts/rubymotion-year-
one/](http://clayallsopp.com/posts/rubymotion-year-one/)). His startup has
been using RubyMotion for a while and he's written tutorial and a book for it
as well.

~~~
zachgersh
Very interesting! Thanks a ton for the tip.

------
dmarkow
While RM-3 itself is only 4 months old, the bug's been around and discussed
since RubyMotion first came out (e.g.
[http://blog.blazingcloud.net/2012/07/16/rubymotion-block-
sco...](http://blog.blazingcloud.net/2012/07/16/rubymotion-block-scope-bug/)).

They used a bug tracker that wasn't publicly viewable until they migrated
everything to YouTrack earlier this year (I reported it last August).

~~~
evilduck
Laurent himself replied to that blog post saying the bug was resolved in RM
v1.20. What's the difference between RM-3 and what that post describes? They
read very similar to me.

~~~
Legion
Maybe a regression? It does sound like the exact same issue at a glance.

------
stephenheron
I just bought a RubyMotion license and I really enjoyed creating my first
iPhone App but I don't think I would have started if I knew about this issue.

I really hope that they get around to fixing this problem, it does make me a
bit concerned that they are pushing big new features while such a serious
issue seems to exists.

~~~
rubyn00bie
This is exactly how I'm feeling now. I've been prototyping and loving it, but
I almost don't even want to try releasing an application if the support burden
is going to be that high...

Now it's like, well, why not just use Objective-C? I sort of just wish I had
my $200 back.

~~~
DenisM
Think of the bright side - becoming aware of the perils of third-party
platform toolchain you are likely saving a huge number of hours and
frustration for yourself in the future. For example, I still regret using
Google Web Toolkit, and for a few years now, but I'm sort of stuck with it.

$200 is small potatoes.

------
bobwaycott
This article is quite the breath of fresh air where constant, pointless
battles over languages are concerned.

Not only does the author have the courage to admit there are problems with
RubyMotion that make it unfit for production use--and seriously, noticeable
unexpected and difficult-to-reproduce-and-fix memory errors make _any_
language unfit for production--but he also offers a dispassionate and
technical explanation.

I love Obj-C and have eyed RubyMotion and other Ruby-related projects like it
(MacRuby, etc.), and it is nice to hear from an unapologetic supporter of a
project that it is not production ready, despite the hype and fanfare.

Thank you.

------
flyingbeaver
RubyMotion's creator answer :
[https://groups.google.com/forum/#!topic/rubymotion/x6-9c__IH...](https://groups.google.com/forum/#!topic/rubymotion/x6-9c__IHH0)

~~~
cpr
tl;dr: They had a well-known workaround for the known bug involving block
variables [apparently not well-enough], so they were focusing on other things.
As of right now, they're going drop everything and fix it in RM 2.4.

~~~
jasonlotito
Every time I heard the phrase "well-known workaround" I interpret it as
"tribal knowledge."

------
crusso
_We must be able to expect that critical flaws in our toolchains will be fixed
promptly_

At some point, Borland disabused me of the notion that serious toolchain
providers fixed their critical flaws promptly... or at all.

------
1123581321
Apologies for the basic question, but why would this 'analog' (is that another
system? An abstraction?) have this issue if it is using ARC? Isn't ARC just a
flag in XCode's compiler? If RubyMotion turns it on, wouldn't XCode make all
the necessary arrangements? Again, I simply want to understand; I'm not trying
to make a point.

~~~
coldtea
It's NOT using ARC. It's using an "analog" (in the original post's words).

With which he means "a substitute", "a similar tech", "their own
implementation of the same concept", "something analogous to ARC" (hence the
"analog").

(Most people know "analog" only as in "analog vs digital", but it was
immediately obvious to me, because I know the etymology of the word from the
original language it was adopted from.

Btw, the english dictionary definition that's closer for such a use of the
word is:

1\. An organ or structure that is similar in function to one in another kind
of organism but is of dissimilar evolutionary origin. The wings of birds and
the wings of insects are analogs.).

~~~
munificent
Personally, I use "analog" to mean "not digital" and "analogue" to mean
"something similar to". I think that's a little clearer, at least to some US
readers.

~~~
coldtea
Could be. I thought analogue was just the british variant of the spelling.

------
hawkw
Sometimes I doubt your commitment to RubyMotion.

------
GantMan
lrz promises fix by next version

[https://groups.google.com/d/msg/rubymotion/x6-9c__IHH0/J7jYd...](https://groups.google.com/d/msg/rubymotion/x6-9c__IHH0/J7jYdoMz85cJ)

------
jimbokun
This puts in question Ruby Motion's entire premise for existence.

Ruby Motion is supposed to make iOS and Mac OS X app development simpler than
Objective C. If there are lots of complex rules and corner cases to learn
about and work around, it becomes easier to just write Objective C, where at
least the rules about memory are well understood by the community.

Will be interesting to see how HipByte addresses this. They at least need to
get in front of the issue with a blog entry or article about how they plan to
address it.

------
gfodor
Hah, I was thinking "what a coincidence" since I started that thread in the
group. Thanks a bunch for writing this up -- I hope it gets fixed soon!

------
pkulak
Am I the only one who thinks that ARC in a language like Ruby is probably
impossible? Even with Objective C they had to add 4 new variable qualifiers,
and put that burden on the programmer to use them properly.

~~~
mikeash
ARC in a language like ruby is trivial. ARC is probably the first kind of
garbage collection ever implemented.

It's only complicated in Objective-C because of all the C.

~~~
jimbokun
Do you have any thoughts, then, on why Laurent is having such a hard time
fixing this in Ruby Motion?

(Looking at your web site, seems like you would have a good understanding of
the underlying issues.)

~~~
mikeash
That's a good question. I'm not really sure, but I'm almost positive it's
related to Ruby or RubyMotion internals, not ARC in general.

As best I can tell from the article and the filed bug, it comes down to not
retaining captured variables in blocks. In Objective-C, there's some automatic
memory management that happens for you when you capture a variable in a block:

    
    
        id x = ...;
        ^{ NSLog(@"%@", x); };
    

Because the block depends on x, the lifetime of that object needs to be tied
to the lifetime of the block. As such, the compiler emits code so that if and
when you copy the block onto the heap, it automatically retains x. When the
block object is destroyed, it automatically releases x.

Note that, while definitely "automatic reference counting", this isn't,
strictly speaking, ARC. Because this is _so_ critical to being able to use
blocks without going completely insane, this bit of cleverness was introduced
with blocks on 10.6, even though ARC didn't exist yet.

The note in the bug says that it's complicated because they don't want to
introduce a performance regression. This suggests that they're not having
trouble with retaining objects referenced by the block per se, but rather with
being smart about it, so that it's only retained when necessary. The
Objective-C compiler does this by constructing blocks on the stack, and
requiring an explicit copy to move them to the heap. Only when explicitly
copied do they retain the variables they capture, so simple inline cases
remain fast. Perhaps Ruby or RubyMotion have something that makes this harder
to do.

If that's correct, then I can't say I find the excuse a very good one.
Performance regressions are bad, but generating incorrect code is much worse.
They need to fix it immediately, take the speed hit, then see about ways to
improve performance while maintaining correctness. However, I certainly could
be wrong.

~~~
hboon
I just want to add that RubyMotion is also not correctly capturing the "value"
of the variable in a block. i.e. even if you manually retain a local
variable's object and don't release it, it wouldn't work correctly if the
block runs _after_ the local variable goes out of scope. IMO, this makes it
much harder to workaround this retain bug.

The workaround now is just to create a class around each block operation. I've
been thinking about this issue quite a bit (I intrigued many developers using
RM are actually not observing this issue sooner) and this workaround seems to
be the only way to use APIs like #beginBackgroundTaskWithExpirationHandler:
and #endBackgroundTask: which has no non-block based alternatives and is
always called asynchronously.

~~~
mikeash
That's quite weird. I can only assume that normal Ruby has no problem with
this. Wonder what changed in RubyMotion to break it. Certainly would need to
be fixed before I'd call RM anything other than a toy or experiment.

------
stashpro
That's a lot of fuzz for an active bug with a very easy workaround.

~~~
jevinskie
I didn't see a workaround, can you elaborate?

~~~
stashpro
I understood that using an instance variable is a viable workaround. Or maybe
just code around the issue?

~~~
bobwaycott
The author states that even using this method has produced indeterminate
crashes.

------
carterschonwald
the relevant issue ticket is here:
[http://hipbyte.myjetbrains.com/youtrack/issue/RM-3](http://hipbyte.myjetbrains.com/youtrack/issue/RM-3)

------
od2m
I've always been suspscious of RubyMotion for having no trial. Now I know.

~~~
easyd
They offer a "30 days money back guarantee".

