4 ms·

My feelings of late have been: 1. Ruby is not built from the ground up for concurrency and eventing. You can use a number of great tools to effect that, but it

My feelings of late have been: 1. Ruby is not built from the ground up for concurrency and eventing. You can use a number of great tools to effect that, but it isn't built for that from the ground up. 2. Rails continues to forge ahead with weird JS and asset management at the Ruby community's peril. We need to be taking a very serious look at tools like: http://scorchedrb.com/ http://scorchedrb.com/ - which provides a (more) correct pattern for routing and things like https://github.com/apotonick/trailblazer https://github.com/apotonick/trailblazer which provides an alternative code organization method which might make more sense. Most of our web apps are essentially state machines and the only framework which acknowledges it is: https://github.com/seancribbs/webmachine-ruby https://github.com/seancribbs/webmachine-ruby 3. Ruby needs to be faster. The community needs to get library support for 2.2 ASAP. We need to use Fibers and we need to use Celluloid. https://github.com/celluloid/celluloid/ https://github.com/celluloid/celluloid/ 4. I'd love to see in 2015 less new projects (fragmentation?), but more forking and more collaboration. That goes for the JS world as well.

cheald 12y ago
1. JRuby's definitely built for concurrency, though I suspect you're kind of leaning towards Node with this comment. It's certainly true that Ruby doesn't comprehensively do reactor-pattern stuff as well as Node, but threading on JRuby works wonderfully well. 2. I definitely agree about Rails and the asset pipeline. It feels awkward and kludgey and particularly in relation to JS I'd like to see code organization and tooling stepped up; many of the apps we're writing today are heavily Javascript, and it's a lot of work to maintain a large JS app on top of a Rails app right now. That's not to say that it's prohibitive, but Rails built a name for itself by making the drudgery less painful, and this is an open pain point. 3. Agreed, though JRuby is again a trailblazer here; boot-up time sucks (I'm working on that over Christmas break!), but 9k and the Truffle+Graal projects are huge leaps forward, and once JIT kicks in, JRuby's long-term performance is really excellent. MRI continues to make strong advances here, as well; the discussions around MRI 3.0 have hinted at some really good stuff coming down the pipe. 4. Can you elaborate on what specifically you mean? Ruby as a whole is absolutely stronger for the "new projects" (RBX, JRuby, Topaz); while issues like this can become divisive, I'll argue that RBX has been a net positive to the Ruby community, both because of RubySpec (a different perspective is valuable, even if it doesn't become the official spec) and because a new approach to a problem generally ends up leaking improvements all over the ecosystem.
- whistlerbrk 12y ago
  We're on the same page here, especially re #2. And I think it's high time I give JRuby a real shot. As for #4, I'm all for those mentioned, low-level (and fascinating) projects. And for projects surrounding programming paradigms e.g. Celluloid, EM... I was really referring to libraries, but on second thought #4 isn't that a big of an issue in Ruby-land, it's mostly a JS world problem. I suppose my particular fear is that instead of re-organizing code within Rails as an example, the community will opt to make another new framework instead, increasing fragmentation.
  - cheald 12y ago
    This is somewhat off topic, but since you mention wanting to try JRuby, I'll give you my spiel. :) I'm a recent JRuby convert (I've only started using it heavily in the last year), but I can't say enough good about it. It's mature, reliable, and really easy to work with. The Java code is extremely easy to read (especially compared to MRI), and integrating Java libraries with your Ruby code is trivial - you don't even have to write bindings, you just require a jar and then start referencing constants. This really shines in places where CRuby has lagged behind - places like numeric computing and natural language processing. The library support is iffy at best, and usually the answer is "use python", but when you can just drop in a Java library and call it a day, stuff gets really fun. Profiling a live JRuby app with JMX and jvisualvm is amazing - I can attach to a live, remote production instance and perform heap dumps, start sample profiling, or even execute Ruby code! Going to back to fix our MRI apps has left me very discontent with the state equivalent tooling :) My primary complaint with Java is that it's verbose and lends itself to overcomplex design, but I absolutely love that I can write high-performance code in Java and then write all my business logic in Ruby - it's the best of both worlds. To illustrate, I wrote Manticore (https://github.com/cheald/manticore https://github.com/cheald/manticore) to solve my persistent discontent with the state of HTTP clients in Ruby; the Apache Commons HTTP components are extremely comprehensive, fast, powerful, etc, but the API is horrific. I spent a bit of time wrapping them up in a nice idiomatic Ruby interface, and ended up with an HTTP client that destroys the pure Ruby clients for features and performance, and even beats out even Typhoeus (which is really just a set of libcurl bindings) - and all in only 700 lines of code! Finally, the JRuby community is so welcoming and inclusive. #jruby on Freenode is populated with all the project core members, and they are very willing to answer questions and help out. headius (Charles Nutter) has turned around bugfixes for issues in minutes (in addition to being extremely friendly and helpful), and they as a group have made it very easy for me to contribute to the project. I've gotten a few dozen pull requests accepted into master in the last few months, and thoroughly enjoy working on it. It has easily been one of my best experiences in open source.

cheald 12y ago

1. JRuby's definitely built for concurrency, though I suspect you're kind of leaning towards Node with this comment. It's certainly true that Ruby doesn't comprehensively do reactor-pattern stuff as well as Node, but threading on JRuby works wonderfully well. 2. I definitely agree about Rails and the asset pipeline. It feels awkward and kludgey and particularly in relation to JS I'd like to see code organization and tooling stepped up; many of the apps we're writing today are heavily Javascript, and it's a lot of work to maintain a large JS app on top of a Rails app right now. That's not to say that it's prohibitive, but Rails built a name for itself by making the drudgery less painful, and this is an open pain point. 3. Agreed, though JRuby is again a trailblazer here; boot-up time sucks (I'm working on that over Christmas break!), but 9k and the Truffle+Graal projects are huge leaps forward, and once JIT kicks in, JRuby's long-term performance is really excellent. MRI continues to make strong advances here, as well; the discussions around MRI 3.0 have hinted at some really good stuff coming down the pipe. 4. Can you elaborate on what specifically you mean? Ruby as a whole is absolutely stronger for the "new projects" (RBX, JRuby, Topaz); while issues like this can become divisive, I'll argue that RBX has been a net positive to the Ruby community, both because of RubySpec (a different perspective is valuable, even if it doesn't become the official spec) and because a new approach to a problem generally ends up leaking improvements all over the ecosystem.

whistlerbrk 12y ago
We're on the same page here, especially re #2. And I think it's high time I give JRuby a real shot. As for #4, I'm all for those mentioned, low-level (and fascinating) projects. And for projects surrounding programming paradigms e.g. Celluloid, EM... I was really referring to libraries, but on second thought #4 isn't that a big of an issue in Ruby-land, it's mostly a JS world problem. I suppose my particular fear is that instead of re-organizing code within Rails as an example, the community will opt to make another new framework instead, increasing fragmentation.
- cheald 12y ago
  This is somewhat off topic, but since you mention wanting to try JRuby, I'll give you my spiel. :) I'm a recent JRuby convert (I've only started using it heavily in the last year), but I can't say enough good about it. It's mature, reliable, and really easy to work with. The Java code is extremely easy to read (especially compared to MRI), and integrating Java libraries with your Ruby code is trivial - you don't even have to write bindings, you just require a jar and then start referencing constants. This really shines in places where CRuby has lagged behind - places like numeric computing and natural language processing. The library support is iffy at best, and usually the answer is "use python", but when you can just drop in a Java library and call it a day, stuff gets really fun. Profiling a live JRuby app with JMX and jvisualvm is amazing - I can attach to a live, remote production instance and perform heap dumps, start sample profiling, or even execute Ruby code! Going to back to fix our MRI apps has left me very discontent with the state equivalent tooling :) My primary complaint with Java is that it's verbose and lends itself to overcomplex design, but I absolutely love that I can write high-performance code in Java and then write all my business logic in Ruby - it's the best of both worlds. To illustrate, I wrote Manticore (https://github.com/cheald/manticore https://github.com/cheald/manticore) to solve my persistent discontent with the state of HTTP clients in Ruby; the Apache Commons HTTP components are extremely comprehensive, fast, powerful, etc, but the API is horrific. I spent a bit of time wrapping them up in a nice idiomatic Ruby interface, and ended up with an HTTP client that destroys the pure Ruby clients for features and performance, and even beats out even Typhoeus (which is really just a set of libcurl bindings) - and all in only 700 lines of code! Finally, the JRuby community is so welcoming and inclusive. #jruby on Freenode is populated with all the project core members, and they are very willing to answer questions and help out. headius (Charles Nutter) has turned around bugfixes for issues in minutes (in addition to being extremely friendly and helpful), and they as a group have made it very easy for me to contribute to the project. I've gotten a few dozen pull requests accepted into master in the last few months, and thoroughly enjoy working on it. It has easily been one of my best experiences in open source.