sigh I wish I could get excited about MRI releases. It's one of the most disappointing parts of using Ruby for my daily grind. The sluggish pace of innovation is sometimes demoralizing. Until 1.9.2, released a year after 1.9.1, and 4 years after 1.9.0, the 1.9 branch was too unstable for production use. Why were 1.9.0 and 1.9.1 GA releases again? The GC also still sucks, so the performance improvements from 1.9 are mostly nullified in real world applications.
Sometimes I wish the work on alternative implementations would be devoted to effort on MRI, but I understand this is a much more complex issue than it appears on the surface. It seems like all of the developers interested in real change in MRI that have the skills to make that change have hopped on to more interesting alternative implementations or left Ruby altogether.
While I've put JRuby in production for some smaller, non-Rails codebases that used JVM libraries, I've tried to run some non-trivial Rails applications on JRuby and it's just too slow for development work. Load time on code seems to be an order of magnitude slower, which is real time that adds up over a day worth of work to be something significant, so I'm back to REE. Rubinius is cool and they've come an amazingly long way, but personally I think the project suffers from what I'm going to call "sufficiently smart compiler" syndrome. After 5 years of work, they're still not even close to JRuby or MRI performance on real-world applications.
I've spent hours and hours understanding the technical and human reasons why all of these problems exist, but unfortunately the reality of shipping things trumps.
I guess that's why I've got this Clojure book in front of me.
The key with 1.9.3 is it's essentially work on producing a better implementation internally. The language is mostly unchanged since 1.9.2 but 1.9.3 is a lot faster in specific situations. Couple this with the newly customizable GC settings (I'll be blogging about this shortly) and 1.9.3 is shaping up to be a fine release. 37signals are already using it in production, even.
Does anybody know if the parallel tests will be ported to test-unit 2.x? Or if it is actually using minitest to do so: Is there a way to get minitest to output junit compatible xml? (ci_reporter doesn't support minitest)
[+] [-] rbranson|14 years ago|reply
Sometimes I wish the work on alternative implementations would be devoted to effort on MRI, but I understand this is a much more complex issue than it appears on the surface. It seems like all of the developers interested in real change in MRI that have the skills to make that change have hopped on to more interesting alternative implementations or left Ruby altogether.
While I've put JRuby in production for some smaller, non-Rails codebases that used JVM libraries, I've tried to run some non-trivial Rails applications on JRuby and it's just too slow for development work. Load time on code seems to be an order of magnitude slower, which is real time that adds up over a day worth of work to be something significant, so I'm back to REE. Rubinius is cool and they've come an amazingly long way, but personally I think the project suffers from what I'm going to call "sufficiently smart compiler" syndrome. After 5 years of work, they're still not even close to JRuby or MRI performance on real-world applications.
I've spent hours and hours understanding the technical and human reasons why all of these problems exist, but unfortunately the reality of shipping things trumps.
I guess that's why I've got this Clojure book in front of me.
[+] [-] masnick|14 years ago|reply
Scroll down on that page for some more lengthy explanation.
[+] [-] petercooper|14 years ago|reply
The key with 1.9.3 is it's essentially work on producing a better implementation internally. The language is mostly unchanged since 1.9.2 but 1.9.3 is a lot faster in specific situations. Couple this with the newly customizable GC settings (I'll be blogging about this shortly) and 1.9.3 is shaping up to be a fine release. 37signals are already using it in production, even.
(Plug: And for anyone on 1.8 who's ignorant of what 1.9 is about, I have something to help you at http://rubyinside.com/19walkthrough/)
[+] [-] Fluxx|14 years ago|reply
https://gist.github.com/1117138
[+] [-] petercooper|14 years ago|reply
[+] [-] thibaut_barrere|14 years ago|reply
[+] [-] chrismealy|14 years ago|reply
[+] [-] hasanove|14 years ago|reply
if i understand this correctly, it seems like it isn't...
"It can not be merged in 1.9.3, because it is late."
[+] [-] cies|14 years ago|reply
[+] [-] rb2k_|14 years ago|reply
[+] [-] phzbOx|14 years ago|reply
Also:
might be useful.[+] [-] trebor|14 years ago|reply
And random with a range parameter is useful shorthand.
Anyway, I'm more enthusiastic about performance improvements where file loading is concerned.