Matt Aimonetti writes about Ruby, Merb, MacRuby and RubyMotion, covering Ruby development on Apple platforms and the Ruby community.
HN links it for MacRuby and RubyMotion commentary, including his review of RubyMotion, and for his posts about Apple and open-licensed books.
Pure Ruby code in MRI 1.9 can run on multiple OS threads, but it can't run on multiple OS threads in parallel. Here's some reading you can do if you're unsure:
http://merbist.com/2011/10/03/about-concurrency-and-the-gil/
http://www.igvita.com/2008/11/13/concurrency-is-a-myth-in-ruby/
http://jabberwocky.eu/2010/10/02/where-is-the-global-interpreter-lock-/
http://en.wikipedia.org/wiki/Global_Interpreter_Lock
Yes: Ruby can allow native code to execute in parallel with Ruby code (although it doesn't always do so, as you note). But if you're under the impression that multiple Ruby threads can execute in parallel, you're wrong. That may or may not be a problem, depending on what you need Ruby to do.
JRuby can be a good option for parallelism, but it's also slower than Ruby MRI 1.9 and has an ecosystem that most Ruby developers will be unfamiliar with. Regardless, my point was that Rails doesn't magically "work with multithreading," at least for standard Ruby deploys.
I find that it's a happy day, not a sad day (even if I like open-source).
Why? Because now some of my customers are going to seriously think about using Ruby for Mac OS X apps, because they know someone is making profit while supporting this, so they feel they can rely on this.
I much prefer this to the fate of IronRuby (or to some extent, MacRuby).
Remember what you wrote one year ago [1] ?
Using RubyMotion for a professional product represents
a significant business risk, which is exactly the same
as using proprietary technology from any vendor.
It turns out the opposite is coming to reality :p
[1] http://merbist.com/2012/05/04/macruby-on-ios-rubymotion-review/
As I recall, BridgeSupport created indexes to C symbols, enumerations and functions by producing XML files [1] that corresponded to C APIs like CoreGraphics, and code you produced yourself.
You don't necessarily need BridgeSupport to call out to Objective-C.
Speaking of BridgeSupport, does anybody know where the most recent source code for that project went? It seems to have been removed from Apple's Mac OS Forge after Laurent Sansonetti left Apple. A shame.
[1] - For example, http://merbist.com/2011/02/19/bridgesupport-build/ . The chapter referenced from O'Reilly's excellent MacRuby book does a better job of explaining the whole process.
More links:
http://weblog.rubyonrails.org/2008/12/23/merb-gets-merged-into-rails-3
http://yehudakatz.com/2008/12/23/rails-and-merb-merge/
http://rubyonrails.org/merb
http://merbist.com/2008/12/23/rails-and-merb-merge/
http://brainspl.at/articles/2008/12/23/merb-is-rails
http://loriholden.com/archives/2008/12/23/16-merb-is-rails-30
http://mornini.wordpress.com/2008/12/23/rails-2x-merb-1x-rails-30/
http://splendificent.com/2008/12/the-merb-rails-merger-announcement-an-inside-opinion/
Yes.
"Merb has an API. You might be wondering why having an API is awesome. Well, the truth is that the Merb Team spent time marking methods public, which are guaranteed to not break until the next major release (any change to the public API will be well documented). There is also a plugin API meaning that plugin developers won’t have to worry about upgrades if they stick to the plugin API."
From: http://merbist.com/2008/11/09/merb-1-0-released/
Matt Aimonetti, the author of the presentation, is not an Apache CouchDB committer. He is a Merb and Rails developer:
- http://merbist.com/about/
This controversy is very much about the Rails community. It's the Rails community leaders who are defending Matt. If this had been an Apache committer you would have seen a clear and swift apology from the ASF and likely a huge mailing list thread about how this behavior isn't helpful.