7 ms·
Ruby's Biggest Challenge for 2009
- davidw 18y agoI wish you'd use LangPop.com for stats instead of TIOBE:-) I agree about the marketing/communication aspect of things though: I was under some sort of impression that 1.9 was, like "odd numbered Linux kernels" some sort of permanent-beta. I'm not quite sure where I got that idea, but a few other people I know seemed to be under the same impression. Something else that might help is a prominently located guide/tutorial to upgrading to 1.9.
- acangiano 18y agoGood point about LangPop, David. I will reference it in future posts.
- tesseract 18y agoI believe that 1.9 was supposed to be a beta (1.5 and 1.7 were), but the plans for 2.0 got to be too ambitious and there came a need for a version number between 1.8 and 2.0. I suppose it could have been called 1.10 but there were presumably good reasons.
- chrislo 18y ago> I suppose it could have been called 1.10 but there were > presumably good reasons. If I remember correctly, that's due to the way ruby sorts strings ['1.8','1.9','1.10'].sort #=> ["1.10", "1.8", "1.9"]
- tesseract 18y agoAh. Maybe it should have been done in hex? %w[1.8 1.9 1.A].sort #=> ["1.8", "1.9", "1.A"]
- sho 18y agoHm, Rails still doesn't work fully on 1.9.1. There's a few bugs relating to character encoding in templates still, you can find details on Lighthouse. It mostly works though. I've switched exclusively to 1.9.1 for console work, which is unaffected by the ActionView bug. I agree with the point about how projects not being ported to 1.9 begin to look unmaintained. It's been 3 months in stable now, and a year of betas before that - I can't help but start thinking any project not moving as fast as possible towards compatibility might not be one anyone should be relying on. Most unforgivable offenders: Mongrel and the DB libraries Most pleasant surprise: RMagick!
- acangiano 18y agoThanks sho. I edited that sentence about Rails and linked the word "complete" to your comment.
- sho 18y agoOops - I didn't want to make a big fuss about it! It's only when you're using unicode in templates, won't affect the vast majority of people. It 99.9% works : )
- sabon 18y agoWell, for all those developers outside US it's more like 0,01% works, because unicode is always used in templates. But hopefully it'll soon be resolved.
- charlesju 18y agoI don't think anyone thinks Ruby 1.9 is a stepping stone for Ruby 2.0. We're not using it because it isn't fully supported yet by Rails (so /agree sho). Perhaps more importantly, a lot of us are waiting for Rails 3.0 to move our existing applications over since there are huge risks and pains with shifting to a new version of a framework from something that currently works fairly well.
- sho 18y ago
- jd 18y agoRails is in a though spot right now. Facing a big challenge, a huge challenge even. And arguably, a challenge it didn't have to face. Why introduce a new VM and break backwards compatibility at the same time? Why not first give people a better VM, with bytecode, better threads and all the other goodies? When people know that upgrading is painless (think Perl) then you can just upgrade without thinking twice about it. If you know you have to check the compatibility checklist of all software you have ever installed (for all you know your text editor depends on Ruby nowadays) then upgrading becomes a very unappealing task. So, step one: introduce new VM. Step two, still don't break backwards compatibility. -If- you have to break the language, at least put some legacy mode in, so people don't have to port every script on their system.
- joe_the_user 18y agoWhy introduce a new VM and break backwards compatibility at the same time? I agree that "Big bangs" aren't always a good idea. However, what I believe is the case is - Any language geeks can feel to tell me I'm wrong here - is that the new VM benefited tremendously from making Ruby's syntax more regular. "MRI", Matzo's Ruby Interpreter, produced the unfortunate effect of making whatever its haphazard result were into "Standard Ruby". Making a faster interpreter that preserved all this stuff would be hard. So in this case, a "big bang", however painful, made sense
- Andys 18y agoThe incompatibilities that have hit hardest are for the modules that use C language extensions. This can't really be helped for such a major change to the underlying structure. The ruby language changes were mostly included in Ruby 1.8.7, and so most "pure ruby" libraries that worked there also work in 1.9.
- kgrad5 18y agoI think Ruby's biggest challenge for 2009 will be getting standardized.
- jwilliams 18y agoI saw "GIL" and had a look into it (Global Interpreter Lock apparently) - seems like a very heavy-handed mechanism to put in. In fact, it seems, well, extremely lazy -- but I'm not sure I understand the thinking behind it. Are there pros/cons to having a GIL approach?
- rcoder 18y agoWithout a GIL, you not only have to make sure that your entire VM + runtime are re-entrant, but that every library you call into is, too. You can call it "lazy," but it's a fairly standard + pragmatic way to safely layer multi-threading atop arbitrary C libraries.
- jballanc 18y agoAdd to that the fact that, without the GIL, there becomes a need to define what qualifies as an atomic operation. Since Ruby didn't have a standard bytecode until recently, this ends up being an implementation-specific nightmare (even with the YARV bytecode, it's still an implementation-specific issue not likely to be resolved soon). In other words, without GIL, what's thread-safe in MRI might not be in JRuby or vice versa.
- davidw 18y agoThe successful approach seems to be what Tcl (and Perl, I hear) do: one interpreter per thread, with message passing/shared memory.
- FooBarWidget 18y agoI don't know about Tcl, but Perl's approach is anything but successful. I have a Perl app of about 40000 lines. It takes 15 seconds to create a single thread, and after it's done, Perl segfaults. Every Perl thread duplicates the AST, making memory usage bloat to ridiculous proportions. I found out that forking new processes is faster and uses less memory.
- berntb 18y ago
- villageidiot 18y agoI think the author makes a good case for the upgrade. But I was fairly confident that the migration would happen later if not sooner. The more interesting question for me is why interest in Ruby has been dropping off.