12 ms·

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

by beat 13y ago

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.

smacktoward 13y ago
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.)
- klaustopher 13y ago
  Also, let's not forget about IBM, HP, RedHat and all the other shops that back Java
  - Xylakant 13y ago
    to be just here: RedHat also backs jruby.
    - Argorak 13y ago
      Heck, RedHat even has a big JRuby Application Server on top of JBoss. http://torquebox.org/ http://torquebox.org/
- xs_kid 13y ago
  Oracle has some JRuby apps on production
- pnathan 13y ago
  > 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.
Argorak 13y ago
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.
- laureny 13y ago
  > 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?
  - deleted 13y ago
    [deleted]
  - bdcravens 13y ago
    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?
  - Argorak 13y ago
    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".
  - ctide 13y ago
    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.
jbooth 13y ago
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).
smoyer 13y ago
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.
- beat 13y 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.
  - Cyranix 13y ago
    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?)
  - fauigerzigerk 13y ago
    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.
  - smoyer 13y ago
    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.
macspoofing 13y ago
>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.
- jliechti1 13y ago
  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.
  - rurounijones 13y ago
    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.
laureny 13y ago
> 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.
- subsection1h 13y ago
  > 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?
  - laureny 13y ago
    > Citation? http://www.indeed.com/jobtrends/ruby%2C+java.html 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).
    - ksec 13y ago
      I think it is actually the Ruby Pool is increasing much faster then there are Ruby Devs.
- lobster_johnson 13y ago
  > 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.
  - pkolaczk 13y ago
    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.

by beat 13y ago

smacktoward 13y ago

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.)

klaustopher 13y ago
Also, let's not forget about IBM, HP, RedHat and all the other shops that back Java
- Xylakant 13y ago
  to be just here: RedHat also backs jruby.
  - Argorak 13y ago
    Heck, RedHat even has a big JRuby Application Server on top of JBoss. http://torquebox.org/ http://torquebox.org/
xs_kid 13y ago
Oracle has some JRuby apps on production
pnathan 13y ago
> 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.

Argorak 13y ago

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.

laureny 13y ago
> 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?
- deleted 13y ago
  [deleted]
- bdcravens 13y ago
  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?
- Argorak 13y ago
  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".
- ctide 13y ago
  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.

jbooth 13y ago

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).

smoyer 13y ago

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.

beat 13y 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.
- Cyranix 13y ago
  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?)
- fauigerzigerk 13y ago
  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.
- smoyer 13y ago
  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.

macspoofing 13y ago

>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.

jliechti1 13y ago
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.
- rurounijones 13y ago
  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.

laureny 13y ago

> 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.

subsection1h 13y ago
> 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?
- laureny 13y ago
  > Citation? http://www.indeed.com/jobtrends/ruby%2C+java.html 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).
  - ksec 13y ago
    I think it is actually the Ruby Pool is increasing much faster then there are Ruby Devs.
lobster_johnson 13y ago
> 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.
- pkolaczk 13y ago
  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.