Why I'm Not Using RubyMotion in Production • Hacker News Board

Re: Why I'm Not Using RubyMotion in Production

#51

Post by x0x0 » Thu, Jun 27, 2013, 5:24 AM UTC

hboon wrote: post #45

x0x0 wrote: post #40

Earlier quoted context omitted.

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.

Re: Why I'm Not Using RubyMotion in Production

#52

Post by gfodor » Thu, Jun 27, 2013, 5:41 AM UTC

krichman wrote: post #48

sjtgraham wrote: post #35

Earlier quoted context omitted.

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 w…

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…

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

Re: Why I'm Not Using RubyMotion in Production

#53

Post by gfodor » Thu, Jun 27, 2013, 5:45 AM UTC

stashpro wrote: post #24

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

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.

Re: Why I'm Not Using RubyMotion in Production

#54

Post by weaksauce » Thu, Jun 27, 2013, 5:46 AM UTC

krichman wrote: post #50

sjtgraham wrote: post #41

Earlier quoted context omitted.

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)

Re: Why I'm Not Using RubyMotion in Production

#55

Post by bobwaycott » Thu, Jun 27, 2013, 6:06 AM UTC

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.

Re: Why I'm Not Using RubyMotion in Production

#56

Post by bobwaycott » Thu, Jun 27, 2013, 6:08 AM UTC

munificent wrote: post #20

coldtea wrote: post #12

Earlier quoted context omitted.

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, t…

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.

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

Re: Why I'm Not Using RubyMotion in Production

#57

Post by bobwaycott » Thu, Jun 27, 2013, 6:12 AM UTC

stashpro wrote: post #28

jevinskie wrote: post #27

Earlier quoted context omitted.

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.

Re: Why I'm Not Using RubyMotion in Production

#58

Post by ef4 » Thu, Jun 27, 2013, 6:30 AM UTC

x0x0 wrote: post #40

scribu wrote: post #25

Earlier quoted context omitted.

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

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.

Re: Why I'm Not Using RubyMotion in Production

#59

Post by blub » Thu, Jun 27, 2013, 7:05 AM UTC

sjtgraham wrote: post #26

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…

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.

Re: Why I'm Not Using RubyMotion in Production

#60

Post by dylangs1030 » Thu, Jun 27, 2013, 7:12 AM UTC

ef4 wrote: post #58

x0x0 wrote: post #40

Earlier quoted context omitted.

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.

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.