Rubinius 2.0 released
rubini.us
rubini.us
As someone who has been working with MRI since 2006-ish, I feel this statement is accurate. MRI is stagnating around the GIL. Rails last lost some of it's edge and this is in part responsible. Since about 2011, I've invested into Erlang (elixir), and mostly NodeJS. They're truly communities that are evolving well, they are applying themselves well to new problems inherit to changes in application building demands.
That seems a bit over the top.
Ignoring the steady stream of improvements/features in MRI in the 1.9-2.1 timeframe, even from the thread-based-concurrency side there have been improvements (e.g. thread safe/async IO libraries replacing older ones).
If rails lost some of it's edge compared to an Erlang based platform, it's because people have awaken from the hype dream they were living in, as they should have never have used it for that job anyway.
Rationally concluding that X is the best fit for your problem is not what I'm arguing against.
What I'm stating is that often the technology choice is driven more by fashion then by technical merits.
E.g. in 2007, rails may have been a better choice to build a web chat than erlang or java, but it's more likely that it was just more "hip".
"If {language} lost some of it's edge compared to an {other language} based platform, it's because people have awaken from the hype dream they were living in, as they should have never have used it for that job anyway."
and compare it this passage that Bruce Eckel wrote in 2005:
"The {language} hyper-enthusiasts have left the building, leaving a significant contingent of {language} programmers behind, blinking in the bright lights without the constant drumbeat of boosterism. But the majority of programmers, who have been relatively quiet all this time, always knew that {language} is a combination of strengths and weaknesses. These folks are not left with any feelings of surprise, but instead they welcome the silence, because it's easier to think and work. Where did the hyper-enthusiasts go? To Ruby, apparently."
This video gives some good insight into what led to his decision to start fresh rather than try and change things in Ruby http://m.youtube.com/watch?v=SAc0vQCC6UQ
So that's probably the biggest thing about Node - everything in the core is built with event orientation in mind, so you know you're not going to hit something that will block and kill you, and that minset is pervasive in userland too.
When you're doing that kind of programming, I think it's better to use a language or ecosystem designed specifically for that purpose rather than use a library such as Twisted or EventMachine which is inside another language that may or may not support what you're doing. This has no basis in theory or anything, just my own experience. Makes things easier for me, that's all.
They do cause resource exhaustion in the developer who has to deal with the cascading callback spaghettis.
First gear is shit, I always to have move off it to go fast on the highway.
> Ruby became popular because Ruby on Rails accelerated the delivery of value by an order of magnitude. This influence is rapidly declining. Efficiencies that Rails introduced, things like convention over configuration and full-stack integration, also encouraged monolithic application architectures. Applications built this way are difficult to change and difficult to scale, which means that under changing conditions, their costs tend to quickly outweigh any value they deliver. Businesses are rapidly learning this lesson.
Rapid being the operative word ironically enough.
So that makes for half about the irony you are accounting for, the other half coming from you (and I really can't see no reason for it unless you had a hard time liking ruby/rails, which in turn would represent a very poor reason).
I do think the Rails hate is overdone, considering Rails is still good at what it's good at - enabling you to build features fast enough to outpace competitors so that you get to the point where you actually have scalability problems. That's pretty valuable in and of itself. Hopefully projects like Rubinius will shore up the performance/scalability issues, though competing with the millions of man-hours spent making the JVM massively robust and performant will be a challenge.
Don't even mention LinkedIn, they don't even know what they doing. They were using like Mongrel version -2 and Rails -0.3, when they decided they had issues with there mobile platform and moved it to NodeJS.
For most of the companies that HNers talk about, whether they use Python or Rails or Scala or Node is only relevant in so far as it helps them iterate quickly and gain traction, and that's what investors care about.
Unless your strategy is dependent on choosing a particular technology (which, in the context of the web, usually means "build around the JVM"), your tech stack is not remarkably relevant to investors as long as it's part of an active ecosystem.
and the elephant in the room (Scala) goes unmentioned.
Does anyone have any pointers on how to keep the latest RBX up to date in RVM?
Will heroku be supporting RBX's new weeklyish release cycle?
Thanks to Matz, DHH, Evan Phoenix. Thanks to the hundreds of contributors. Thanks to Engine Yard for the $$$. Thanks to the community.
Rubinius 2 will target Ruby 2.1. We're brining Ruby into the future! We will not support multiple Ruby language versions moving forward.
Version releases are changing with the release of Rubinius 2.0. There will be a new release once a week, won't follow a pre-determined release schedule. Master branch will be kept extremely stable. New versions will be X.Y.Z+1. Please post issues, hopefully they will be fixed quickly.
The goal is to semantically version the Rubinius core starting with version 3.0. We've added a subdomain http://releases.rubini.us for hosting release tarballs.
About Rubinius Parts:
* It has a VM that runs byte code produced by the Ruby compiler. Every Ruby method gets its own interpreter.
* The generational garbage collector (GC) has a very fast young generation collector, usually pausing for less than 15 ms to complete a collection.
* Rubinius implements native operating system threads for concurrency and has no global interpreter lock (GIL). Ruby code can run in parallel on multi-core or multi-CPU hardware.
* The Rubinius just-in-time compiler (JIT) turns Ruby bytecode into machine code. The JIT thread is mostly independent of the Ruby threads so the JIT operation doesn't impact the running code's performance.
* The Rubinius core libraries (e.g. Array, Hash, Range, etc.), as well as Rubinius tools like the bytecode compiler, are written in Ruby. The Rubinius systems treat them just like Ruby application code.
Commenters note: There's a whole section called "Plans, Meeet Future" which seems to say Ruby hasn't kept pace with the "SaaS revolution." Honestly, not sure what as going on here, I'll punt on a summarizing.
Plans for improvement:
* Significantly improve concurrency coordination in the system. Some operations requires topping all threads. Working to get rid of this.
* Provide more efficiency by using more modern lock-free concurrent data structures.
* Make the GC more concurrent and parallel.
* Make the JIT even faster and expose more of it to regular Ruby code.
Gems as Components:
* Major components, like the bytecode compiler, Ruby parser, debugger, etc. have been moved to gems. These components can be updated easily and quickly without requiring a Rubinius release.
* In Rubinius 2.0, the Ruby standard library has also been converted to gems.
The post then reflects on how Rubinius has inspired other projects: RubySpec, Topaz, Opal, Puma, etc.
And it ends with: "Ruby is an excellent language. Rubinius is dedicated to providing Ruby developers with excellent tools and technology competitive with these other languages. Developers who are happy writing Ruby shouldn't be forced to leave it because of technical limitations."
I wonder what this means for RubySpec?
Now, Rubinius 2.0, Ruby 2.1, Topaz, JRuby.
Exciting time for Ruby implementation.
So, when people refer to "Ruby," they are most commonly referring to two things: the language, and the default interpreter. The default interpreter is known as "MRI," which stands for "Matz's Ruby Interpreter."
Rubinius is an alternative Ruby interpreter. It's main claim over MRI is that Rubinius has (much) better support for multi-threaded applications. Additionally, where much of the core Ruby functionality (e.g., Array) is built using C in MRI, Rubinius builds most of it's core functionality using pure Ruby code, and relies on the interpreter to make it fast enough, similar to PyPy. The theory is that if you build a fast enough interpreter, it's easier to build your dynamic language functionality in the dynamic language, rather than in C.