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.
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.
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?
On top of that, the initial statement was "almost no big business uses Ruby".
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.
No, you don't understand what selection bias means.
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.
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.
I would attend a Ruby/Rails conference, and I work for a "big business". That doesn't mean that my "big business" uses Ruby.
Be aware that this includes deployment automation for some software. Two of the behemoths in that space are written in Ruby.
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.
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.
[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.
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.
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 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.
(Can anyone speak to this aspect of working with Dagger?)
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.
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.
You are still getting all the benefits of static typing, especially if you are coding to a contract.
(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.)
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.
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.
Citation?
Why would Ruby developers be getting more scare? Are they retiring earlier than Java developers?
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).
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.
Seeing as how you've fit the classic "respond to every post" argumentative style.