Why I'm Not Using RubyMotion in Production | Hacker News Reader

Why I'm Not Using RubyMotion in Production

joshsymonds.com

146 pointsVeraticus73 comments

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.

... 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.

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.

Has it ever led to a pseudo-ransom situation if only a single client is affected by a showstopper bug? If not, how is this mitigated?

Well, I believe two ways. First, I'm sure the contracts have penalties, plus hospitals have lawyers. Second, when companies spend tens of millions of dollars per year or more, they certainly talk to a bunch of current clients. If word gets around that your company screws customers it will throw a wrench in sales. There aren't that many hospitals, particularly if you view chains like kaiser as a single customer, in the US.

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.

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.

>> one of the most common electronic medical record systems

Can you point to the company name? I am checking what is out there (EMRS).

I'm at least annoyed that an LLVM static compiler was hyped up for MacRuby (some code was even available) less than 6 months before RubyMotion became a thing. Always felt fishy to me.

That is $200, then after a year you will have to pay $100 to get updates. That was not cheap, I was hoping that I can continue recieving updates for my initial purchase, since many apps which is payed only once does that.

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/).

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.

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

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.

> 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.

Did you know you can have Vim keybindings in Xcode?

The XVim plugin? That's hardly a complete implementation.

xvim is super alpha... the visual studio guys just released a vim plugin for xcode too... I haven't used the xcode one yet but if it's as good as the visual studio one it should be very good. (I have contributed to xvim and I have purchased the visual studio plugin)

I might have to look into this visual studio plugin, thanks.

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

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

Xcode has command line tools. You don't have to use the GUI exclusively. Also I know at least one developer that uses vim for editing but uses Xcode for building. It's probably in your best interest to use some combination (e.g. Xcode for configuring your build settings)

Using Xcode is a shit experience, it crashes numerous times each day, creates zombie processes when testing in the simulator, and has something like 1000 tiny problems that are irritating. LLDB is powerful, but not a proper REPL.

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

Yesterday I had to convert a list of constants into mathematical operations. Took ten seconds to make the macro in vim, and then I ran it twenty times in a second. Compare with the five to ten minutes it would have taken doing option+arrow around the numbers to add characters before and after.

I've turned off all of Xcode's text editing functionality (except for esc to code complete) because it was interfering with typing instead of helping. I've tried to turn off all the "jump to error" stuff in the settings, but it still insists on jumping to the disassembly for main() when it hits an error.

Yeah I have to admit if they added first class vim keybindings to XCode it would have probably swayed me away from RubyMotion.

What about AppCode and the vim plugin that goes with all Jetbrains IDEs

Having parts of a string perform operations on a container is not elegant, it's a crutch for the lack of availability of generic operations or something like LINQ. Many of Objective-C's interesting features have this problem that either they're too magical, have an odd syntax or are leaky abstractions due to the limitations of backward compatibility.

This. After the addition of blocks, Grand Central Dispatch, and the booting of garbage collection in favour of ARC, ObjC is a pleasure to code in and to see it perform. As mentioned, KVC/KVO have made the UI code for my app much simpler than without them.

I'd add that one not be fooled by the apparent verbosity of the "selectors", which is the ObjC equivalent of lisp parens that hits folks new to the language. Their cognitive overhead (for me) is rather low, and they make the code readable without profuse commenting. XCode has been a pleasure as well (despite the occasional crashes), due to the live code correctness feedback (thanks to llvm/clang), auto-complete and auto-correct.

Overall, practically everything's been improving in iOS land as far as I can tell.

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.

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/). His startup has been using RubyMotion for a while and he's written tutorial and a book for it as well.

Very interesting! Thanks a ton for the tip.

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...).

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

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.

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

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.

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.

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.

You can get a refund within 30 days.

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.

RubyMotion's creator answer : https://groups.google.com/forum/#!topic/rubymotion/x6-9c__IH...

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.

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

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.

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.

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.).

Thanks to you and Veraticus. My assumptions were completely off.

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.

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

Was going to say the same thing. I employ the same usage to mitigate confusion.

RubyMotion doesn't use ARC (or Xcode) at all -- it doesn't produce Objective-C code as its output, but executable bytecode intended to be run on the target. The output of Objective-C and RubyMotion, that is, is the same. So you need an equivalent implementation of ARC in RubyMotion to deal with memory management, unless you want to do it manually, which wouldn't make RubyMotion very Ruby-like at all.

> The output of Objective-C and RubyMotion, that is, is the same.

Debatably, as is the subject of this article.

Sometimes I doubt your commitment to RubyMotion.

lrz promises fix by next version

https://groups.google.com/d/msg/rubymotion/x6-9c__IHH0/J7jYd...

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.

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!

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.

Ruby already has garbage collection, so clearly GC is not impossible at all.

And there have been successful bridges from Python/Ruby to Obj-C that had GC too.

Now, ARC, or something similar for RubyMotion, is a different take on the matter. I don't know why they want that way instead of an actual GC.

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.

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.)

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.

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.

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.

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

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

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

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

Read the paragraph that starts with the sentence, "Of course, there's a workaround."

you mean the paragraph that includes "...will correct the crashing error – sometimes. I’ve used instance variables and have still experienced crashes in blocks" ? That one? Or was there a paragraph I missed that included a workaround that actually solved the problem rather than minimizing it?

See https://news.ycombinator.com/item?id=5950675

The fact that there is a workaround is irrelevant for two reasons.

First, said workaround would completely change the entire structure of your ruby code. Basically, kill blocks. This is inferior to Objective-C itself structure-wise.

Second, and most importantly, this bug is not something that jumps out at you. It only causes crashes in some small % of runs. So, the result is your apps look fine, you are writing idiomatic ruby, but once you release to production, you start getting crash reports because you closed over a local variable that ends up being released. This is the kiss of death for production apps: un-reproducible bugs due to magic in the compiler not working as expected.

In other words, even if you know about the bug, and even if you understand the workaround, if you write code naturally, you are going to introduce crashing bugs that are not reproducible that affect some small but measurable percentage of your users. A true nightmare.

I think "irrelevant" is a poor choice of words here.

It is VERY relevant that there is a workaround. Additionally, it's kind of unfair to point at 1 bug (that has a workaround) and judge an entire system on it.

https://yourlogicalfallacyis.com/composition-division https://yourlogicalfallacyis.com/no-true-scotsman https://yourlogicalfallacyis.com/the-texas-sharpshooter

You basically just said "No, you" and then posted some links to logical fallacies. Care to address my argument more directly? The key problem here is that while this bug that may have a workaround (and that workaround is questionable to even work in all cases), it's that the bug does not manifest itself in a development environment, and occurs when you write code naturally. So, you are likely to introduce the bug, but you don't get to know you have crash issues all over your app until you ship it to a lot of users. This, combined with the App Store review delay process, results in a situation where this platform is not tenable for professional software developers to use.

edit: Laurent (RubyMotion lead) has chimed in and raised the priority of this issue, this is great news

the relevant issue ticket is here: http://hipbyte.myjetbrains.com/youtrack/issue/RM-3

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

They offer a "30 days money back guarantee".

Reply on news.ycombinator.com