Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Why I'm Not Using RubyMotion in Production

joshsymonds.com

Post reply on HN
Print view View original

41–50 of 75 posts

Re: Why I'm Not Using RubyMotion in Production

#41

Post by sjtgraham »

adriand wrote: post #39
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 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?

Re: Why I'm Not Using RubyMotion in Production

#42

Post by zw »

ef4 wrote: post #19

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

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.

Re: Why I'm Not Using RubyMotion in Production

#43

Post by zw »

Veraticus wrote: post #14
1123581321 wrote: post #10

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.

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.

Re: Why I'm Not Using RubyMotion in Production

#44

Post by spartango »

zachgersh wrote: post #2

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.

Re: Why I'm Not Using RubyMotion in Production

#45

Post by hboon »

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.

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?

Re: Why I'm Not Using RubyMotion in Production

#46

Post by hboon »

mikeash wrote: post #37
jimbokun wrote: post #33

Earlier quoted context omitted.

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

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.

Re: Why I'm Not Using RubyMotion in Production

#48

Post by krichman »

sjtgraham wrote: post #35
easyd wrote: post #32

Earlier quoted context omitted.

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

Re: Why I'm Not Using RubyMotion in Production

#49

Post by bricestacey »

adriand wrote: post #39
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 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.

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)

Re: Why I'm Not Using RubyMotion in Production

#50

Post by krichman »

sjtgraham wrote: post #41
adriand wrote: post #39

Earlier quoted context omitted.

> 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.
Post reply on HN