Introducing Rubinius X(rubini.us)
rubini.us
Introducing Rubinius X
http://rubini.us/2013/10/15/introducing-rubinius-x/
221 comments
I don't know why people keep complaining about Ruby's (MRI) speed. Yes, it's not that fast but for most programmer's doing web development it doesn't matter. Remember, you are (probably) not writing the next Twitter/Facebook/whatever. You are (probably) writing a boring LOB web application.
Not everyone is working on a startup trying to peddle their stuff to a zillion users and getting hammered in the process. If you ever get to Twitter/Facebook/whatever size no out-of-box solution is going to work. You'll end up doing what Twitter did which is re-architect all their infrastructure/code and tune all their stuff as much has possible.
Ruby's issue IMHO is that it has always been a Rails-centric community/ecosystem and never had the change to grow beyond that. It's still largely used to write web stuff and nothing else. Python, which is a "similar" language, has a much healthier and more diverse ecosystem being used in things like scientific computing or computer vision.
If you want to make Ruby better, grow beyond the web application ecosystem and make it more diverse.
Not everyone is working on a startup trying to peddle their stuff to a zillion users and getting hammered in the process. If you ever get to Twitter/Facebook/whatever size no out-of-box solution is going to work. You'll end up doing what Twitter did which is re-architect all their infrastructure/code and tune all their stuff as much has possible.
Ruby's issue IMHO is that it has always been a Rails-centric community/ecosystem and never had the change to grow beyond that. It's still largely used to write web stuff and nothing else. Python, which is a "similar" language, has a much healthier and more diverse ecosystem being used in things like scientific computing or computer vision.
If you want to make Ruby better, grow beyond the web application ecosystem and make it more diverse.
I agree with the Rails-centrism issue. Even alternative web frameworks have a hard time in the Ruby world.
I disagree with the assumption that Ruby is web only. E.g. Chef and Puppet are huge efforts that have no direct connection to frontend web, both written in Ruby. Vagrant as well. Ruby is big in the infrastructure world.
I disagree with the assumption that Ruby is web only. E.g. Chef and Puppet are huge efforts that have no direct connection to frontend web, both written in Ruby. Vagrant as well. Ruby is big in the infrastructure world.
It is funny to ready Ruby guys complaining of the lack of web frameworks alternatives. Python community likes to complain that they have too much web frameworks. Nobody is ever satisfied :-)
What about game framework, computer vision, scientific computing, robotics, etc? I'm sure you can come up with examples for each of these but most are either dormant/abandoned or simply non-existant. As for infrastructure, yes Chef and Puppet are big in the startup world but I know a lot more companies using Python or Java for that.
Companies use Java instead of Puppet? How does the conversation go where you even start to compare those two things?
"Hey do we have $X million for Opsware?"
"Sure thing."
"Damn it feels good to be a banker."
"Sure thing."
"Damn it feels good to be a banker."
For robotics, see Artoo: http://artoo.io/
Does it help that I know far more companies using Chef and Puppet for that then Python and Java?
Depends, do they have a fraction of the IT staff that Tivoli and Opsware users have? I'm guessing not.
I usually work for DAX companies. Yes.
My point was that your personal sample is most probably irrelevant.
My point was that your personal sample is most probably irrelevant.
I've been doing some robotics stuff using my arduino and ruby via the dino gem (https://github.com/austinbv/dino)
http://www.rubymotion.com/ is an increasingly big deal for iOS (and now Mac) development.
There are people working on it, see for example: http://sciruby.com/
>It's still largely used to write web stuff and nothing else.
Vagrant? Homebrew? Jekyll?
Vagrant? Homebrew? Jekyll?
As I wrote elsewhere in this thread, I don't think that people are leaving Ruby in the droves that the author claims. Ruby isn't dying, and Rails isn't dying, at least not right now.
However, the author does point to problems in Ruby's performance and maturity that are problems and issues -- if not immediately, then down the road. Your point about how people are leaving Ruby in favor of people, tools, and performance in the Java world is a good one. I would like to think that JRuby is a good option for such people, but maybe not.
I found the author's ideas for modernizing Ruby to be interesting. I didn't agree with all of them, but at least he's trying to hash out some possible ways in which Ruby could improve. This sounds like a wish list for Ruby 3.0, though -- interesting ideas that would break compatibility, and that will take a while to implement. Perhaps his work, and that of Rubinius, could show us the way forward to such a new version.
However, the author does point to problems in Ruby's performance and maturity that are problems and issues -- if not immediately, then down the road. Your point about how people are leaving Ruby in favor of people, tools, and performance in the Java world is a good one. I would like to think that JRuby is a good option for such people, but maybe not.
I found the author's ideas for modernizing Ruby to be interesting. I didn't agree with all of them, but at least he's trying to hash out some possible ways in which Ruby could improve. This sounds like a wish list for Ruby 3.0, though -- interesting ideas that would break compatibility, and that will take a while to implement. Perhaps his work, and that of Rubinius, could show us the way forward to such a new version.
JRuby, at least in my experience, has not yet delivered performance in line with my expectations of a JVM-hosted language.
In my opinion, performance is by a huge margin the chief reason I do not begin new projects on Ruby. I would rather defer performance tuning efforts and scale complexity until much later in projects' life, rather than immediately following launch when I have 100 concurrent users hitting the application.
In my opinion, performance is by a huge margin the chief reason I do not begin new projects on Ruby. I would rather defer performance tuning efforts and scale complexity until much later in projects' life, rather than immediately following launch when I have 100 concurrent users hitting the application.
> IMHO, Node.js is the new Ruby. It has the benefit of
> having the same language on the client and the server,
> but once again, it's going to run into similar
> scalability issues when large organizations try to use
> it. I think we're going to run into the same issues,
> of it becoming a cool bandwagon, the platform being
> stretched to its breaking point, followed by the
> realization that there are serious problems.
[0]: http://elixir-lang.org
[1]: http://pragprog.com/magazines/2013-06/programming-elixir
[2]: http://pragprog.com/book/elixir/programming-elixirNo matter the whole hype cycle I do actually reckon Elixir is positioned to be the new leader on the programming-web-front: being underpinned by Erlang means it is the ONLY platform/language out there so far with super solid scalability to rival Java AND a light/novel way of programming. That being said I'm personally doing fine with newer versions of PHP (which for my purposes are solid and fine when backed by best practices and prepared sql statements!)
I think a bigger change is the JVM and .Net don't suck so much now. There are interesting languages like Scala and Groovy on the JVM and frameworks like Play and MVC on .Net that make development less painful.
I think a bigger change is the JVM and .Net don't suck so much now.
Frankly, JVM hasn't really sucked since it got a JIT compiler (J2SE 1.2, 1998) or if you prefer the switch to HotSpot as the default VM (J2SE 1.3, 2000).
Frankly, JVM hasn't really sucked since it got a JIT compiler (J2SE 1.2, 1998) or if you prefer the switch to HotSpot as the default VM (J2SE 1.3, 2000).
Most of these stories also contain a lot of "we used a monolithic approach first and then split it up". A lot of companies I know kept their frontends in Rails, because its frontend tooling is really good. But you'll never write the big backend processing part in Rails.
Also, this is a question of resources. Once your first version succeeds, you suddenly have the funds to build a complex version where you care about all the small details.
Ruby is a _very good_ language as long as you are in the "I don't need to tune all the details phase".
Also, this is a question of resources. Once your first version succeeds, you suddenly have the funds to build a complex version where you care about all the small details.
Ruby is a _very good_ language as long as you are in the "I don't need to tune all the details phase".
Twitter got a huge performance and efficiency boost even rewriting the front end on the JVM (in Scala).
Twitter is a one-in-a-thousand company with traffic amounts that most of us here will dream of ever achieving. Even the more people that don't take specific interest in running large scale deployments.
Even writing you frontend in Java first would (most likely) not have helped you coping with the new-found challenges in that heights.
Even writing you frontend in Java first would (most likely) not have helped you coping with the new-found challenges in that heights.
Perhaps on the efficiency side. On the performance side it would be true even on a small site (unless it was all static, cached content).
http://www.techempower.com/benchmarks/
http://www.techempower.com/benchmarks/
Twitter is a one-in-a-thousand company with traffic amounts that most of us here will dream of ever achieving.
And not every low-traffic site is simple CRUD. If you do image processing, applying machine learning, natural language processing (or a thousand other things that are CPU intensive), it's nice that you can directly use one of the many high-performance libraries available in the Central Repository in your webservice.
And not every low-traffic site is simple CRUD. If you do image processing, applying machine learning, natural language processing (or a thousand other things that are CPU intensive), it's nice that you can directly use one of the many high-performance libraries available in the Central Repository in your webservice.
You probably won't reasonably run most of these applications in your frontend framework either.
Also, the example was the Twitter frontend. So I respond to Twitter frontend. Don't derail.
Also, the example was the Twitter frontend. So I respond to Twitter frontend. Don't derail.
Twitters original architecture was an absolute disaster.
I'm sure they could get a speedup by rewriting the front-end, but the fact that they kept trying and fail to scale stuff that with anything remotely like a sensible architecture is network IO bound rather than CPU bound even with MRI on the hardware available when they launched was a good sign that their main problem had nothing to do with language.
Their "simple" case of updating n followers for every status update when n is small is trivially distributable with a relatively simple message bus routing fabric; their "hard" case of updating when n is excessively large is simple-ish by simply structuring the follower lists as a tree of "virtual" follower lists that acts as forwarders; you can do that with off the shelf components.
To illustrate just how basic this problem is: I've built message buses for scenarios like that using mail servers even - though if you do that, at least with a standard mail server, you will be limited by disk IO on forwarding nodes unless you spend too much money (you don't need message updates to be durable "in transit", as if the system is suitably.
Another simple approach to the large follower problem is to pull from "expensive" publishers and push from cheap ones. You can do that too with 25-30 year old software and some scripts to maintain the lists: Push via SMTP, pull via NNTP and make the "mailbox" you post status updates to for people with large follower lists a SMTP->NNTP gateway.
No, I'm not suggesting they should actually do that, just pointing out that it is viable, and it was viable with the kind of data volumes they are dealing with well over a decade ago. Yet they had problems handling it years later with a much smaller data volume than they have now.
When you get to the size Twitter is now, it makes sense to sacrifice developer effort for saving some percents here and there on servers, but their complaints about language when they started their rewrites was distractions from the real issues, whether they realised it themselves or not - it's not like they were handling data volumes at the time that lots of people haven't managed to handle with much more modest resources.
I'm sure they could get a speedup by rewriting the front-end, but the fact that they kept trying and fail to scale stuff that with anything remotely like a sensible architecture is network IO bound rather than CPU bound even with MRI on the hardware available when they launched was a good sign that their main problem had nothing to do with language.
Their "simple" case of updating n followers for every status update when n is small is trivially distributable with a relatively simple message bus routing fabric; their "hard" case of updating when n is excessively large is simple-ish by simply structuring the follower lists as a tree of "virtual" follower lists that acts as forwarders; you can do that with off the shelf components.
To illustrate just how basic this problem is: I've built message buses for scenarios like that using mail servers even - though if you do that, at least with a standard mail server, you will be limited by disk IO on forwarding nodes unless you spend too much money (you don't need message updates to be durable "in transit", as if the system is suitably.
Another simple approach to the large follower problem is to pull from "expensive" publishers and push from cheap ones. You can do that too with 25-30 year old software and some scripts to maintain the lists: Push via SMTP, pull via NNTP and make the "mailbox" you post status updates to for people with large follower lists a SMTP->NNTP gateway.
No, I'm not suggesting they should actually do that, just pointing out that it is viable, and it was viable with the kind of data volumes they are dealing with well over a decade ago. Yet they had problems handling it years later with a much smaller data volume than they have now.
When you get to the size Twitter is now, it makes sense to sacrifice developer effort for saving some percents here and there on servers, but their complaints about language when they started their rewrites was distractions from the real issues, whether they realised it themselves or not - it's not like they were handling data volumes at the time that lots of people haven't managed to handle with much more modest resources.
This is a pretty horrible example. Twitter is a real time communications platform and even ignoring scale its not the right choice for Twitter. I doubt there's many folks at all in the Rails community who would say that Rails is the right stack for Twitter.
The front end is just a bunch of calls to services and HTML rendering from templates. It really has nothing to do with real time communication.
Except that little thing that shows you new tweets immediately...
That "little thing" which maintains and generates the timeline should be IO bound whether it's written in C or Ruby unless it's written by someone who does not understand the problem space, and ought to be a separate service. We can agree Rails doesn't make much sense for it, but frankly, language does not matter. Understanding how to minimise context switches for a network service and how handle fan-out does. It's not a hard problem - it's been solved dozens of times over by people writing queueing message servers, NNTP servers and SMTP servers, amongst others.
I don't disagree with any of your points. I just disagree with the assumption that twitter frontend is something static with no time-related components.
The frontend should be. It is folly to handle things like the timeline update there, where it is time sensitive, rather than as a backend process that is not - nobody will notice if their timeline is a few seconds out of date. They will notice if it takes more time for the pageload to complete.
That is just polling essentially the same endpoint that renders the page.
I guess JRuby is trying to address the first point and they wouldn't have to retrain their staff. I don't know how popular JRuby is but it runs on the JVM.
"Skill Availability"... riiight.
You know, one of these days this argument might catch on in other industries. For instance you go to the doctor and say "Doctor, I have a sore throat" and the doctor replies "Well, you might need your tonsils removed, but in order to do that we'd need to hire competent surgeons - how about we just punch you in the face until you forget about your throat"
You know, one of these days this argument might catch on in other industries. For instance you go to the doctor and say "Doctor, I have a sore throat" and the doctor replies "Well, you might need your tonsils removed, but in order to do that we'd need to hire competent surgeons - how about we just punch you in the face until you forget about your throat"
How is that relevant? You can solve the same problems in Java as you can in Ruby. An ENT surgeon is not interchangeable with a physical therapist.
You're clearly missing the boat by a mile here. The skill of developing software is transferable to different languages. Choosing a language for its skill availability is saying that you're too lazy to hire developers competent enough to learn a new language in a short space of time. If you're hiring people who can/will only write code in $language then there's something wrong with your hiring policy, or there'd be no reason for multiple languages to exist.
Also you're flat out wrong about solving the same problems in different languages. It may be possible to solve all problems in Java or Ruby, but it is not possible to solve them in the same way - or more specifically the best, most economical or most maintainable way.
To bring skill into the equation means no one should ever have written anything in Erlang because few people could write Erlang - but people do, because competent software engineers can learn Erlang.
Also you're flat out wrong about solving the same problems in different languages. It may be possible to solve all problems in Java or Ruby, but it is not possible to solve them in the same way - or more specifically the best, most economical or most maintainable way.
To bring skill into the equation means no one should ever have written anything in Erlang because few people could write Erlang - but people do, because competent software engineers can learn Erlang.
I believe Node.js has solid technical foundations and it will not run into same troubles as Ruby or PHP. There are millions poured into JS research, Ruby never had decent GC or JIT. Also Node.js code base and unit tests are solid, not like client side JS.
Also there are modern strongly typed languages which compile into JS and run just fine on Node.JS. This solves code-base scalability for large teams..
Also there are modern strongly typed languages which compile into JS and run just fine on Node.JS. This solves code-base scalability for large teams..
I agree that Node.js is technically solid, but the Ruby/Rails code bases and communities have an immeasurably larger and more mature testing culture than JS/Node... and "modern strongly typed languages compiling to JS" does not by any means solve code-base scalability problems for large teams. That claim is simply false. There are boatloads of experienced Java developers. The people who tend to write "strongly typed languages compiling to JS" tend to write those languages, and not JS.
To be clear: the web would not be what it is without JS, and Node is a fascinating and innovative thing. I disagree that there are loads of people who are experienced in C/C++ are champing at the bit to go write Node. The Java/C# talent pool is massively larger than the non-frontend JS talent pool at this time, and the C/C++ talent pool is largely otherwise occupied. That could change... but it hasn't changed yet. The HN/startup scene is not representative of the software industry at large, and a lot of people writing these "languages that can compile to JS" are part of the industry at large.
To be clear: the web would not be what it is without JS, and Node is a fascinating and innovative thing. I disagree that there are loads of people who are experienced in C/C++ are champing at the bit to go write Node. The Java/C# talent pool is massively larger than the non-frontend JS talent pool at this time, and the C/C++ talent pool is largely otherwise occupied. That could change... but it hasn't changed yet. The HN/startup scene is not representative of the software industry at large, and a lot of people writing these "languages that can compile to JS" are part of the industry at large.
All I am saying is that Node.JS has solid foundation to support huge community growth. For me as Java/Scala programmer Node.js is appealing for reasons described above. RoR usually means troubles and I try to avoid it.
V8 is backed up by Google, I guess that's pretty big deal.
>IMHO, Node.js is the new Ruby
That seems a bit apples-to-oranges to me. The degree of hype is similar, yes, but other than that they seem like different animals. Ruby started slow (performance-wise), with memory leaks (that were denied at first), and was predominantly a community development. Node.js is running on top of V8, which is mature, performant, and backed by Google.
That seems a bit apples-to-oranges to me. The degree of hype is similar, yes, but other than that they seem like different animals. Ruby started slow (performance-wise), with memory leaks (that were denied at first), and was predominantly a community development. Node.js is running on top of V8, which is mature, performant, and backed by Google.
Plus it's evented so it's not really I/O bound, which makes it great as a service glue.
Also, node.js with browserify & grunt makes for a great front end packaging & dependency tool.
Also, node.js with browserify & grunt makes for a great front end packaging & dependency tool.
> Also, node.js with browserify & grunt makes for a great front end packaging & dependency tool.
This reminds me of "homebrew is a great packaging/dependency tool, it's basically as good as apt/yum/pacman"
This reminds me of "homebrew is a great packaging/dependency tool, it's basically as good as apt/yum/pacman"
Ruby / MRI has for the most part been evented internally. It's how Ruby got away with green threads until 1.9.x; it's just largely hidden from the developer (until you try to call badly behaved C extensions...).
V8 was first released in 2008 - and while it is awesome, "mature" sounds like a bit of a reach...
Is it reasonable to paraphrase what you're saying as:
When developers are more expensive than servers, rails makes sense.
When servers are more expensive than developers (because of scale), Java/c# start to make sense.
When developers are more expensive than servers, rails makes sense.
When servers are more expensive than developers (because of scale), Java/c# start to make sense.
Or because you straight don't need an army of super capable developers once an organization is large. You need people keeping the lights on and maintaining the momentum
>> PHP is great for rapid prototyping
A few of the worlds most trafficked websites use PHP is production: wikipedia, facebook, wordpress, and hundreds of other bb forums.
A few of the worlds most trafficked websites use PHP is production: wikipedia, facebook, wordpress, and hundreds of other bb forums.
Yes, Node.js is the new Ruby on Rails. It's amazing how EventMachine and other similar frameworks failed to gain traction.
PHP has HHVM, Symfony, and Composer; it does not suffer from any of these problems. Ruby is dying, PHP is the future.
Businesses (meaning Big Business, I suppose) don't reject Ruby because it's "a dying language". They reject it because they're inherently conservative. Java and .Net rule the roost because they're seen as safe, respectable choices.
The appearance of risk is more important to most businesses than actual risk. Ruby isn't dominant, therefore it is perceived as risky. Java's complexity might actually threaten the survival of a small project, but it's not "risky" because it's dominant.
The appearance of risk is more important to most businesses than actual risk. Ruby isn't dominant, therefore it is perceived as risky. Java's complexity might actually threaten the survival of a small project, but it's not "risky" because it's dominant.
The story that Big Business is not using Ruby is just that - a story. On the first RailsConf i've been to (RailsConf Europe 2007), most attendees were actually working for Big Biz.
I have spent most of my ruby career in large companies, even for Padrino work. No one builds a multi-million dollar project in Ruby. But one or the other frontend for that. Some of the services. The deployment tooling, be it Chef or Puppet. Ruby is a surprisingly flexible language and can be successfully used on or off the JVM, which large companies just _like_.
This blog post reeks of negativity and speaks of a willingness to throw the baby out with the bathwater.
I have spent most of my ruby career in large companies, even for Padrino work. No one builds a multi-million dollar project in Ruby. But one or the other frontend for that. Some of the services. The deployment tooling, be it Chef or Puppet. Ruby is a surprisingly flexible language and can be successfully used on or off the JVM, which large companies just _like_.
This blog post reeks of negativity and speaks of a willingness to throw the baby out with the bathwater.
> On the first RailsConf i've been to (RailsConf Europe 2007), most attendees were actually working for Big Biz.
Selection bias.
Go to a COBOL conference and you'll likely find that most attendees work in Big Biz as well. What does that tell you?
Selection bias.
Go to a COBOL conference and you'll likely find that most attendees work in Big Biz as well. What does that tell you?
That COBOL is predominantly used in Big Biz? I think you proved his point.
It'd be selection bias if he made the assumption that most big businesses were using Ruby. That's not the point he was making -- what he said was that lots of people using Ruby work at big businesses.
It'd be selection bias if he made the assumption that most big businesses were using Ruby. That's not the point he was making -- what he said was that lots of people using Ruby work at big businesses.
> That COBOL is predominantly used in Big Biz? I think you proved his point.
No, you don't understand what selection bias means.
No, you don't understand what selection bias means.
You're not very good at explaining it either. Plus, selection bias may not be the only sampling effect here.
Selection bias is when a developer from Big Biz is more likely to go to conferences than a developer from smaller business. Do you have any specific reason to believe that? Not knowing much about conferences, I don't. So until you tell me of those specific reasons, I have no reason to believe in selection bias.
Now, there's another sampling effect: maybe Big Biz simply hire (much) more developers than smaller businesses. If 5% of Big Biz devs work on Ruby, and 10% of startup devs work on Ruby, but 90% percent of developers work for Big Biz, then your Ruby conference will still be 80% full of Big Biz devs without selection bias, even though Big Biz is twice as hostile to Ruby.
Selection bias is when a developer from Big Biz is more likely to go to conferences than a developer from smaller business. Do you have any specific reason to believe that? Not knowing much about conferences, I don't. So until you tell me of those specific reasons, I have no reason to believe in selection bias.
Now, there's another sampling effect: maybe Big Biz simply hire (much) more developers than smaller businesses. If 5% of Big Biz devs work on Ruby, and 10% of startup devs work on Ruby, but 90% percent of developers work for Big Biz, then your Ruby conference will still be 80% full of Big Biz devs without selection bias, even though Big Biz is twice as hostile to Ruby.
> Do you have any specific reason to believe that?
They have more money so they can send more developers to these conferences than startups. Also, they have more employees, so the odds of a number of them being Rails developers is higher.
But that's not even what was being discussed in the context of my "selection bias" remark: the OP was saying that Ruby is used in BigBiz and used Ruby conference attendance to support this claim, which is different from what you are arguing.
They have more money so they can send more developers to these conferences than startups. Also, they have more employees, so the odds of a number of them being Rails developers is higher.
But that's not even what was being discussed in the context of my "selection bias" remark: the OP was saying that Ruby is used in BigBiz and used Ruby conference attendance to support this claim, which is different from what you are arguing.
As much as you didn't understand the point that I was trying to disprove, which was the bare assumption that big business is uninterested in Ruby.
Indeed. Who's more likely to afford several hundreds of dollars for a ticket, plus travel, plus days of hotel, plus lose several days of productivity? A bootstrapped startup, an independent developer, or a corporation with departments that have seven-figure budgets?
That is certainly one factor. But companies are also selective and rarely send someone on conferences for a language that doesn't interest them _at all_.
On top of that, the initial statement was "almost no big business uses Ruby".
On top of that, the initial statement was "almost no big business uses Ruby".
[deleted]
I work in a large corporation. We use Microsoft .NET (recently converted from Java). At home, I develop with Ruby for smaller pet projects and personal things.
I would attend a Ruby/Rails conference, and I work for a "big business". That doesn't mean that my "big business" uses Ruby.
I would attend a Ruby/Rails conference, and I work for a "big business". That doesn't mean that my "big business" uses Ruby.
Are you 100% sure that no department has ever used or commissioned software that runs Ruby? My experience is that most companies have and still do.
Be aware that this includes deployment automation for some software. Two of the behemoths in that space are written in Ruby.
Be aware that this includes deployment automation for some software. Two of the behemoths in that space are written in Ruby.
>The appearance of risk is more important to most businesses than actual risk. Ruby isn't dominant, therefore it is perceived as risky ...
That's not quite right. Anecdotally, I've seen or read about big corps using hot JS front-end frameworks like Angular and Backbone, server frameworks and databases like Node.js, MongoDB and Redis, and programming languages like Python, Erlang and Scala in production. Even if you look at the big tech corps (such as Yahoo, Google, Twitter, Facebook, Amazon), internally there isn't a whole lot of Ruby either. The big poster-child for Ruby, Twitter, is now most known for migrating away from Ruby than for actually using it.
I'm not a Ruby guy, but it doesn't seem like cliche corporate conservatism is what's holding Ruby back. It looks like it's Ruby, and specifically the Ruby platform. Maybe pretty Ruby language semantics aren't enough to make up for Ruby platform downsides. Maybe there just isn't a good reason to use Ruby.
>Java's complexity might actually threaten the survival of a small project
The choice of Java would not threaten the survival of any small project. Though Java is (still) not a very pretty language, the tooling around it has gotten enormously better from where we were in, say, 2003. Current frameworks like JEE, Spring and Play are actually pretty great to work with.
That's not quite right. Anecdotally, I've seen or read about big corps using hot JS front-end frameworks like Angular and Backbone, server frameworks and databases like Node.js, MongoDB and Redis, and programming languages like Python, Erlang and Scala in production. Even if you look at the big tech corps (such as Yahoo, Google, Twitter, Facebook, Amazon), internally there isn't a whole lot of Ruby either. The big poster-child for Ruby, Twitter, is now most known for migrating away from Ruby than for actually using it.
I'm not a Ruby guy, but it doesn't seem like cliche corporate conservatism is what's holding Ruby back. It looks like it's Ruby, and specifically the Ruby platform. Maybe pretty Ruby language semantics aren't enough to make up for Ruby platform downsides. Maybe there just isn't a good reason to use Ruby.
>Java's complexity might actually threaten the survival of a small project
The choice of Java would not threaten the survival of any small project. Though Java is (still) not a very pretty language, the tooling around it has gotten enormously better from where we were in, say, 2003. Current frameworks like JEE, Spring and Play are actually pretty great to work with.
I'd actually say the poster child for Ruby is Github. GitHub is a collection of small Sinatra Web Apps.
Indeed, I wanted to mention this as well.
Furthermore, I think Python (actually Jython) is starting to become for prevalent in the enterprise space. I've seen a few different enterprise software suites from companies like IBM and HP that support writing extensions in Jython. I know that the JVM implementation of Ruby is JRuby, but is anyone using that in production? Jython seems relatively more stable/mature, but I really don't know much about JRuby.
Furthermore, I think Python (actually Jython) is starting to become for prevalent in the enterprise space. I've seen a few different enterprise software suites from companies like IBM and HP that support writing extensions in Jython. I know that the JVM implementation of Ruby is JRuby, but is anyone using that in production? Jython seems relatively more stable/mature, but I really don't know much about JRuby.
The only time I've ever used Jython is for administrating Websphere. And nothing says bloated overpriced overcomplicated time-wasting enterprise nightmare like Websphere.
Seriously, businesses will spend the equivalent of ten programmers' salaries on Websphere licenses, but they'd never consider hiring ten programmers. It's the poster child of corporate timidity in risk aversion drag.
But I digress.
Seriously, businesses will spend the equivalent of ten programmers' salaries on Websphere licenses, but they'd never consider hiring ten programmers. It's the poster child of corporate timidity in risk aversion drag.
But I digress.
jython used to be popular many years ago when it was the most decent language to add scripting to a java app.
I don't _think_ it's very popular as a scripting language for new java stuff, and it still only supports python 2.5 which is 8 years old.
I don't _think_ it's very popular as a scripting language for new java stuff, and it still only supports python 2.5 which is 8 years old.
Constant Contact uses Rails on jruby pretty extensively, because of improved performance and JVM integration. There was also a talk at Boston's Wicked Good Ruby conference of a case study of a large Struts 2 app getting extended in Rails on JRuby. (I asked about Grails as an alternative; not only was Groovy more painful than Ruby to work in, but Grails itself, in the speaker's experience, was more difficult to integrate into an existing application stack. Which is something the Grails folks might want to look into, if it's correct...)
From memory on the torquebox (application server for jruby based on jboss) or the jruby mailing list there was one guy who worked for a large gaming studio (I think it was one of sony's gaming divisions) who use jruby and torquebox for the network backend[1] of their AAA games.
[1] Gamer / game analytics, logins etc. Basically APIs that their games call over the network for the more "social / analytics" stuff.
Personally I have used jruby in the past for implementations of services where we needed to use java libraries.
[1] Gamer / game analytics, logins etc. Basically APIs that their games call over the network for the more "social / analytics" stuff.
Personally I have used jruby in the past for implementations of services where we needed to use java libraries.
I know of a couple of installations that use jruby in production. It's often coupled with some sort of java service in the backend, so sure, it's used in production.
It's also stable, even though it tends to lag a little behind cruby in some features. The 2.0.0 feature set is not yet implemented fully.
It's also stable, even though it tends to lag a little behind cruby in some features. The 2.0.0 feature set is not yet implemented fully.
I'm using JRuby in the code I'm developing for my startup, in order to access Java libs I need. The biggest issue has been that it doesn't support Ruby 2.0 yet, which is merely aesthetic at this point for me. JRuby hasn't given me any grief since I got it going.
It seems that Ruby never won over Python in big tech companies. Probably it has something to do with Python being widespread in science (as far as I understand, tech companies are dominated by graduates from the best colleges) - if you're a graduate, you already know a scripting language, why learn another one?
I was ready to leave Java for enterprise projects, but the name change (J2EE to JavaEE) was accompanied by a dramatic simplification and modularization of the framework. These changes have made me much happier AND more productive as a Java developer, so it's my contention that Java is far more entrenched in the enterprise than it was even 4 years ago.
Alas, it's still kind of a mess. The #1 improvement made to Java imho has been dependency injection in Spring and Hibernate. But this dependency injection pretty much kills all the compile-time sanity checking that compiled languages are supposed to provide. It's great when it works, but when it doesn't, it just barfs out useless stack traces that don't actually show you where the problem occurred.
I'm not sure I believe Spring and JavaEE are as compatible as some would lead you to believe. CDI and JPA are the official implementations of dependency injection and ORM persistence, but they overlap with other functions in Spring and Hibernate. Components in JavaEE are POJOs or MBeans and they're injected based on qualifiers and rules in a configuration file. Guice and Spring both allow you to wire components together, but you can easily get conflict between their injection and the CDI injection.
The compile time sanity checking is still doing type checking, and to a degree you're correct ... there will be run-time exceptions if CDI can't find any instances of an object (likely an interface) to inject or if there is more than one that matches. I don't think you'd want it to randomly pick one.
If you code to the CDI and JPA specifications, you can plug in Hibernate and Weld as your implementations of the frameworks. If you plug in Hibernate and Weld, then use their non-standard extensions you can indeed find irregularities.
The compile time sanity checking is still doing type checking, and to a degree you're correct ... there will be run-time exceptions if CDI can't find any instances of an object (likely an interface) to inject or if there is more than one that matches. I don't think you'd want it to randomly pick one.
If you code to the CDI and JPA specifications, you can plug in Hibernate and Weld as your implementations of the frameworks. If you plug in Hibernate and Weld, then use their non-standard extensions you can indeed find irregularities.
Can you show me an example of something a compiler could check if it wasn't for dependency injection?
I think the question of whether or not to hard code some setting or make it configurable is unrelated to dependency injection. Dependency injection is one way to design dynamic configuration once you have decided not to hard code.
Other options would be to load stuff from a database, a directory server or from a config file. No matter how you do it the compiler won't be able to help.
I think the question of whether or not to hard code some setting or make it configurable is unrelated to dependency injection. Dependency injection is one way to design dynamic configuration once you have decided not to hard code.
Other options would be to load stuff from a database, a directory server or from a config file. No matter how you do it the compiler won't be able to help.
I can't speak to Spring and Hibernate, but using Guice for dependency injection has been quite pleasant. True, it does push some errors to run-time that I would have preferred to see at compile-time, but the error messages make the resulting fix immediately obvious.
(Can anyone speak to this aspect of working with Dagger?)
(Can anyone speak to this aspect of working with Dagger?)
I don't believe this is true at all. Dependency injection is just a way to invert control, decouple your code, and make it more testable. Proper tests of your configuration when your container is bootstrapped is all that is necessary to maintain sanity here.
You are still getting all the benefits of static typing, especially if you are coding to a contract.
You are still getting all the benefits of static typing, especially if you are coding to a contract.
Java and .NET are also backed by ginormous corporations (Oracle and Microsoft), which big business also generally views as a major risk-mitigating factor.
(It isn't really -- in fact it's the opposite, "corporate" platforms tend to die out faster than open-source ones, at least in my experience -- but they think it is, which in this discussion is all that matters.)
(It isn't really -- in fact it's the opposite, "corporate" platforms tend to die out faster than open-source ones, at least in my experience -- but they think it is, which in this discussion is all that matters.)
> Java and .NET are also backed by ginormous corporations (Oracle and Microsoft), which big business also generally views as a major risk-mitigating factor.
This is a big deal. Particularly for risk mitigation and CYA when something goes wrong. No one got fired for buying IBM, as was once said.
This is a big deal. Particularly for risk mitigation and CYA when something goes wrong. No one got fired for buying IBM, as was once said.
Also, let's not forget about IBM, HP, RedHat and all the other shops that back Java
to be just here: RedHat also backs jruby.
Heck, RedHat even has a big JRuby Application Server on top of JBoss.
http://torquebox.org/
http://torquebox.org/
Oracle has some JRuby apps on production
> They reject it because they're inherently conservative
Not just that. They reject Ruby because
1. It's very slow and continues to be very slow despite all the performance work being done on it (nod to JRuby).
2. It's just hard to hire Ruby developers, who are getting more scarce every year.
These are the symptoms of a dying language.
Not just that. They reject Ruby because
1. It's very slow and continues to be very slow despite all the performance work being done on it (nod to JRuby).
2. It's just hard to hire Ruby developers, who are getting more scarce every year.
These are the symptoms of a dying language.
If you provided sources, I would maybe think this was something beyond a personal axe you have to grind.
Seeing as how you've fit the classic "respond to every post" argumentative style.
Seeing as how you've fit the classic "respond to every post" argumentative style.
> It's just hard to hire Ruby developers, who are getting more scarce every year.
Citation?
Why would Ruby developers be getting more scare? Are they retiring earlier than Java developers?
Citation?
Why would Ruby developers be getting more scare? Are they retiring earlier than Java developers?
> Citation?
http://www.indeed.com/jobtrends/ruby%2C+java.html
> Why would Ruby developers be getting more scare? Are they retiring earlier than Java developers?
Ruby developers have always been a tiny fraction of the number of Java developers, and that fraction has been steadily decreasing, while the Java developer pool keeps increasing (Android helped quite a bit growing that population).
http://www.indeed.com/jobtrends/ruby%2C+java.html
> Why would Ruby developers be getting more scare? Are they retiring earlier than Java developers?
Ruby developers have always been a tiny fraction of the number of Java developers, and that fraction has been steadily decreasing, while the Java developer pool keeps increasing (Android helped quite a bit growing that population).
I think it is actually the Ruby Pool is increasing much faster then there are Ruby Devs.
> 1. It's very slow
Benchmarks these days show Ruby 1.9/2.0 as being a wee bit faster than Python, and it's improving. That's still much slower than Java, of course, but then that's a bad comparison; Ruby and Python are better comparisons.
Benchmarks these days show Ruby 1.9/2.0 as being a wee bit faster than Python, and it's improving. That's still much slower than Java, of course, but then that's a bad comparison; Ruby and Python are better comparisons.
It is also still much slower than Groovy and Scala, being at the same time similarly or even less expressive and having worse tooling. Therefore I can't see any reason to move from e.g. Java to Ruby. When Java is not expressive enough I'd consider using Groovy/Scala/Clojure.
It's worth noting that Ruby's metaprogramming model goes a bit beyond the mere appearance of risk, in many people's opinions. Maybe we're wrong, but it's not like we're avoiding it because it's got a small install base (it doesn't) or nobody's heard of it (we all have, for most of a decade now).
No, Ruby died last month, but now it's cool again in a retro sort of way. Node.js is what's dying this week. Next month, Tcl is going to make a comeback.
Oh God, I certainly hope so.
Everything is a string!
Seriously, I don't mind Tcl at all. Does that make me crazy?
Seriously, I don't mind Tcl at all. Does that make me crazy?
Actually, internally, everything is not a string, and has not been that way since... 10+ years. Everything is representable as a string, though.
I actually like Tcl quite a bit even if I don't use it much these days:
http://www.amazon.com/Tcl-Toolkit-2nd-John-Ousterhout/dp/032... (See the cover for all of the authors' names :-)
I actually like Tcl quite a bit even if I don't use it much these days:
http://www.amazon.com/Tcl-Toolkit-2nd-John-Ousterhout/dp/032... (See the cover for all of the authors' names :-)
No tcl is nice. It's expressive and functional. I love not having to use the shift key every two characters for expressions. upvar/uplevel are awesome for creating new language contructs and meta programming.
People ditched it because it wasn't cool, but it got the job done and remains useful and succinct.
People ditched it because it wasn't cool, but it got the job done and remains useful and succinct.
> I love not having to use the shift key every two characters for expressions.
Just customize your keyboard layout, and reverse shift behaviour for the number row. There, better symbol access.
Just customize your keyboard layout, and reverse shift behaviour for the number row. There, better symbol access.
A colleague told me about a Tcl feature called upvar. I contracted epilepsy on the spot. Luckily, this meant i couldn't listen while he told me about uplevel.
yes, TCL sucks.
i sincerely think that what ruby just needs is just a really good wordpress alternative.
I disagree. The strength of ruby is in rapid development. It is not best for performance, installation or deployment. Therefore it's good for teams building software, but it will never be good for install-your-own open source software like WordPress. Since the vast majority of WordPress users never even look at the code there is absolutely nothing to be gained by not using PHP.
>[Ruby] is not best for performance, installation or deployment.
PHP isn't either, except that it's packaged well in Linux.
If there were good packages for Ruby in Debian, the only advantage that PHP would have is in being the shared hosting default. Both are pretty equally performant, and Ruby has the advantage of being a nicely designed language.
>there is absolutely nothing to be gained by not using PHP.
What is there to be gained by using PHP?
PHP isn't either, except that it's packaged well in Linux.
If there were good packages for Ruby in Debian, the only advantage that PHP would have is in being the shared hosting default. Both are pretty equally performant, and Ruby has the advantage of being a nicely designed language.
>there is absolutely nothing to be gained by not using PHP.
What is there to be gained by using PHP?
<?= 'Hello World' ?>Every language has advocates that believe that. The reality is that no one writes WordPress in any one of those languages because PHP, warts and all, is a language for getting things done.
no, the reality is that people write them all the time, then abandon the project.
For example in railsland, typo and mephisto were both popular at some point, and in djangoland there have been at least two dozens blog engines _I know of_.
There was a beautiful django conference video where the speaker asked "who is writing a blog engine in django" and about 9/10 of the room raised their hands.
EDIT: I concur, many language advocates believe that, but I think they are wrong for different reasons.
For example in railsland, typo and mephisto were both popular at some point, and in djangoland there have been at least two dozens blog engines _I know of_.
There was a beautiful django conference video where the speaker asked "who is writing a blog engine in django" and about 9/10 of the room raised their hands.
EDIT: I concur, many language advocates believe that, but I think they are wrong for different reasons.
I'm kind of disappointed in the way the author is approaching the launch of Rubinius X. The "death of Ruby" is being used as a rhetorical device. The strategy appears to be that if we all believe that Ruby is actually dying, we're more likely to get behind Rubinius X. Unfortunately, no support is provided for this claim.
Rubinius has always been the Ruby that placed purity before pragmatism. I applaud them for that, but putting forth the assertion that Ruby is dying as a means to drum up support for a new generation of Ruby seems like getting off on the wrong foot.
Rubinius has always been the Ruby that placed purity before pragmatism. I applaud them for that, but putting forth the assertion that Ruby is dying as a means to drum up support for a new generation of Ruby seems like getting off on the wrong foot.
Ruby does seem to be, if not dying, at least losing a lot of the buzz it had a few years back, but mostly that seems to be because Rails has lost the buzz it had, and much of Ruby's buzz was actually not Ruby buzz, but Rails buzz.
That being said, I think the vision Rubinius X has about where Ruby should go is great -- both in terms of language features and conventions -- and I think that besides the specific details, the high-level strategic vision is something Ruby needs.
That being said, I think the vision Rubinius X has about where Ruby should go is great -- both in terms of language features and conventions -- and I think that besides the specific details, the high-level strategic vision is something Ruby needs.
It is suspicious though that the Rubinius project just lost funding from Engine Yard, and now (like a week later?) the maintainer has declared Ruby dead and Rubinius X is the answer. It seems like death throes (of Rubinius) to me, rather than any substantial commentary on Ruby in general.
A few points:
1. Dying != dead
2. In addition to being maintainer of Rubinius, Brian Shirai is the creator of RubySpec. To me, Rubinius X is more a forward-looking extension of RubySpec then it is something about building support for Rubinius-the-project. As RubySpec sought to create and concretize agreement on what Ruby is (which was important to making Ruby-the-language something more than MRI-the-implementation), Rubinius X is an (opinionated) effort to establish a consensus on where Ruby-the-language is going and how it is going to address the aspects of Ruby that are limiting its adoption.
3. I'm not at all surprised that the fact that Engine Yard, historically one of the biggest corporate players in the Ruby world and who until fairly recently was paying core developers for both JRuby and Rubinius is now not directly sponsoring either would be a source of soul searching and consideration of the future, both of the Rubinius and Ruby. I'd be rather more surprised if it wasn't.
1. Dying != dead
2. In addition to being maintainer of Rubinius, Brian Shirai is the creator of RubySpec. To me, Rubinius X is more a forward-looking extension of RubySpec then it is something about building support for Rubinius-the-project. As RubySpec sought to create and concretize agreement on what Ruby is (which was important to making Ruby-the-language something more than MRI-the-implementation), Rubinius X is an (opinionated) effort to establish a consensus on where Ruby-the-language is going and how it is going to address the aspects of Ruby that are limiting its adoption.
3. I'm not at all surprised that the fact that Engine Yard, historically one of the biggest corporate players in the Ruby world and who until fairly recently was paying core developers for both JRuby and Rubinius is now not directly sponsoring either would be a source of soul searching and consideration of the future, both of the Rubinius and Ruby. I'd be rather more surprised if it wasn't.
Lets face it - Ruby is a great language and wrapped with Rails it allows to craft napkin idea to working, real-world prototype in record short amount of time.
These capabilities prove to be golden for Silicon Valley startups where speed of execution means difference between life and death (VC or nothing).
Once done - startups are praying for a quick exit until the issues of gems mess, scaling, performance and deployment nightmares start raising their ugly heads and requires ample continuous investments in administration and management talents to keep things afloat.
Serious multi-billion enterprises need performance, guarantees of commercial support from big vendor, speed of compiled languages and cannot afford to use interpreted languages and have their feet stuck in all that swamp.
Hence they use Java and dot NET. That's a fact of life.
These capabilities prove to be golden for Silicon Valley startups where speed of execution means difference between life and death (VC or nothing).
Once done - startups are praying for a quick exit until the issues of gems mess, scaling, performance and deployment nightmares start raising their ugly heads and requires ample continuous investments in administration and management talents to keep things afloat.
Serious multi-billion enterprises need performance, guarantees of commercial support from big vendor, speed of compiled languages and cannot afford to use interpreted languages and have their feet stuck in all that swamp.
Hence they use Java and dot NET. That's a fact of life.
Lets face it - Ruby is a great language
I'm not sure that is a premise that can be tossed out as axiomatic before making an argument.
I'm not sure that is a premise that can be tossed out as axiomatic before making an argument.
Given that you will have to figure out scaling issues eventually anyway, the speed of compiled languages should NOT be weighed heavier than programming ease in your decisionmaking. Programmer time is FAR more expensive than hardware these days.
Actually it matters a lot. Since when the programmers manage servers? More servers = more people managing them. And if for a compiled language you need 2 data centers for Ruby you need 20... And level 4 data centers are expensive.
Ruby is great at what it does. I don't see Node.js replacing it anytime soon. But Ruby won't be in enterprise anytime soon also.
Ruby is great at what it does. I don't see Node.js replacing it anytime soon. But Ruby won't be in enterprise anytime soon also.
I've toed this line for a long time, but concern about performance is really starting to be an issue for me when I make a decision about what language/framework to use. Here's my line of thinking:
" If another language can provide 10x more performance in 2x the code of Ruby, that's a tradeoff I'd seriously consider.
If I do ever have a hit on my hands, and it starts scaling quickly, there's a cost, management, and maintenance issue to bottlenecking myself with Ruby. "
I realize that there are many parts to a system and that other parts encounter scaling considerations before the programming language does - ie database.
However, it seems there are known, quick to implement solutions that can solve the data scaling problem in a cost effective manner. Reimplementing my application logic with another language seems to be a very cost-ineffective and time consuming task.
I'd rather head that concern off at the pass by picking that language with 10x the performance and 2x the amount of code.
" If another language can provide 10x more performance in 2x the code of Ruby, that's a tradeoff I'd seriously consider.
If I do ever have a hit on my hands, and it starts scaling quickly, there's a cost, management, and maintenance issue to bottlenecking myself with Ruby. "
I realize that there are many parts to a system and that other parts encounter scaling considerations before the programming language does - ie database.
However, it seems there are known, quick to implement solutions that can solve the data scaling problem in a cost effective manner. Reimplementing my application logic with another language seems to be a very cost-ineffective and time consuming task.
I'd rather head that concern off at the pass by picking that language with 10x the performance and 2x the amount of code.
What if there are languages that offer 10x performance with the same amount of code? And what if there are other languages that have not only faster runtimes, but are also much faster to code in?
Throwing money in hardware to compensate for chosen framework's sluggishness doesn't seems to run well with people who sign the checks.
Neither does buying extra programmers.
[deleted](2)
The type of performance, guarantees of commercial support, and quality of product that only serious multi-billion enterprises like CGI federal can provide!
There are no silver bullets in software development; all projects can fail. The only difference is that with ruby or other dynamic languages, it'll fail faster and cheaper.
There are no silver bullets in software development; all projects can fail. The only difference is that with ruby or other dynamic languages, it'll fail faster and cheaper.
There are 20-30 ruby conferences every year in the US alone. I've been to about 7. They all had > 200 attendees. Even the less-known ones tend to sell out well in advance.
Freelance rates for ruby developers are crazy-high. In Seattle, at least, I'm seeing $200/hr as not uncommon.
And on a side note, PHP has been around for about 80 years now and it's still moving along.
So I don't think ruby/rails are going to "die" any time soon.
Freelance rates for ruby developers are crazy-high. In Seattle, at least, I'm seeing $200/hr as not uncommon.
And on a side note, PHP has been around for about 80 years now and it's still moving along.
So I don't think ruby/rails are going to "die" any time soon.
Yes, exactly. If Ruby is dying, then why are Ruby conferences popping up everywhere? Why are Ruby developers in desperately short supply?
I live in Israel, where Ruby has taken a while to make inroads. But we just had a conference last week, and the many attendees were super excited about the language. And companies were desperate to find employees who know Ruby and/or Rails.
Indeed, the biggest reason that I've found companies give for avoiding the use of Ruby is the scarcity of experienced developers. A client of mine switched from Ruby to PHP last year, simply because he could easily find PHP programmers, and they cost a lot less. You could argue that this points to companies leaving Ruby, but in many ways, I'd say that it rather indicates Ruby is a victim of its own success.
Even if Ruby is dying (which I don't think is the case), plenty of seemingly dead languages are still in demand, and are used on all sorts of projects. You can command great consulting rates in COBOL, today, if you want.
Both Ruby and Rails have strong, active communities that are pushing the language and framework forward in all sorts of interesting ways. The key to a successful open-source project is the community, so I'm pretty confident that I'll be working in Ruby for at least a few more years. But hey, if the author wants to work in something else, power to him; we're fortunate to be living in an era of many high-quality, open-source languages.
I live in Israel, where Ruby has taken a while to make inroads. But we just had a conference last week, and the many attendees were super excited about the language. And companies were desperate to find employees who know Ruby and/or Rails.
Indeed, the biggest reason that I've found companies give for avoiding the use of Ruby is the scarcity of experienced developers. A client of mine switched from Ruby to PHP last year, simply because he could easily find PHP programmers, and they cost a lot less. You could argue that this points to companies leaving Ruby, but in many ways, I'd say that it rather indicates Ruby is a victim of its own success.
Even if Ruby is dying (which I don't think is the case), plenty of seemingly dead languages are still in demand, and are used on all sorts of projects. You can command great consulting rates in COBOL, today, if you want.
Both Ruby and Rails have strong, active communities that are pushing the language and framework forward in all sorts of interesting ways. The key to a successful open-source project is the community, so I'm pretty confident that I'll be working in Ruby for at least a few more years. But hey, if the author wants to work in something else, power to him; we're fortunate to be living in an era of many high-quality, open-source languages.
Thank you for being the first comment (I've seen) that actually looks at some amount of data. It's hard to read "most Rails people are moving on", "Rails and Ruby don't find the new web model" and "node.js is replacing Ruby" over and over without anyone saying how they're coming to their conclusions.
My thoughts are the same as yours... Ruby and/or Rails aren't going anywhere anytime soon. Just think, Rails powers the site that stores most startups code. It may not be as shiny and new as it was, but there's still a lot of usage.
My thoughts are the same as yours... Ruby and/or Rails aren't going anywhere anytime soon. Just think, Rails powers the site that stores most startups code. It may not be as shiny and new as it was, but there's still a lot of usage.
There are also more job listings on Angel List referencing Ruby (640) than jobs referencing Node / Node.js (399) or Python (454).
Indeed.com
Ruby: 6,401 Python: 8,299 .NET: 26,711 Java: 36,069
An interesting switch is: Django Developer: 1,199 Rails Developer: 3,682
I don't think Ruby, Python, etc will die anytime soon. There are too many small businesses that need products developed fast. PHP on the other hand...
PHP Developer: 10,317 What?! ;)
Ruby: 6,401 Python: 8,299 .NET: 26,711 Java: 36,069
An interesting switch is: Django Developer: 1,199 Rails Developer: 3,682
I don't think Ruby, Python, etc will die anytime soon. There are too many small businesses that need products developed fast. PHP on the other hand...
PHP Developer: 10,317 What?! ;)
More like 20 years, but yeah, I guess 20 Internet Years equals around 80 standard years..
Interestingly, Ruby is also approaching its 20-year anniversary. Of course, PHP has been popular much longer than Ruby.
...until people realize the mess that is node.js. I would rather say Rails is dying because it no longer fits the new web programming paradigms.
So very much this.
I never really learnt Rails, to be honest. I dabbled, but never got fully into it. The thing is, the way I'm writing web apps now (nice API's over straight classes, composable libraries, and a routing layer over the top to give it a REST interface) doesn't fit my mental model of how Rails works.
Similarly, I've somewhat abandoned "MVC" for web-apps. Nice API's with the ability to have any front-end, not kicking out HTML from my framework, and the like -- that's what I'm doing now.
Don't get me wrong -- I know that Rails (especially 4) can do all this as well. Heck, there's not much stopping me from doing what I'm doing here with straight Ruby, a couple of libraries and Sinatra (I have a good friend who does exactly that). But for some reason, I've instead written off ruby entirely for that use-case.
I'm merely the n=1 here though, and as a non-ruby programmer, my opinion doesn't mean much I guess. But I find it curious how I ended up skipping it.
I never really learnt Rails, to be honest. I dabbled, but never got fully into it. The thing is, the way I'm writing web apps now (nice API's over straight classes, composable libraries, and a routing layer over the top to give it a REST interface) doesn't fit my mental model of how Rails works.
Similarly, I've somewhat abandoned "MVC" for web-apps. Nice API's with the ability to have any front-end, not kicking out HTML from my framework, and the like -- that's what I'm doing now.
Don't get me wrong -- I know that Rails (especially 4) can do all this as well. Heck, there's not much stopping me from doing what I'm doing here with straight Ruby, a couple of libraries and Sinatra (I have a good friend who does exactly that). But for some reason, I've instead written off ruby entirely for that use-case.
I'm merely the n=1 here though, and as a non-ruby programmer, my opinion doesn't mean much I guess. But I find it curious how I ended up skipping it.
Interesting, as that's very much how my mental model of how Rails works:
1. The routing layer is all about declaring a resource which gives you all 7 major REST operations, and
2. there's a nice facility for responding_to any data format (html, json, js, text, etc) you want.
With rails scaffolding, you can pretty much get all boilerplate code written for you, and have it very simply implement a REST backend for a more "heavyweight" javascript framework (angular, ember, etc).
I wonder if the issue is that rails didn't originally start out this way, and now people assume that Rails is stuck in the past?
I think the article gets it right in that Ruby needs better concurrency primitives (promises are a nice idea), and esp better performance. If Javascript can be as fast as it is with V8, there should be nothing stopping Ruby from achieving similar levels of performance.
1. The routing layer is all about declaring a resource which gives you all 7 major REST operations, and
2. there's a nice facility for responding_to any data format (html, json, js, text, etc) you want.
With rails scaffolding, you can pretty much get all boilerplate code written for you, and have it very simply implement a REST backend for a more "heavyweight" javascript framework (angular, ember, etc).
I wonder if the issue is that rails didn't originally start out this way, and now people assume that Rails is stuck in the past?
I think the article gets it right in that Ruby needs better concurrency primitives (promises are a nice idea), and esp better performance. If Javascript can be as fast as it is with V8, there should be nothing stopping Ruby from achieving similar levels of performance.
I think its not an issue of anyone thinking that rails can't do those things. Its just that there are other things out there that are not as thick, which can also do restful routing. Unless you're already entrenched in Rails, there isn't much benefit to using it over sinatra or express, which allow you to modularize the other components that you need, while also having a lower barrier to entry.
I don't think many Rails developers are abandoning the platform though, so dying probably isn't the right word for it.
I don't think many Rails developers are abandoning the platform though, so dying probably isn't the right word for it.
> I wonder if the issue is that rails didn't originally start out this way, and now people assume that Rails is stuck in the past?
I don't think I got it across in my post correctly, but that's basically what I was trying to say, yeah! I even _know_ that I have that cognitive bias, and yet it remains. I even tried to pick up Rails 4 last week, and put it back down rather quickly again.
I don't think I got it across in my post correctly, but that's basically what I was trying to say, yeah! I even _know_ that I have that cognitive bias, and yet it remains. I even tried to pick up Rails 4 last week, and put it back down rather quickly again.
As someone who programs when the urge hits, rather than as a day job, I ended up playing catch up with Rails. Each time I went to start a project, there's be some new changes/features in Rails for me to learn.
These days, I'm happy coding away in Padrino, which seems to sit between Sinatra and Rails in terms of features and functionality.
For me, Rails just became too big to keep up with. It's more fun and productive with a lighter-weight framework that can get you 90% of the way there. For a newcomer to Ruby, it doesn't seem to be the old "watch me write a blog engine in 5 minutes!" anymore. That might be why the other popular frameworks are getting the attention...
These days, I'm happy coding away in Padrino, which seems to sit between Sinatra and Rails in terms of features and functionality.
For me, Rails just became too big to keep up with. It's more fun and productive with a lighter-weight framework that can get you 90% of the way there. For a newcomer to Ruby, it doesn't seem to be the old "watch me write a blog engine in 5 minutes!" anymore. That might be why the other popular frameworks are getting the attention...
So what do you use for the front-end? How is it communicating with your API?
If you're talking about single-page apps I don't think it's the new web programming paradigm. Most applications fit much better as classic sites which Rails is so good at. In fact I think most SPAs I've seen would be better off with a "traditional" stack. I always find myself thinking "why is this even a SPA?".
Why is node.js a mess?
JavaScript is a messy language, but ignoring that, the module ecosystem is a mess. There are many duplicated modules, many of them done in a half-assed manner by inexperienced developers and rarely updated.
For example, the Node community absolutely loves MongoDB for inexplicable reasons, and support for other datastores is terrible. Despite Postgres supporting hstore for years and Node being popular for years, the two hstore modules are "node-postgres-hstore" (7 stars on github) which hasn't been updated in 1 year and "node-hstore" (17 stars on github) that hasn't been updated in 2 years. Everything I've seen indicates that this is typical for modules in Node.
Meanwhile, Ruby and Rails support Postgres extremely well at this point.
Similarly, node has several migration libraries, all of which are pretty limited. One of the popular ones, "node-migrate" by one of the most prolific node module developers, still has an open issue from 2 years ago about using timestamped migrations, with the developer commenting as if the concept is news to him (https://github.com/visionmedia/node-migrate/issues/2)
For example, the Node community absolutely loves MongoDB for inexplicable reasons, and support for other datastores is terrible. Despite Postgres supporting hstore for years and Node being popular for years, the two hstore modules are "node-postgres-hstore" (7 stars on github) which hasn't been updated in 1 year and "node-hstore" (17 stars on github) that hasn't been updated in 2 years. Everything I've seen indicates that this is typical for modules in Node.
Meanwhile, Ruby and Rails support Postgres extremely well at this point.
Similarly, node has several migration libraries, all of which are pretty limited. One of the popular ones, "node-migrate" by one of the most prolific node module developers, still has an open issue from 2 years ago about using timestamped migrations, with the developer commenting as if the concept is news to him (https://github.com/visionmedia/node-migrate/issues/2)
>There are many duplicated modules, many of them done in a half-assed manner by inexperienced developers and rarely updated.
This statement accurately describes the world of Ruby gems.
This statement accurately describes the world of Ruby gems.
That might be fun to claim, but the reality is that it's 2013, not 2007. The Ruby ecosystem is much more robust at this point.
The greater robustness means that:
1. There are more high quality modules, so if you look hard enough, you are likely to find one for your tasks,
2. There is an even greater number of duplicative, half-assed, and poorly maintained modules than there were in 2007 (some of which existed but weren't half-assed or poorly maintained in 2007), and those are still quite often the first ones you'll run into when looking for something that does what you want.
> For example, the Node community absolutely loves MongoDB for inexplicable reasons, and support for other datastores is terrible
Right, because everybody uses Postgres, right? All of the major database vendors are supported quite well, and just because hash storage in Postgres (which is already a stretch) is not as well maintained doesn't mean "support for other datastores is terrible).
Right, because everybody uses Postgres, right? All of the major database vendors are supported quite well, and just because hash storage in Postgres (which is already a stretch) is not as well maintained doesn't mean "support for other datastores is terrible).
Node.JS is great when you simply need to move bits from disk onto the network with minimal processing in between and your app is otherwise I/O bound. This is what gives Node.JS its superficial appeal. The trouble comes when you need to write anything of complexity and you find yourself in callback hell and your code becomes difficult to reason about at an unreasonable rate. This makes adding new features to any large code base a ghastly nightmare.
JavaScript is also a really shitty, poorly conceived language with cruft galore, and this compounds the hell of event-driven programming.
I dropped Node.JS because it made me hate programming.
JavaScript is also a really shitty, poorly conceived language with cruft galore, and this compounds the hell of event-driven programming.
I dropped Node.JS because it made me hate programming.
I've found that, if done correctly, Javascript, especially with a module system like common.js, scales with complexity extremely well.
It requires a different approach than OOP that most people are used to but results in very loosely coupled code.
i.e. a power screw driver is a "terrible" tool when used like a manual screwdriver.
It requires a different approach than OOP that most people are used to but results in very loosely coupled code.
i.e. a power screw driver is a "terrible" tool when used like a manual screwdriver.
Compared to e.g. Java API documentation, I find node.js documentation to be an amateurish attempt at best.
In defense of Node (God, there's a phrase I never thought I'd find myself writing), it's also much newer than Java is. Given ten or fifteen years for people to work on them, the docs almost certainly would get better.
To be honest, the Java API documentation is pretty stellar. I am/was a Python developer, and I remember hearing the claim that Django has great documentation. I don't know if I'm spoiled by Java or what but if Django passes for "great" then I think Java's docs should pass for legendary.
It isn't. But its fun to say with all your hipster garb on.
Wait, I thought node users were hipsters? Now node haters are hipsters as well?
.. Is anyone not a hipster?
.. Is anyone not a hipster?
Similarly, C and Java are dying since nobody touts their use of them in PR materials. Also Postgres and HTTP. /snark
Technology hipsterism != technology vitality.
Technology hipsterism != technology vitality.
It depends of the language I suppose. Ruby was all about being new, cool and fun. Call that hipsterism if you want. But now that people moved on, it's fair to ask ourselves "Who is going to use Ruby for their next project?". Big company? No. Hipsters? No. You? Maybe : )
But my start up isn't cool if we aren't using the newest and greatest buzzword technologies.
"The few exceptions prove the rule".
I don't think this means what he thinks it means.
I don't think this means what he thinks it means.
Agreed, I think the author has mis-understood what it means. Quite a common one to get wrong though, for anyone wondering it generally means that stating an exception proves/ establishes/ implies that a general rule exists.
E.g. You may not play ball in the park within 20 metres of the road implies that the general rules is that you can play ball elsewhere in the park.
http://en.wikipedia.org/wiki/Exception_that_proves_the_rule
E.g. You may not play ball in the park within 20 metres of the road implies that the general rules is that you can play ball elsewhere in the park.
http://en.wikipedia.org/wiki/Exception_that_proves_the_rule
Just a few of my cats are male. This proves that all my cats are female. Right?
I think he's taking as axiomatic that there only a few people using ruby, thus claiming this demonstrates the general rule people don't use ruby. Thus he is, in fact, using the phrase correctly.
But by taking it as axiomatic that few people use ruby, he is begging the question.
But by taking it as axiomatic that few people use ruby, he is begging the question.
It's just another hand-waved argument in the whole confused post. If the dude's approach to code matches his approach to writing then we have nothing to worry about.
The most charitable interpretation of the claim I could think of was that the author meant the few exceptions illustrate why the other companies are moving away from ruby.
Rails is dying.
Ruby isn't. It just isn't as popular amongst hipster web programmers anymore...
There's some very interesting things going on in the non-Rails and non-web framework Ruby world...
Ruby isn't. It just isn't as popular amongst hipster web programmers anymore...
There's some very interesting things going on in the non-Rails and non-web framework Ruby world...
What is the evidence that Rails is dying? The programming bootcamp movement is primarily Rails-based, One Month Rails just came out of YC, and I know of at least one other S13 YC company who built their web app in Rails. What seems to have changed is that not every startup is being built with Rails anymore, which I'd say is a positive thing that does not mean Rails is dying.
The hype is dying. I also think the web is moving beyond the Rails model...
The hype is definitely dying, as it should. Rails is just months shy of being 10 years old. I find it kind of amazing that using Rails was even newsworthy within the past couple of years, given how long it has been in use.
A startup choosing Rails to power their application today is like a startup choosing Linux to power their servers. It is not something worth reporting. It doesn't necessarily mean the usage is in decline though.
A startup choosing Rails to power their application today is like a startup choosing Linux to power their servers. It is not something worth reporting. It doesn't necessarily mean the usage is in decline though.
That's a good thing, right? Rails is a great tool for the projects that it should be used for. It should be picked on merits, not on hype.
I'm primarily a Java Developer, I tried Rails recently for the first time on a project without a SQL datastore and found that it was difficult to get a foothold as a beginner.
Switched to Scala Play and the more flexible framework allowed what I needed easily even without a lot of knowledge on Play. Rails seems like it would be great if your doing a typical CRUD app but if you need something a little outside that box it gets in the way.
That said it seems like apps aren't always just CRUD anymore and that may be why its falling in popularity.
Switched to Scala Play and the more flexible framework allowed what I needed easily even without a lot of knowledge on Play. Rails seems like it would be great if your doing a typical CRUD app but if you need something a little outside that box it gets in the way.
That said it seems like apps aren't always just CRUD anymore and that may be why its falling in popularity.
Yeah, "real-time" is the big thing now but there no mainstream tools to simplify the development of such apps, so we're pretty much in Perl + CGI era. The ones that exist offer much looser coupling between client and server than required or just plain weird.
Totally agree with your point. Though it might seem that Rails has scaling problems and is regarded as slow and painful once the system matures, there are many many other applications to the language in itself. Plus, there's a lot to be done on the performance side of things. Ruby compilers have come a long way, but there's still plenty of room for improvement.
Just look at Puppet. It is so awesome, and it's implemented in Ruby. Ruby is definitely growing like a weed among the devops community.
Just look at Puppet. It is so awesome, and it's implemented in Ruby. Ruby is definitely growing like a weed among the devops community.
"Ruby is failing to help businesses engage customers. It is seen as inefficient and inferior to other languages."
This is pure bullshit. If your business is advertising a particular programming language in order to "engage customers", you are doing something terribly wrong (unless you're in a niche developer market). Your customer doesn't even care about the programming language your site is written in at all. All they want is business value. If the value of your software outweighs the cost, THAT is how you engage customers.
Ruby and other dynamic languages like Python and PHP will always have a place, no matter how they do or don't scale. The danger for 95% of startups is complete failure - not succeeding and not getting any traction at all, not "OMG how are we going to scale this with the hundreds of millions of pageviews we have?". A focus on rapid prototyping and productivity for a small team is exactly what most startups need, and Ruby/Rails is a great fit for that. It's not going anywhere, and it's certainly not going to die.
This is pure bullshit. If your business is advertising a particular programming language in order to "engage customers", you are doing something terribly wrong (unless you're in a niche developer market). Your customer doesn't even care about the programming language your site is written in at all. All they want is business value. If the value of your software outweighs the cost, THAT is how you engage customers.
Ruby and other dynamic languages like Python and PHP will always have a place, no matter how they do or don't scale. The danger for 95% of startups is complete failure - not succeeding and not getting any traction at all, not "OMG how are we going to scale this with the hundreds of millions of pageviews we have?". A focus on rapid prototyping and productivity for a small team is exactly what most startups need, and Ruby/Rails is a great fit for that. It's not going anywhere, and it's certainly not going to die.
If you love a tool, it won't die. Period.
And lots of people (myself included) still love Ruby.
And I finally released a potentially useful gem for medium to large Ruby/Rails codebases. Are unmitigated monkeypatches complexifying your codebase to the point of pain? I wrote a gem to help manage that...
https://github.com/pmarreck/pachinko
And lots of people (myself included) still love Ruby.
And I finally released a potentially useful gem for medium to large Ruby/Rails codebases. Are unmitigated monkeypatches complexifying your codebase to the point of pain? I wrote a gem to help manage that...
https://github.com/pmarreck/pachinko
A baseless, attention-grabbing headline, a vague language spec that doesn't really seem to be adding any new ideas (and indeed rejecting some good ones), and no actual working code. Get back to me when you actually write something; until then all this is is a glorified blog post with a "wouldn't it be nice if there were ____ language out there?"
I have so many thoughts about this post right now, that I find it hard to put them into a coherent comment. Still, I want them out there:
1) I, too, feel that Ruby is no longer as fashionable as it used to be. I do not think this to be much of a problem and more like the natural way fashions work. But I still think the effect can be observed. It was not long ago that I learned about a cool new project written in Ruby here on HN on a weekly basis. These days, it has become a rare occurence.
2) It is a fact that the "cool kids" have moved on. But there is not the one big new thing. Rather, people who were popular in the Ruby world 5 years ago use Scala, Clojure, Node.js, Go and a few other things these days.
3) Still, Rails seems to be very popular with startups. Maybe not with the ones that are highly technical. But many of those just trying to get a mvp out there seem to default to rails these days.
4) I love Ruby. I used to love learning new programming languages. But ever since writing Ruby code on a daily basis, other languages most often fail to attract me. And I no longer look at technical benefits. Instead I take a look at the syntax and most often I am annoyed. Ruby has this effect on _some_ people, but not on others. For those who do not care about Ruby's aesthetics, there is probably little to keep them from trying out other languages.
5) There is little in the list of features on x.rubini.us that I disagree with. But at the same time, there is nothing I ever missed. Also, I am not convinced that all of those issues can or should be solved on the interpreter level.
6) Instead of a list of features, I would love to see a list of the kinds of applications that would benefit from those. I am not convinced that Node.js-style network services should be the future of Ruby.
1) I, too, feel that Ruby is no longer as fashionable as it used to be. I do not think this to be much of a problem and more like the natural way fashions work. But I still think the effect can be observed. It was not long ago that I learned about a cool new project written in Ruby here on HN on a weekly basis. These days, it has become a rare occurence.
2) It is a fact that the "cool kids" have moved on. But there is not the one big new thing. Rather, people who were popular in the Ruby world 5 years ago use Scala, Clojure, Node.js, Go and a few other things these days.
3) Still, Rails seems to be very popular with startups. Maybe not with the ones that are highly technical. But many of those just trying to get a mvp out there seem to default to rails these days.
4) I love Ruby. I used to love learning new programming languages. But ever since writing Ruby code on a daily basis, other languages most often fail to attract me. And I no longer look at technical benefits. Instead I take a look at the syntax and most often I am annoyed. Ruby has this effect on _some_ people, but not on others. For those who do not care about Ruby's aesthetics, there is probably little to keep them from trying out other languages.
5) There is little in the list of features on x.rubini.us that I disagree with. But at the same time, there is nothing I ever missed. Also, I am not convinced that all of those issues can or should be solved on the interpreter level.
6) Instead of a list of features, I would love to see a list of the kinds of applications that would benefit from those. I am not convinced that Node.js-style network services should be the future of Ruby.
[rant] If you're going to claim that your strong opinions are facts, please treat them as such and give citations or back them up yourself. [/rant]
Ruby is not my favorite language anymore, but I still use it and see evidence that there is a huge place it fills in the dev community and ecosystem. I have never used a more expressive language. I'm stating this as a fact from what I have experienced, and I'm giving points that back it up. There are dozens of actively maintained Ruby projects, some of which are the most popular repos on GitHub. I don't see any evidence that the Ruby ecosystem is on a downward trend of activity and is "dying", so I have no reason to think otherwise.
This kind of stuff reminds me why I take breaks from HackerNews every once in a while -_- Yuck.
Ruby is not my favorite language anymore, but I still use it and see evidence that there is a huge place it fills in the dev community and ecosystem. I have never used a more expressive language. I'm stating this as a fact from what I have experienced, and I'm giving points that back it up. There are dozens of actively maintained Ruby projects, some of which are the most popular repos on GitHub. I don't see any evidence that the Ruby ecosystem is on a downward trend of activity and is "dying", so I have no reason to think otherwise.
This kind of stuff reminds me why I take breaks from HackerNews every once in a while -_- Yuck.
The post doesn't point to any data proving the point. I'm curios from where he had concluded that ruby is dying...
Um, wut?
This post is so confusing. I see some half thought out ideas, but no solutions.
Ruby may not be Java or JavaScript, but why would you want it to be? You have Java and JavaScript for times when you want to use Java or JavaScript.
Use the right tool for the job.
This post is so confusing. I see some half thought out ideas, but no solutions.
Ruby may not be Java or JavaScript, but why would you want it to be? You have Java and JavaScript for times when you want to use Java or JavaScript.
Use the right tool for the job.
The post contains lots of contradictory facts.
First, some people (not all) are using other tools than Ruby. They are looking for a solution to their problems. IMHO Ruby is not even present in the discussion when people make their choices. But Rails is. So I'm not sure that modernizing Ruby is sufficient. Building a modern framework around it could be though. I mean, people go to NodeJS because of Node, not because of Javascript...
First, some people (not all) are using other tools than Ruby. They are looking for a solution to their problems. IMHO Ruby is not even present in the discussion when people make their choices. But Rails is. So I'm not sure that modernizing Ruby is sufficient. Building a modern framework around it could be though. I mean, people go to NodeJS because of Node, not because of Javascript...
>>But Rails is
I was about to mention this. I know of at least two (very) hot S13 YC companies that either built their web app in Rails or explicitly deal with Rails (not sure if One Month Rails is built in Rails or not, but it is pretty explicitly pro-Rails). Does Rails prevalence preclude Ruby from being a dying language? Depends on what you mean by dying. The dominance of Rails is probably something of a blessing and a curse for the broader Ruby world. I'm too new to it to have a strong position, but I will say that as a novice developer, I went with Ruby and Rails because there is a fantastic suite of tools for learning from scratch.
I was about to mention this. I know of at least two (very) hot S13 YC companies that either built their web app in Rails or explicitly deal with Rails (not sure if One Month Rails is built in Rails or not, but it is pretty explicitly pro-Rails). Does Rails prevalence preclude Ruby from being a dying language? Depends on what you mean by dying. The dominance of Rails is probably something of a blessing and a curse for the broader Ruby world. I'm too new to it to have a strong position, but I will say that as a novice developer, I went with Ruby and Rails because there is a fantastic suite of tools for learning from scratch.
Rails is a curse. Because of it, Ruby (which is a fantastic language) has been reduced to a web language, when it's really much more than that.
Ruby was a little-known project before Rails came along. Without Rails, we wouldn't be having this discussion at all.
I never would have been exposed to Ruby if not for Rails (I'm a novice, self taught developer). While everyone talks about how amazing Scala and Haskell are (of which I have no doubt), I learned Ruby because Rails allowed me to build little projects (usually web apps) very easily. Now I have branched out into a bit of node.JS, some Python, and some Clojure (I like the idea of learning a Lisp), but Rails was a friendly entry point.
[deleted]
Well there's a broad range of applications that simply can't be built with Rails. And that's shame. It's a corollary to the other commenter saying that Rails no longer fits the new web programming paradigms.
Many Rails folks have moved on to other things, many of them to Node.js, and in general development is becoming less homogenous (i.e. Go services interacting with a Rails app/middleware, and an Angular.js front-end). This is a good thing; we are seeing people more willing to use the right tool for the job rather than trying to use one language for everything.
This. I think of any of the comments so far you express what I'm seeing as well (I know 'use case of 1'). Distributed & modularized apps where each component uses the language/framework best suited for the job.
The most common complaint I hear when I talk about Ruby is it's poor performance. The languages I hear mentioned most often (by the complainers) as alternatives include Go and Node.js.
I've used Ruby for a few years as a part-time coder. In that time I've never ventured out to try the variety of Ruby interpreters available. For instance, I've heard of JRuby, and I have also heard it's really fast, but it just seems like it's intended for "enterprise" use-cases, rather than my day to day scenarios.
If there are all these faster Ruby interpreter variants out there, one 'evangelism' approach could simply be to make them more visible and approachable to end-users.
There's also opportunities for package maintainers to work to make these alternatives available in the various Linux/Unix distributions. I want to be able to apt-get them, rather than hunt down a PPA or build via RVM.
Is there anything else beyond speed that is holding Ruby back from greater mindshare?
I've used Ruby for a few years as a part-time coder. In that time I've never ventured out to try the variety of Ruby interpreters available. For instance, I've heard of JRuby, and I have also heard it's really fast, but it just seems like it's intended for "enterprise" use-cases, rather than my day to day scenarios.
If there are all these faster Ruby interpreter variants out there, one 'evangelism' approach could simply be to make them more visible and approachable to end-users.
There's also opportunities for package maintainers to work to make these alternatives available in the various Linux/Unix distributions. I want to be able to apt-get them, rather than hunt down a PPA or build via RVM.
Is there anything else beyond speed that is holding Ruby back from greater mindshare?
You mentioned performance and packaging. There's also concurrency issues but those are improving.
The most interesting critique of Ruby I've heard recently was from Tom Stuart @ Ruby Manor this year:
http://lanyrd.com/2013/ruby-manor/scffpd/
In this talk he demonstrated how the multi-paradigm nature of Ruby makes it hard to fully realize the benefits of a single paradigm like FP or OOP.
This is obviously not something that CTOs are bringing up in tech provisioning discussions, but I think it does prevent ruby from having the kind of strengths that would make it a go-to language for certain types of projects the way that Go, Scala, Node.js or Haskell are able to do these days. I think Ruby's biggest appeal is to programmers who care a great deal about aesthetics and expressiveness of code.
The most interesting critique of Ruby I've heard recently was from Tom Stuart @ Ruby Manor this year:
http://lanyrd.com/2013/ruby-manor/scffpd/
In this talk he demonstrated how the multi-paradigm nature of Ruby makes it hard to fully realize the benefits of a single paradigm like FP or OOP.
This is obviously not something that CTOs are bringing up in tech provisioning discussions, but I think it does prevent ruby from having the kind of strengths that would make it a go-to language for certain types of projects the way that Go, Scala, Node.js or Haskell are able to do these days. I think Ruby's biggest appeal is to programmers who care a great deal about aesthetics and expressiveness of code.
First, let me start by saying I'm a day-to-day Ruby developer and I absolutely love the language. That said, there are things besides the speed that prevent the acceptance of Ruby among people:
* No static type checking, potentially resulting in more bugs * Ease of monkey-patching, potentially resulting in insecurities * Rampant use of hash-as-arguments, resulting in method definitions that don't actually define their arguments (though Ruby 2.0 fixes this with named parameters, it's still a common pattern) * Heavy use of symbols, which some people see as the moral equivalent of magic strings
I personally think all of these arguments are bunk except for the over-use of hash-as-arguments even in Ruby 2.0. But some people give them credence.
* No static type checking, potentially resulting in more bugs * Ease of monkey-patching, potentially resulting in insecurities * Rampant use of hash-as-arguments, resulting in method definitions that don't actually define their arguments (though Ruby 2.0 fixes this with named parameters, it's still a common pattern) * Heavy use of symbols, which some people see as the moral equivalent of magic strings
I personally think all of these arguments are bunk except for the over-use of hash-as-arguments even in Ruby 2.0. But some people give them credence.
IIS integration period the end.
well that was argument awhile back. nowadays with products like Helicon Zoo (which i use for development), it make integrating a rails (or php, python, cfml) site with IIS a breeze. seriously, if you're using IIS and want to run a rails site, you should have looked at Helicon Zoo.
well that was argument awhile back. nowadays with products like Helicon Zoo (which i use for development), it make integrating a rails (or php, python, cfml) site with IIS a breeze. seriously, if you're using IIS and want to run a rails site, you should have looked at Helicon Zoo.
[deleted]
This post really needed to follow up on the whole "Ruby is dying" part with some sort of "and here's how Rubinius X can help" part.
The way it's written has caused everyone here to debate whether or not Ruby is dying and completely ignore the announcement. I'm sure the title of the HN link isn't helping either.
The way it's written has caused everyone here to debate whether or not Ruby is dying and completely ignore the announcement. I'm sure the title of the HN link isn't helping either.
That would be in the first link.
It has definitely lost the cool edge that it had. In the midwestern US, it takes longer for trends to penetrate and I saw the Ruby height in popularity here after it had been eating Hacker News alive for a while. Now out here, it is definitely Node.js. All the new young developers talk about it. The old PHP devs in town talk about it, but can't switch to it because all of their libraries and business is in PHP, etc.
Interestingly enough, event-loop non-blocking, etc is NEVER the reason mentioned by the devs interested in it and using it. They only mention how nice it is to have basically the same language in the frontend and backend. They claim not having your brain switch like that is a huge benefit (which I could believe, but I haven't tried. (Python+Django+Flask dev myself))
Interestingly enough, event-loop non-blocking, etc is NEVER the reason mentioned by the devs interested in it and using it. They only mention how nice it is to have basically the same language in the frontend and backend. They claim not having your brain switch like that is a huge benefit (which I could believe, but I haven't tried. (Python+Django+Flask dev myself))
To be relevant today, a programming language must provide simple yet powerful facilities for composition and collaboration. A language does not need general immutable state, purely pure functions, or complex type systems, no matter how inferred.
> Is this a poke at Haskell?
Its saying that a language doesn't have to be Haskell to be relevant. If that's what you consider a "poke", then sure.
Its saying that a language doesn't have to be Haskell to be relevant. If that's what you consider a "poke", then sure.
http://x.rubini.us/
I like everything I read there except undefined. I have been using Lua for a while now and having only two falsy values is great. I am not convinced adding a third is a good trade-off.
I like everything I read there except undefined. I have been using Lua for a while now and having only two falsy values is great. I am not convinced adding a third is a good trade-off.
Ruby just seems to be actually getting used by large projects. I personally think that makes sense because you want to see that a language can stand some sort of test of time before entirely adopting it. I think what Jeff Atwood had to say about it [1] when choosing to use it for Discourse [2] shows a different opinion that this article. One that I agree with more.
[1]: http://www.codinghorror.com/blog/2013/03/why-ruby.html [2]: http://www.discourse.org/
[1]: http://www.codinghorror.com/blog/2013/03/why-ruby.html [2]: http://www.discourse.org/
Atwood's argument boils down to "I wanted to work with this one guy, and what he uses is Ruby." Which is fine as far as it goes, but it doesn't really say much about the popularity of the language among programmers in general.
This is such a flame bait :)
Does Rubinius really needs this?
I installed it last week and trying it out with Rails 4 to see how it feels. Ruby is alive and well. And mainstream.
I installed it last week and trying it out with Rails 4 to see how it feels. Ruby is alive and well. And mainstream.
I hate this phrase. It doesn't mean what people think it means and wouldn't make any sense if it did: http://en.wikipedia.org/wiki/Exception_that_proves_the_rule
While I find the project interesting, I see nothing about performance. I'd like to see a focus on performance using optional type annotations.
http://www.mirah.org
http://www.mirah.org
what a load of rubbish.
I have seen absolutely no evidence that Ruby is dying or even ill.
This article provides absolutely no evidence but just makes a completely unsubstantiated claim.
Saying startups aren't bragging that they are using Ruby as proof that it is dead is pretty dumb. Sure Ruby isn't the hot new thing anymore, it's not as "cool" as it used to be and the people who always want to be trying the latest languages aren't experimenting with it and writing blogs about it. But it's very much alive and kicking, just much more mature and less sexy. Which is inevitable.
I have seen absolutely no evidence that Ruby is dying or even ill.
This article provides absolutely no evidence but just makes a completely unsubstantiated claim.
Saying startups aren't bragging that they are using Ruby as proof that it is dead is pretty dumb. Sure Ruby isn't the hot new thing anymore, it's not as "cool" as it used to be and the people who always want to be trying the latest languages aren't experimenting with it and writing blogs about it. But it's very much alive and kicking, just much more mature and less sexy. Which is inevitable.
I'm not entirely sure what this is, is it a rewrite/syntax clean up of the existing ruby language that runs on the Rubinus VM?
This post is hilarious but all jokes aside I am still interested to see what "Rubinius X" turns out to be.
so a week ago it was CFML and this week its Ruby. is there going to be any week that the languages i program in doesn't get bashed on the net ;)
The hyperbole is undermining the point.
[deleted]
Ruby is not dead, it just smells that way.
Seriously though, it's demise is a little overstated - the BBC for one use it quite a bit, as do quite a few startups.
The author of the post seems a bit butthurt that Ruby has not surplanted all other technologies - and it never will.
One big problem is that for most businesses their first and perhaps last taste of Ruby comes from Rails, and it's security fails. That is a shame.
Having been burnt by the failed promises of Rails ourselves, our company moved onto Python, and never looked back.
Also, Ruby is just one tool in the kit, fine for some jobs, patently unsuitable for many others. The evangelists should realise this, and not do a disservice to Ruby by trying to shove it into every place and frankly pissing off potential future adopters of that technology.
One big problem is that for most businesses their first and perhaps last taste of Ruby comes from Rails, and it's security fails. That is a shame.
Having been burnt by the failed promises of Rails ourselves, our company moved onto Python, and never looked back.
Also, Ruby is just one tool in the kit, fine for some jobs, patently unsuitable for many others. The evangelists should realise this, and not do a disservice to Ruby by trying to shove it into every place and frankly pissing off potential future adopters of that technology.
1) Performance. The JVM simply scales better, it is more cost effective in the datacenter. Without mentioning names, I know of significant Silicon Valley darlings that spent huge sums trying to scale Ruby, got crushed, and eventually ripped-and-replaced the backends with Java.
2) Skill Availability. There are 7+ million Java programmers, it is easier to hire Java programmers.
3) Tool Availability and Maturity.
I think Ruby is a fine language, but I see it like PHP, great for rapid prototyping and productivity in the small, but it's version 1 for the lean startup or for the corporate departmental app. Version 2 is Java, C#, etc using the UX and product feature lessons learned from the Ruby prototype.
IMHO, Node.js is the new Ruby. It has the benefit of having the same language on the client and the server, but once again, it's going to run into similar scalability issues when large organizations try to use it. I think we're going to run into the same issues, of it becoming a cool bandwagon, the platform being stretched to its breaking point, followed by the realization that there are serious problems.