tag:blogger.com,1999:blog-20975090.post8330856640437642141..comments2024-03-11T10:18:55.852-05:00Comments on Headius: Promise and Peril for Alternative Ruby ImplsCharles Oliver Nutterhttp://www.blogger.com/profile/06400331959739924670noreply@blogger.comBlogger38125tag:blogger.com,1999:blog-20975090.post-86254282477235594962008-08-19T01:10:00.000-05:002008-08-19T01:10:00.000-05:00regarding rails and ruby 1.9, I'm not sure but I b...regarding rails and ruby 1.9, I'm not sure but I believe it to be compatible now.<BR/>http://blog.codefront.net/2008/05/25/living-on-the-edge-of-rails-22-pre-railsconf-2008-edition/Roger Packhttps://www.blogger.com/profile/01578246846716577925noreply@blogger.comtag:blogger.com,1999:blog-20975090.post-84021376704407394262008-08-19T01:07:00.000-05:002008-08-19T01:07:00.000-05:00The assertion that " you can't scale Ruby 1.9 any ...The assertion that " you can't scale Ruby 1.9 any better on wide systems than you could with Ruby 1.8" is hopefully going to be overcome by the use of asynchronous database drivers [1] [2] plus fibers. We can only hope :)<BR/>[1]http://oldmoe.blogspot.com/2008/07/faster-io-for-ruby-with-postgres.html<BR/>[2]http://github.com/tqbf/asymy/tree/master<BR/>[3] rails works on 1.9 http://blog.codefront.net/2008/05/25/living-on-the-edge-of-rails-22-pre-railsconf-2008-edition/#comment-664800<BR/> <BR/>I'd also say that after the release of 1.9.1 people will start to adopt it more and it will become the new de facto standard.Roger Packhttps://www.blogger.com/profile/01578246846716577925noreply@blogger.comtag:blogger.com,1999:blog-20975090.post-47663809446468401322008-05-05T18:46:00.000-05:002008-05-05T18:46:00.000-05:00Nice overview, thanks Charles. MacRuby suprised me...Nice overview, thanks Charles. MacRuby suprised me, I missed the news about it.LacKachttps://www.blogger.com/profile/16538385959945797364noreply@blogger.comtag:blogger.com,1999:blog-20975090.post-66991696579631326212008-05-03T19:13:00.000-05:002008-05-03T19:13:00.000-05:00For what it's worth, Stephen Weeks has just resume...For what it's worth, Stephen Weeks has just resumed work on Cardinal.Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-20975090.post-46061860168784564412008-05-03T08:33:00.000-05:002008-05-03T08:33:00.000-05:00@charles: I'm sorry I should have been clearer. I ...@charles: I'm sorry I should have been clearer. I was talking about *yet another* problem with ruby's green threads :)<BR/><BR/>Namely that communication between ruby's green threads and POSIX threads are hard to do right and so in 1.8, threads are almost useless in combination with UI stuff. Luckily for us Cocoa provides lots of nice APIs that can work around this.<BR/><BR/>For more info see: http://trac.macosforge.org/projects/ruby/wiki/WhyMacRuby<BR/><BR/>Cheers,<BR/>EloyAnonymousnoreply@blogger.comtag:blogger.com,1999:blog-20975090.post-73717634338786733592008-04-29T15:16:00.000-05:002008-04-29T15:16:00.000-05:00One addition to the "New Contenders" section: The ...One addition to the "New Contenders" section: The <A HREF="http://www.ruby-php.org/" REL="nofollow">Ruby.PHP project</A>, which is a Ruby to PHP compiler that I am writing as my Master's thesis.<BR/><BR/>As I write in the FAQ at the project website, it is in the early stage of development (no "inflection point" in the near future :-), however the compiler is already able to translate simple Ruby scripts into (somewhat ugly) PHP and run them.<BR/><BR/>There is an <A HREF="http://www.ruby-php.org/demo" REL="nofollow">online demo of the compiler</A> on the web.Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-20975090.post-63945440700083818922008-04-29T14:11:00.000-05:002008-04-29T14:11:00.000-05:00> People are not flocking to Ruby 1.9 in drovesPer...> People are not flocking to Ruby 1.9 in droves<BR/><BR/>Perhaps that has less to do with "we're not interested" and more to do with--oh, I don't know--maybe the fact that they are *actively discouraged* from using it in production? =)Philhttps://www.blogger.com/profile/12517691336187602116noreply@blogger.comtag:blogger.com,1999:blog-20975090.post-76267534333474029362008-04-29T12:52:00.000-05:002008-04-29T12:52:00.000-05:00dan moore: There's no one library that serves that...dan moore: There's no one library that serves that purpose, but there are dozens of libraries written to fill some or all of that purpose. Some are written during the course of a language's implementation and never repurposed. Some are built with the express intent of building several languages on top of them. So although it would be nice to have a "one library to rule them all", there have been DLR equivalents of varying completeness on the JVM for years.<BR/><BR/>I'd love to abstract out as much as possible from JRuby to help add another tool to that toolbox.Charles Oliver Nutterhttps://www.blogger.com/profile/06400331959739924670noreply@blogger.comtag:blogger.com,1999:blog-20975090.post-81358413339085979392008-04-29T12:36:00.000-05:002008-04-29T12:36:00.000-05:00Is there an equivalent to MS's DLR for the JVM? I...Is there an equivalent to MS's DLR for the JVM? If not, could parts of JRuby's implementation be abstracted out to make one?Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-20975090.post-18919815135571026852008-04-29T09:13:00.000-05:002008-04-29T09:13:00.000-05:00eloy: Part of the problem with that is the fact th...eloy: Part of the problem with that is the fact that Ruby 1.9 doesn't allow its native threads to run concurrently. Perhaps it's a goal for MacRuby to eliminate the giant lock?<BR/><BR/>laurent: That certainly seems reasonable. I'm looking forward to trying MacRuby for OS X app development too, so hurry up :) And I suppose the 1.9/Rails thing will be solved by the time you have a release. I just hope it won't be too difficult for you to keep aligned with "real" 1.9's growing features and bug fixes.<BR/><BR/>bob aman: I think my concern with 1.9 specs is more that it's changing too fast. Sure, Ruby 1.8 has had a set of specs written after-the-fact, but it's also mostly frozen (ignoring 1.8.7 for the moment). 1.9 is still under active development. And my point about Rails on MacRuby was just that anyone who's interested in Rails and interested in MacRuby will try to bring the two together. You're right, anyone interested in MacRuby but not Rails on MacRuby will probably not try it :)Charles Oliver Nutterhttps://www.blogger.com/profile/06400331959739924670noreply@blogger.comtag:blogger.com,1999:blog-20975090.post-69965130267041714062008-04-29T08:53:00.000-05:002008-04-29T08:53:00.000-05:00@Michael KoziarskiAs far as we're aware there's on...@Michael Koziarski<BR/><BR/><I><BR/>As far as we're aware there's one remaining issue outstanding for 1.9 compatibility with edge rails, a bug in 1.9.<BR/></I><BR/><BR/>Wasn't really the crux of my argument, but if that's the case, then my bad, obviously a lot of progress has been made since the last time I took a look. That said, in my experience, it still takes awhile for bugs of any significance to get fixed in Ruby itself. So while it might not be Rails's fault, it may very well still end up being quite awhile before Rails can boast of Ruby 1.9 compatibility. Not all that familiar with the details of the bug in question though.<BR/><BR/>@Charles Oliver Nutter<BR/><BR/><I><BR/>Perhaps that's the case for MacRuby developers, but just about any Rubyist interested in MacRuby is going to try running Rails on it. </I><BR/><BR/>Maybe I'm misunderstanding your statement, not sure, but I think this is really far off the mark. If my purpose for using MacRuby is to write a GUI, I'm going to test that MacRuby meets my needs by writing a simple GUI app, not by trying to run Rails on top of it. Besides that, if what Michael said above is true, then Rails will most likely have achieved 1.9 compatibility long before MacRuby is done.<BR/><BR/><I><BR/>And I'm not entirely sure creating 1.9-compatible libraries is even a good idea right now... since 1.9 isn't entirely 1.9-compatible from day to day. What is Ruby 1.9? Do we have a spec? A test suite? Anything? If the answer is no, it's not ready.<BR/></I><BR/><BR/>Did Ruby 1.8 have a spec to start off with? Until Rubinius and friends came along, no. Don't get me wrong, a spec is a good thing. But the presence of a spec is not a prerequisite for usefulness. I'm not advocating that people try to maintain two versions of a library, one for 1.9 and one for 1.8. That would be insane. I would, however, like to see people making use of simple capabilities checks anywhere in a library that there's a known compatibility issue. For example, if you call [] on a string, you should be checking the return value and making sure you got what you expected. With careful short-circuiting in the checks, there shouldn't be any measurable performance penalty for doing so, and the gains are significant.Bob Amanhttps://www.blogger.com/profile/08770372909350717238noreply@blogger.comtag:blogger.com,1999:blog-20975090.post-26579776493640368582008-04-28T23:04:00.000-05:002008-04-28T23:04:00.000-05:00Charles, thanks for the kind words and the nice su...Charles, thanks for the kind words and the nice summary of MacRuby. I do agree with your point of view regarding MacRuby.<BR/><BR/>However, as others suggested, please note that running Rails is not a top priority at the moment. We want to focus on delivering a high quality solution to develop efficient Mac OS X applications, firstly. <BR/><BR/>As you also expected, I do not think that MacRuby _in its current shape_ will be faster than 1.9 generally speaking. Nevertheless, we also have a new GC which performs faster collections in a separate thread, and even if pure object allocation micro benchmarks reveal to be slower, this might probably change the typical behavior of a Rails app regarding memory usage (once 1.9 can run Rails of course). <BR/><BR/>And we have lots of ideas for the project, including the rewrite of more critical parts of the 1.9 source base. This is just the beginning :)Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-20975090.post-12327604771963539822008-04-28T18:55:00.000-05:002008-04-28T18:55:00.000-05:00Excellent article Charles, thanks for your time!I ...Excellent article Charles, thanks for your time!<BR/>I just wanted to chime in on the MacRuby part.<BR/><BR/>At least one good reason imo to use 1.9 is because of the native threads, which has been a long standing problem in RubyCocoa, it can be worked around but better is.... well better :)<BR/><BR/>And also, like said before, MacRuby is about being able to use Cocoa, not so much about existing Ruby code like Rails.<BR/>RubyCocoa is the same in this aspect, except it's for 1.8.<BR/><BR/>EloyAnonymousnoreply@blogger.comtag:blogger.com,1999:blog-20975090.post-87399047469261104732008-04-28T18:19:00.000-05:002008-04-28T18:19:00.000-05:00Joachim: Is hash ordering really the main feature ...Joachim: Is hash ordering really the main feature in 1.9 you're interested in? JRuby already has insertion-ordered hashes in 1.1, so that shouldn't prevent you from giving it a try.Charles Oliver Nutterhttps://www.blogger.com/profile/06400331959739924670noreply@blogger.comtag:blogger.com,1999:blog-20975090.post-5565722991234423362008-04-28T14:49:00.000-05:002008-04-28T14:49:00.000-05:00I understand the issues (somewhat), but I think th...I understand the issues (somewhat), but I think the biggest advantage with rubinius really is that it is a community project. Yes, it may be that evans writes most anyway ;) but the key really was that basically if you contribute, you do have the chance to influence.<BR/><BR/>And while I personally think that the rubinius project is lagging a tiny bit the last some months, I do believe that there is no REAL argument why this should not work. Just look at smalltalk and how much squeak is touted and loved (even though smalltalk probably no longer has the many coders that python and ruby has these days)Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-20975090.post-41936132706031590272008-04-28T12:51:00.000-05:002008-04-28T12:51:00.000-05:00I've posted a short retort concerning Rubinius at ...I've posted a short retort concerning Rubinius at <A HREF="http://blog.fallingsnow.net/2008/04/28/rubinius-retort/" REL="nofollow">http://blog.fallingsnow.net/2008/04/28/rubinius-retort/</A>.Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-20975090.post-2730852628193633762008-04-28T11:37:00.000-05:002008-04-28T11:37:00.000-05:00Microsoft's support for ruby - what's the strategy...<A HREF="http://consultinginaustin.wordpress.com/2008/04/28/microsofts-support-for-ruby-whats-the-strategy/" REL="nofollow">Microsoft's support for ruby - what's the strategy?</A>Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-20975090.post-17707981744001414732008-04-28T10:15:00.000-05:002008-04-28T10:15:00.000-05:00fuzzyman: I don't believe I was rude at all, or ev...fuzzyman: I don't believe I was rude at all, or even incorrect. As far as I can tell from monitoring the IronRuby list, the IronRuby team is having no design or dev discussions in the open. You can't run an OSS project that way. And there are plenty of historical examples of how damaging a private "trunk" repository can be to an OSS project. Tossing SVN bundles over the fence every so often does not foster a daily give-and-take with the community.<BR/><BR/>Ask yourself...doesn't it bother you that you can't update your working copy to the same sources the IronRuby team sees in the morning? Doesn't it bother you that they're having all their substantive conversations behind closed doors, leaving you to guess at progress?<BR/><BR/>These problems can certainly be remedied, but pretending they don't exist won't help anyone...and will damage IronRuby's long-term OSS prospects.Charles Oliver Nutterhttps://www.blogger.com/profile/06400331959739924670noreply@blogger.comtag:blogger.com,1999:blog-20975090.post-77967124802333994002008-04-28T09:50:00.000-05:002008-04-28T09:50:00.000-05:00Hi Charles (good article by the way - a very inter...Hi Charles (good article by the way - a very interesting read).<BR/><BR/>You're quite rude about the IronRuby development process. I must say that from being on the mailing list your description certainly doesn't *seem* right.<BR/><BR/>I think John might have some things to say about the technical points you raise - but the DLR has supported multiple engines for quite a while now.Michael Foordhttps://www.blogger.com/profile/06229713779852499022noreply@blogger.comtag:blogger.com,1999:blog-20975090.post-30458089308575652732008-04-28T08:43:00.000-05:002008-04-28T08:43:00.000-05:00fuzzyman: Ah, thank you, noted. I think I must hav...fuzzyman: Ah, thank you, noted. I think I must have assumed it was the first since it was the most visible in my realm.<BR/><BR/>sambo99: For what it's worth, JRuby has had that same level of openness for at least the 3.5 years I've been involved. And we've used existing community-driven test suites. The creation of the rubyspec is a great consolidation of testing, but it's certainly not the first such effort.<BR/><BR/>We would also like to move toward more Ruby code, but have opted for now to avoid the performance hit we'd incur doing so. Ruby can be made fast, certainly, and perhaps fast enough to build an entire runtime with, but the techniques and strategies necessary might hold back practical uses of JRuby. So we're pragmatic...JRuby works, and it runs fast. If it's not written in Ruby today, maybe it will be later.<BR/><BR/>jherber: The move to Object should reduce memory consumption, since core types will have fewer wrapping layer and Java integration will not require wrappers at all. And the dynamic invocation work for JDK7 will most certainly help: it will allow us to delete a lot of code and reduce substantially what code we generate at runtime, for a leaner Ruby; it will also mean we can leverage the JVM's much-better optimizations, rather than wiring our own. The future looks bright :)Charles Oliver Nutterhttps://www.blogger.com/profile/06400331959739924670noreply@blogger.comtag:blogger.com,1999:blog-20975090.post-73158537978647644312008-04-28T08:34:00.000-05:002008-04-28T08:34:00.000-05:00excellent state of the union charles! bravo!great...excellent state of the union charles! bravo!<BR/><BR/>great to hear after all your incredible work that jruby still has quite a few more tricks up the sleeve. do you think dynamic invocation work in open jdk will have a big impact on performance? do you think the move to java.lang.Object as ruby base will also affect memory footprint?jherberhttps://www.blogger.com/profile/17138349998684867855noreply@blogger.comtag:blogger.com,1999:blog-20975090.post-84201825548162681292008-04-28T06:25:00.000-05:002008-04-28T06:25:00.000-05:00> It's also unclear if people really *want* all of...> It's also unclear if people really *want* all of what Ruby 1.9 has to offer.<BR/><BR/>For me, just _one_ offering is enough to make me move to 1.9: To pass human-readable data through YAML_load / modify / YAML_dump cycles, I need hash insertion order preservation.<BR/><BR/>Not a spectacular new feature - yet for my little application a decisive advantage of Ruby over other languages.Unknownhttps://www.blogger.com/profile/15571425702241279960noreply@blogger.comtag:blogger.com,1999:blog-20975090.post-53338721939441162242008-04-28T04:55:00.000-05:002008-04-28T04:55:00.000-05:00Charlie, You write fascinating articles! One thing...Charlie, <BR/><BR/>You write fascinating articles! <BR/><BR/>One thing that I think is worth mentioning here about rubinius is the new trend for really open projects. Its not enough just to have your source open.<BR/><BR/>The whole github + lighthouse + downloadable open irc logs and a high quality spec suite lowers the bar for contributions. I like this trend, its good. <BR/><BR/>Erlangs actor pattern in ruby can really change the way we think about scalability. Thats good. <BR/><BR/>And the dream of Ruby in Ruby well that is really good, and I hope it comes good one day. <BR/><BR/>I keep on thinking that there must be a way to get the runtime to watch over whats going on and have it inline chunks that have not been performing well. Lots of small methods seems like a best practice when it comes to code maintainability, I think our VMs just need to get smarter when it comes to invocation. But this hellishly hard on a dynamic runtime. <BR/><BR/>Cheers<BR/>Samsambo99https://www.blogger.com/profile/17248950362509796501noreply@blogger.comtag:blogger.com,1999:blog-20975090.post-84669407745392042432008-04-28T02:52:00.000-05:002008-04-28T02:52:00.000-05:00Although it is at best 'innacurate to say that Iro...Although it is at best 'innacurate to say that IronRuby is "the first Microsoft project under the Microsoft Permissive License".<BR/><BR/>IronPython (and possibly other projects) were licensed under the 'Microsoft Permissive License', which was renamed to the Microsoft Public License, long before IronRuby. (long being relative of course...)Michael Foordhttps://www.blogger.com/profile/06229713779852499022noreply@blogger.comtag:blogger.com,1999:blog-20975090.post-16145662940783257512008-04-28T01:20:00.000-05:002008-04-28T01:20:00.000-05:00About "better Ruby" - this is the largest danger a...About "better Ruby" - this is the largest danger ahead. Having multiple incompatible forks, due to different understanding of "better".<BR/><BR/>My view of "better" is that you should be compatible with Matz, however hard that may be for you Java and Microsoft and other folks.<BR/><BR/>You can have internal mechanics of your own, but leave the language alone, please.<BR/><BR/>His vision of the language as "friendly" may not be the easiest to implement, but don't change the language so you can have faster implementation. Go code in Java instead.<BR/><BR/>I write programs in Ruby because of Ruby language (and Rails :-), not because of compile/execution speed (ditto for Rails). And since Ruby (and Rails) is already very popular despite this "huge failings" you describe, I would say changing the language is not so very urgent as some people would want everybody to think.Anonymousnoreply@blogger.com