> Concurrent and distributed applications aren't the future anymore, they are the present. They are vital to business success. The many talented developers that are passing over Ruby for Erlang, Go, Clojure and Node are draining Ruby of talent and vitality.
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.
> I feel this statement is accurate. MRI is stagnating around the GIL
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.
Right or wrong, we should all take a moment to consider the irony that people are now writing stuff like this:
"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."
If you dont mind me asking, what hype are you referring to? I think a lot of people are correct in assuming that Rails is a good solution for a large (largest?) class of web applications, from cruds to crud+some ajax and so on. We know for a fact that it is working for some really successful companies, so I think depicting people as living in some dream just for rationally concluding that a particular technology will suit them is, well, a stretch.
I've been breathing internet from 1999, and believe me, when Rails was born it was - specially compared with the former current status of web development - awesome and game changing. That justified hype brought a lot of people, specially designers, to Rails, and still brings them even if other tools are better suited for the task in hand, and you know what they say, "if all you have is a hammer, everything looks like a nail".
I love Ruby, but I have to agree with this. Scala is the language I'm slowly moving away from Ruby for. I describe it to people who love Ruby but haven't used Scala as "Ruby with types, that you don't need to know about". It's obviously A LOT more, but I've found using Scala and JRuby in conjunction is an amazing combo.
One thing I enjoy about NodeJS is their standard library is asynchronous until you want it to be. Most of the NodeJS libs in NPM are also designed in this way. With EventMachine, you have to be careful what you're using because some of those RubyGems will probably include blocking IO.
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.
The creator of Node was something of a Rubyist, i believe the main reason was around the stdlib / ecosystem not being event oriented, making it difficult to build non-blocking applications. EventMachine may well have strategies to defeat this, I just don't know.
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.
why this hate for rails and ruby on ycombinator?
and why this love for javascript on serverside. I never find javascript to be a great language. Callback, callback, everywhere:)
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.
What like Twitter? You could win the lottery 10 times before having a chance at starting a company that has scaling problems like Twitter. Besides Rails still exists in there stack.
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.
So I guess investors completely ignore the fact that maybe Rails is actually a factor in the initial phase of the life of a startup and allows you to build foundations at a fast pace while still providing great structure and good tooling, cause hell you have to "move off it" to "scale" (which a big percentage of the companies they invest in never have to face anyway, since they go bust before having to even face scaling issues).
First gear is shit, I always to have move off it to go fast on the highway.
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.
The reference is not terribly subtle. Here's what the current reality is, direct from Rubinius article.
> 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.
The subtle reference I was referring to (which made me mention Twitter) was that s/he wrote "scala" in place of "scale" in ["companies had to move off it to scale"] presumably by mistake, since it was later edited.
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).
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."
> Over time, we've tried to support multiple Ruby language versions, many different projects, old and new code, code that abuses every corner of MRI's ad hoc semantics, and every random, undocumented MRI C function with the Rubinius C-API compatibility layer. Unfortunately, this is unsustainable and not in the best interests of Ruby or Rubinius.
Ruby is what's known as an interpreted programming language. It was invented in Japan by a guy nicknamed Matz. You write code, save it to a file, and then a separate program "interprets" this file into code that the computer can understand.
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.
Congratulations to Brian, Dirkjan and all the other people involved in Rubinius. This is great news, I'm looking forward to test my apps on Rubinius 2.0!
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.