You are so wrong. Where performance is tight, Python can do much better.
Python has Pyrex when dynamic typing is a problem, and Psyco, a *very* fast JIT.
Plus, Python has a bigger number of useful and fast C libraries like NumPy. And the C++ Boot::Python.

Basically, Python is a mature language, with a sheer number of goodies Ruby obviously lacks.

Nice ignorant flaimbait Mj. Other commenters, please don't follow that path.

At my company, Python and Perl are already established as company standards. Adding a third dynamic language is difficult when there is little differentiation at the surface level. In fact, because they are trying to cutback number of tools that are in use (which numbers in the thousands), they even tried to get rid of Perl, but the deafening blow-back stopped that effort.

Corporate adoption takes time, and I think that Python has had more time in the sun to develop credibility in that space. But Rails is also the one thing Ruby does better than any other language--its killer app, as they say--so it's natural for uptake to occur there first. I think more general adoption of Ruby will probably follow.

In the defense of Python, I think it is used for internal applications more because of its ability to create nice little GUI apps. Ubuntu uses Python a bunch for many of its small apps. I use Ruby/Rails all day long at work and have never built a GUI based program with it. When I have attempted to play with the GUI libraries for Ruby it is nothing but a headache.

LOL. I hope this doesn't turn into a C vs VB or .Net vs J2EE war :) From my perspective, which is admittedly limited, I get the vibe that Ruby is not there yet for the enterprise. The anti-enterprise guerrilla in the RoR community doesn't help the cause either.

Lack of powerful IDE's could be one factor. But that is being addressed now, given how many "beta" IDE's were on display at RailsConf.

@Mj : Performance is only one measure of a language's success, and a weak one at that. I didn't say that Ruby is a panacea, I simply suggested that it's good for the same purposes, for the most part.

@Daniel : Thanks for calling out the obvious bait. :)

@Curt : You know, it's really Perl 5 that I see Ruby being an obvious replacement for in a lot of places. Ruby 1.8 has a lot of the niceties that we can expect to see in Perl 6, but it's stable. As a former perl hacker, I'm just sort of surprised to not see it catch on more in this regard.

@Brian : Definitely good points. I'm wondering though, even not at the corporate level, why aren't there more postings for say, small-to-medium size businesses that have high sys-admin and internal application needs? (Maybe Data Centers and the like?)

@John : You're definitely right there. We've actually used Python for a couple projects at my work where the client absolutely wanted a little. Most of the time, for small internal apps, Camping has been ideal for us though. I suppose Ruby is still lacking an easy way to generate acceptable GUI apps, even though several of the toolkits seem oh-so-close... :-/

@Lori : I still don't get the IDE issue. You're probably right because it comes up so often, but unfortunately, they seem to get in the way of Ruby productivity rather than improve it in most cases I've seen.

@Sergio : Yeah, I think that there is definitely some friction from within about 'corporate' ruby adoption, as well as from the outside. I think one of the big issues though is we're not targeting at all the space that lies between two l33t h4x0rs in a garage and a 5000 programmer human wave.

Why don't I for instance, see jobs for a medical center looking for Ruby skills to do data mining or something? I'm just feeling like we're running into an issue where you can make money from Ruby, but only in a severely limited domain, which I think might be dangerous for future growth.

I think you're correct about the list of reasons, except for the last one maybe. Also, because Perl and Python are already there, there's less incentive to embrace yet another language. Things like the Windows version - which looks like a quick-and-dirty port from Linux - may also make a bad impression.

My personal experience after moving from Python is that online documentation is seriously lacking. You have to buy the book or fish for clues in many different places.

I think you just need to change your perception of what Rails is. Try this:

Rails isn't a web development environment.

It's the most popular GUI layer for Ruby applications. Web stacks are the de facto GUI for the vast majority of applications these days.

Quoting AdSR

I think you're correct about the list of reasons, except for the last one maybe. Also, because Perl and Python are already there, there's less incentive to embrace yet another language.

That's definitely a factor, I'm sure. There was an interesting discussion on RubyTalk recently about how Ruby wasn't added to the Linux Standard Base, but that Perl and Python have been. I think the general consensus was that Ruby just doesn't have the kind of utilities you often see written in perl, at least not many that are wildly popular enough for it to make sense to include it in such a broad thing like the LSB.

Perhaps this is true, and something we should take seriously.

Things like the Windows version - which looks like a quick-and-dirty port from Linux - may also make a bad impression.

I'm not sure what you mean. There are some messy things about it, but all in all, I think the Ruby One Click Installer seems to be quite good for general needs, and includes a lot of the libraries people would otherwise need to install by hand.

Do you mean the source based install? If so, yeah, I think you need something like msys to get it up and running, but I'm fuzzy on the details. (Rarely build on Windows, mostly *nix)

My personal experience after moving from Python is that online documentation is seriously lacking. You have to buy the book or fish for clues in many different places.

I still hear a lot of this at user group meetings and the like. I guess that I've never really had a problem with crawling the blogosphere through my trusted contacts, and searching mailing lists through a similar approach. I suppose that this technique would be some deal more difficult for new folks entering the community, since we're dealing with a much larger community at this point.

I wonder if this will catch up over time, Perl, PHP and Python and many others have been around plenty long enough for documentation to catch up. It'd be nice to find clever ways to accelerate this, though.

@James Moore:

between Rails and Camping, it's somewhat true that you can do most of your GUI needs.

I totally don't buy the notion that you should have to, though. I think a lot of companies don't either. Single user, offline apps, do not need Rails. Sometimes they're built that way because it's the best way to stay in Ruby with the existing tools, but that's a workaround, not a solution.

@Gregory : I get the impression that sysadmins generally don't think of themselves as programmers and are less likely to pick up a newer scripting language unless it really addresses their pain points. Perl has been serviceable in this role for years and although Ruby and Python will always produce more maintainable code even for day-to-day scripts there may just not be enough there to push it into the sysadmin space, especially if Python already has a larger mindshare there.

@Gregory:

I meant the One Click Installer. I didn't enjoy the "installation result". It modified the system path to begin with. Also, the GUI apps that come with it have issues (can't hide prompt window, etc.); I know this isn't directly Ruby's fault.

Mind you, this is my personal impression, and I am comparing to Python installation, having used it for many years.

@Brian

You may be right. I wonder what the big pain points are, and what projects would be helpful for generating new interest in that regard.

Essentially Ruport has been what made it possible for me to work for the last couple years in Ruby without doing any Rails (besides some writing.) We're hoping that we'll be able to expand that, but it's not something that I'd describe as anywhere near a 'wild success' commercially, at least not yet.

We've sort of got a chicken and egg problem here. Things like reporting software are important commercially, and benefit from being free software, but aren't fun to write. I suspect a lot of the markets we're missing, like the sysadmin space have similar problems.

I'm hoping this discussion spins off project ideas and identifies problem areas and to some extent, it has already.

@AsDR

I think the installer has been improving over time. For example, I think you can set an option of whether it changes the path, and other little things like that. Do you have other specific reasons about why the Python installer behaves better?

I'm sure Curt Hibbs would be interested, if you haven't shared them already. (I'm also curious)

I think thats like asking "who here does non-web programming full time?" - A) more developers out there are probably doing web development than anything else. B) People flock to rails because it makes web development easier. A+B = C) Most people are using ruby for web development.

As more people get exposed to Ruby via rails though, they will discover how nice and suitable it is to right most other types of programs in it as well.

@Gregory:

Thanks for making me try to convey this into words :) It's an aesthetic thing, so it's a bit hard (and subjective).

I think the difference is that, with Python, you basically end up with a single point of entry - you just have IDLE for interactive mode and code editor.

The question is, of course, if Ruby should follow suit, or if it should find it's own way. The last time I checked, it's goal wasn't to become another Python :)

quoting AdSR:

I think the difference is that, with Python, you basically end up with a single point of entry - you just have IDLE for interactive mode and code editor.

Oh, you're talking about things like FreeRIDE, Scite, and FXRI. None of those are part of the Ruby distribution, they're just bundled in the hopes that they're helpful. IIRC, FreeRIDE has been removed. As to the latter two, I think it's just a convenience thing, I don't expect experienced Rubyists to use those for long.

It's interesting to think about whether Ruby would benefit from a default environment a la IDLE. I think you're right though, it's not necessary for Ruby to copy Python for the sake of Python. In fact, I feel like all you need is a general purpose editor to get the most of Ruby. irb runs great on the command line. :)

But perhaps that clarifies something: there is no editor that is part of the standard ruby distribution

@Scott

You're right. At the same time, I don't think that Rails has to be the single entry point for bringing people into Ruby. I think there are plenty of jobs out there that aren't web-based.

Though you might be right that the market is declining to some extent, there will always be stuff going on in the background that needs general purpose programming tools. Some things are just ill-suited for the web, and though the pressure is there to mallet it in, I don't think that's necessarily a good thing.

This is a classic network effect.

Your company/industry/client has tools that are in Perl, Python, Java, or C++. You have programmers/managers/sysadmins who are familiar with Perl, Python, Java or C++. You have QA/Release/Deployment processes that already work with Perl, Python, Java or C++. You already have Perl/Python/Java interpreters and the supporting packages and libraries installed on all the servers.

Ruby has to have some pretty compelling advantages over Perl, Python, Java or C++ to get past all of those hurdles.

Imagine a problem where we have staff or contractors expert in both Ruby and Perl and a problem you could solve a problem in with 1 hour of coding in Ruby but that required 2 days in Perl. If my company has comparable infrastructure in place to support both Ruby and Perl, we'll obviously choose to write it Ruby. However, it will take weeks to get IT to even begin to consider installing Ruby, and nobody has worked with this Ruby consultant.

1) Rails is a sufficiently compelling reason to get past most of these hurdles on the web, which will ultimately get Ruby more widely deployed and used off the web.

2) Ruby is going to be more used in small shops where these hurdles are smaller. If you don't have an existing infrastructure, why not build it around Ruby?

Ray has said almost everything I wanted to say. Please don't mistake that for a comment on relative quality of implementation or design of the language; it's merely a comment on network effects.

@Ray

very well put. That defines the problem pretty well (in addition to some others)

Do we have clever solutions beyond 'wait and see', and 'ride the Rails wave' ?

I don't ask that provocatively, but as a very serious question on whether it's possible / worth it to try to accelerate things.

I think the comments about the one-click installer ring true: it's amateurish. I know many people who use a nicely packaged build like ActivePerl and ActivePython from ActiveState. ActiveRuby, anyone?

I'm trying to use it for some sysadmin/dba/infrastrucutre glue type automation tasks and I find that Capistrano could be for Systems Administration space what Rails has been for the web-app space.

Cap folks are extremely helpful, however the focus is still development related and for good reason. Hopefully we'll have more people using Cap for more general purpose administration type tasks, so we can slowly develop the Capistrano capability in the systems admin area.

Oddly enough, Ruby is supposed to be a scripting language, but there really aren't any sysadmin specific books out there. Sysadmins have to do tasks on short notice and the emphasis is usually not on best practices and the nuances of object orientation etc. Perl is 'easier' because there are so many ready made scripts already out there that help you get that little thing done right away. (Not the best thing to do when having to do proper software engineering, but this is systems admin slash operations remember? :) There is one Ruby book on sys administration which is supposed to be out there soon, but not sure when. There is a huge automation market in small IT divisions out there just waiting to be exploited.

I think one challenge maybe that people who know tools like Capistrano inside out are not systems admins by trade per se , so those task libraries are not out there as much as development/deployment type task libraries. Even thought Cap2 with it's namespaces and more liberal/decoupled architecture is a godsend and makes things just friggin ripe for someone to exploit the sysadmin automation market (and get Ruby in the 'enterprise' to boot).

Ruby has a strong foothold in the QA/tester community. Do a job search for "Watir".

Most of the time nothing changes, until it does.

In terms of market penetration (outside of Japan), Ruby is a new language, and as such will be adopted more quickly by companies in a position to adopt new languages. Such companies will by nature by small and new, and most tech startups these days are going to be web companies. Hence, most companies who're using Ruby will be using Rails.

In enough years, Ruby will be boring and widespread and you'll see it get used in lots of other contexts. For now I suppose it's Rails.

Things that would help if they were improved would include:

* Not immediately obvious how to produce executables customers can't read. (Will probably improve with YARV (Ruby 1.9) bytecode, like pyc)

* Performance (improving with 1.9)

* IDEs in dynamic languages are more difficult and possibly less useful, except if they tie in the virtual machine (squeak).

* Documentation (Improving). Ri is wonderful, especially FastRi, but it doesn't tie in to local doc formats (man pages, Windows help files) which people want/expect.

* GUIs: nothing really Rubyesque (FXRuby feels too static, the Tk library doesn't feel native to Ruby), and then there are all the licensing, native-look-and-feel issues. Also cross platform support is nontrivial.

Some of these problems are too big for individuals to tackle. Finding a way to break them down into manageable steps would help.

I dont think this has anything to do with the strengths and weekeneces of Ruby. I think this is because most ruby programing it being done on new applications and most new applications are web applications. At the moment the only credible Ruby web fraimwork with mined share is Rails.

I think Joel said something along the lines of "There would have to be a compelling reason not to write a new application as a we aplication".

I think the general consensus was that Ruby just doesn't have the kind of utilities you often see written in perl, at least not many that are wildly popular enough for it to make sense to include it in such a broad thing like the LSB.

In talking to the sysadmins I know, this is their general sentiment. To them, Ruby isn't a "scripting language" in the way Perl is -- it's not just bash-on-steroids. To the sysadmins, Ruby is an application development language. The primary complaint (valid or otherwise) is that it's too hard to fall back down into the shell: Perl's backtick operator and its army of pass-through system functions are part of what makes it a winner for sysadmin functions.

Now, I'm sure Ruby can be used for all the same purposes as Perl, and it'd at least look a lot prettier -- but they haven't really been sold on why it's better.

"Nice ignorant flaimbait Mj. Other commenters, please don't follow that path."

Mj cited facts. CPython is more mature, performs better and has more applications than Ruby. The same was true of Perl vs Python a decade ago. Every dog will have it's day, so be patient Daniel.

Of course waiting may not be enough and Ruby could be derailed from its path to glory by the Java crowd jumping from the J2EE failure onto Ruby's web bandwagon.

The Tiobe index (whatever it means) http://www.tiobe.com/tiobe_index/index.htm seems to show a mostly upward trend for Ruby for the last twelve months.

Quoting Robert Fischer

Perl's backtick operator and its army of pass-through system functions are part of what makes it a winner for sysadmin functions.

Ruby has backtick, and quite a few system functions. Which ones are you missing? I'd be honestly surprised if they were plentiful. Your thought that ruby might be seen as an application development language by sysadmins might be true though... I doubt it's very valid in reality. The only difference I see is that perl has so much code for that kind of stuff on CPAN.

@Paul Novak

Does Tiobe index Rails seperately? :)

@Mark

Don't just drink the koolaid. Joel also says FogBugz is good.

@hgs

Great list, it'd be interesting to post that somewhere and do a follow up a year from now and see if there has been any progress on those.

@Francis

To me (most) rails work is boring. So that's already happened. :)

I think there are no pure ruby jobs because the notion of a "pure" language developer is a dying notion. Even when I was a "pure C++ developer", I still used ruby every day. It's not like I got paid for the minutes where I used C++ and not paid for the minutes where I don't.

It's always seemed strange to me that developers were classified by a "primary" language. Good developers use lots of different tools. Even Java developers, who were once the most isolated, now use multiple languages implemented off the same VM.

@Dave

Of course. It's a matter of using the right tool for the job. However, it seems like Ruby is being overlooked in a lot of ways when it *is* the right tool for the job.

I'm not sure whether I implied anywhere that Ruby is the one true right language, but based on some of the replies I've been getting, let me say that's not what I was suggesting.

I'm talking about how it's annoying that even some small companies I've done work for have been apprehensive about using Ruby for the wrong reasons.

"Waiting on JRuby"?!? Any place clueless enough to do that is probably one where you don't want to work.

I think the real issue is that there's no compelling reason to switch from Python or Perl in other areas. I'm not a web programmer, but in Rails, Ruby seems to temporarily have a monopoly on something that web programmers like. Without that kind of killer app, it's just another scripting language.

I think the real issue is that there's no compelling reason to switch from Python or Perl in other areas.

I think pure object orientation does have some advantages. But you're right, it's not going to sell Ruby to sysadmins.

Still, James Gray's Higher Order Ruby series might be interesting to perl programmers:

http://blog.grayproductions.net/articles/category/higher-order-ruby

As to python, I've always felt as if it's just a stylistic difference that makes me prefer Ruby. I don't get involved in the language wars on this one.

Programmers should have the freedom to select the tools that suit them and the job the best. Sometimes it's Ruby, sometimes it's not. But I'd hate to think that Ruby is being overlooked just because Perl is 'there'.

I think "why are there no Ruby jobs?" is the wrong question. I've had jobs going back to 2001 that involved Ruby programming to some extent. In some of them it was mostly Ruby, in others it was just a little bit of Ruby - none of the applications were web apps. I was initially contacted for a recent gig because of my Ruby skills. They were considering re-writing their non-web app in Ruby (was written in C). After a few weeks they decided that they'd best not rewrite in Ruby, but instead re-architect their system and implement in C++. Since I can also program in C++, it wasn't a problem for me. What ended up happening was that we generated a great deal of our C++ classes using a Ruby-based code generator that read XML descriptions.

My point is that most programming jobs require some mix of programming languages and technologies. I'm not sure it's realistic to ask for Ruby programming jobs when in reality you need to work in a mixture of languages.

My point is that most programming jobs require some mix of programming languages and technologies. I'm not sure it's realistic to ask for Ruby programming jobs when in reality you need to work in a mixture of languages.

You're probably right. Maybe the title made it seem like I was saying that there should be some windfall of homogeneously Ruby related jobs. What I really meant is why isn't knowledge of Ruby a highly in-demand skill when you separate it from Rails related work?

All work environments will involve several languages, I just think that the Ruby community might be doing themselves a dis-service by allowing the language to be typecast as a web language.

I suppose this isn't very different than the Perl == CGI stigma that was popular at one point...

There seem to be quite a bit of ruby jobs at https://jobs.rubynow.com . Although many do seem to be rails specific.

Sorry, I wrote the wrong url, its http://jobs.rubynow.com

@carlos

yeah, that's about the best job resource that I know of. Once in a while, there are some interesting general programming jobs there.

But if you look at the front page, a quick scan reveals literally 100% of the entries are rails related. (At least at this moment)

I thoroughly enjoy the Ruby language, and my experience with it is solely through Rails. That said, outside of Rails I have never seen Ruby as the 'right tool for the job' for whatever task is at hand.

Python has way better incredibly solid and diverse library support, and way better documentation. Python also has very capable web frameworks that offer everything Rails has and even some extra features that Rails doesn't have.

PERL has way more recipe style scripts for the taking.

C++ obviously outperforms other languages.

These languages solve _all_ of my, and the rest of my teams problems, leaving no room for Ruby anywhere in the company.

Ruby has 'feeling' going for it, but until the documentation, libraries and the community mature, it will not be a marketplace contender. Give it a few more years and there is no doubt Ruby will look much better. Python has had 10 years to get to where it is today.

As a personal aside, this is all assuming the Rails network effect is healthy for the Ruby community, which I'm not always sure it is...

Ruby has 'feeling' going for it, but until the documentation, libraries and the community mature, it will not be a marketplace contender. Give it a few more years and there is no doubt Ruby will look much better. Python has had 10 years to get to where it is today.

I'm sure we do need to give it time to mature. I think you've got the order right, documentation is most important (will expose some of the good libraries out there), libraries (where there are holes), and community (which has moved beyond the hype).

Besides the sort of hyper-enthusiasm that is common through some of the Ruby community, what do you see as other aspects that need to mature? In my experience the community as a whole has been one of the best aspects of working in Ruby for me.

As a personal aside, this is all assuming the Rails network effect is healthy for the Ruby community, which I'm not always sure it is...

I has similar doubts sadly...

Well, Ruby can't be used for creating any fat clients because it lacks completely a GUI toolkit. (3rd party ones are too hacks and too much trouble to set up always everywhere etc) It's also hard to distribute and mass-deploy (AD is the *only* choice.. how many ruby apps you have seen in one MSI, containing also the Ruby itself? mmh?) them.

The inconvenient truth: Ruby isn't used for many tasks because it is not suitable for them. It's that simple.

Gregory,

I can tell you that there is a growing use of Ruby in the law enforcement area. There are a number of data mining operations against the victim/offender databases being built out there.

@Michael,

That's pretty interesting. Wonder if Ruport would be any help for the reporting side of things...

Because Ruby is only used by uber-leet Web 2.0 startups, that are never successful enough to require hiring anyone beyond the geek(s) who started the company.

Languages and libraries make a platform. Applications are built on platforms. Rails is the canonical platform for Ruby based web apps. (There are serveral others, but...) So while a marvelously expressive language, the Ruby community has yet to distill what would be the canonical libraries for apps not based on HTML, be they categorized as GUI, enterprise or other. That's my take on it.

@RMB

That's a pretty good way of putting. In terms of commercial viability, Rails *is* the only thing that stands out in Ruby as a platform.

It's fair enough to say for any given domain, there isn't an obvious choice, but usually many options, and your acquaintance to what is available depends on what blogs you read and how long you've been hanging around.

I think what we need is healthy competition and collaboration in these domains. Perhaps Ruby will soon see spill over from the web domain into others, and new platforms will emerge. We are actually seeing that with Ruport, where a lot of our best contributions are now coming from Rails developers, even though the system itself is Ruby centric. It'll be interesting to see where that leads.

What do folks think, beyond the web, are the most important domains to tackle? It's clear that Ruby has a GUI deficiency, and also that the sysadmin domain is pretty well covered by Perl / Python. I wonder if there are low hanging fruit, so to speak, that our community can focus on to help expand its identity beyond teh Railz

The few people I know that know much about Ruby have abandoned it for various reasons. I currently use it at work, but we have issues with stability and memory leakage. I just removed a stack of Active Record and REXML items, but our processes are still leaking memory, albeit much slower.

I feel the Ruby Runtime is still pretty young and not up to par, but if we can cut down on how much we actually do inside of ruby with more down to C modules or up to the web-interface portion, we will probably keep using it out of the need not to rewrite all from scratch. If we had a time machine, I don't think Ruby would have made it. However, if you're a ruby expert and think you could fix this, watch the Seattle craigslist postings, we are hiring.

Ruby is 'new' enough and 'cutting edge' enough that only people who can actually decide for themselves why to write code in it will do so - it will not hit corporate radar until large consultancies or similar companies start putting it out there.

I work for a large consultancy, who told me I couldn't even install it, let alone discuss solutions in it.

Entrpreneurs - enjoy your toy. You can and should use it to eat 'big corporates' lunch for them.

SR

MRI does suck, but why use Ruby over Python? With Rails there was nothing equivalent out there, so it initially had a web development edge. I fully expect Ruby to quickly go back into obscurity as more and more articles are written about Rails' limitations (it's inefficient ORM, tight coupling, and difficulty in getting that last 20% of functionality).

Plus Ruby-the-language is annoying, at least for me.

It's interesting to see how many people decided to make this post into Ruby vs. Python. That was never my intention, and it seems kind of silly to make that argument, honestly.

Python? Perl? Scripting? SYSADMINS? No, no, no, NO. Look upwards. The people who are most interested in Ruby are Java developers who wish to escape Enterprise Hell. Rails is not only a killer app, it lets you create killer apps. It's a meta-app, a Domain Specific Language. Now look farther upwards. The way Rails was created in Ruby turns out to be the big story. Do as the Rails developers! Use Ruby to create a killer Domain Specific Language! Jacob Harris explains this way better than I could.

A good programming language shouldn't need 'good marketing'. While Rails might be good, Ruby is redundant. Python, as merely an example, has better support and more widespread understanding.

It could also be that there are more Ruby programmers around than there are Ruby jobs available ;-)

At the moment there's been a big surge in Perl jobs (especially here in London). What does this mean? Are the actually more Perl jobs? Or are there less Perl programmers around? Hard to tell but there were some Perl stats from jobs.perl.org recently which seemed to suggest more Perl jobs are being posted.

BTW I'm currently contracting to a company where they set up a dev team from scratch and so had a language clean slate. A consultant analysed their requirements and came up with the following ranked list... 1. Perl, 2. Python, 3. Java, 4. PHP, 5-6. Ruby & VB, 7. C# & 8. Delphi.

NB. Obviously this list will change depending on requirements & the consultant! The first three only had about 3-4 weighting points between them.

/I3az/

Well I am paid to write Ruby, but not Rails. Actually I did a bit of Rails also, but most of the work is non-Rails.
The thing I'm working on is a test automation framework, so it's not an application as in 'editor' or 'browser', but used for application level testing.
Actually, there's no reason it couldn't be used for the whole system, apart from the fact that someone would have to implement quite a few interfaces... So I'm a tester not a developer.

Ruby is new Lisp, easy to write and impossible to maintain.

Beyond Rails, Ruby doesn't bring enough to the table to replace languages like Perl and Python that are already entrenched. If Ruby moves in that direction it will take a while if it happens at all. Time will tell.

I'm a Perl developer and the only language that is interesting for me besides Perl is Groovy at the moment (which is basically the same like Perl - written in shiny, bloated Java to make it "cool" and "brand new"). Why should I mess around with Ruby? It has nothing besides Rails that make it unique and/or interesting. And Rais is just a hype that will go away.

Because Ruby is rather mediocre in many ways. Shell scripts, python -- much better.

So it seems like the popular opinion is that Ruby is nothing special without Rails. That's sort of surprising to me, honestly.

I think there are a lot of things that make Ruby a pleasant language to work with, but I'd rather see that proven by example than argue it out here. Hopefully the Ruby project spotlight and the Summer of Code coverage will help bring other interesting things about the language to light.

It is curious how many people have posted to this blog just to bash Ruby though, perhaps there is a better way to spend your time?

I posted something on my site on this: http://www.theecotone.com/2007/06/07/no-ruby-jobs/

A few thoughts:
- So much RubyOnRails vs Java/.NET/PHP/etc, why not more Ruby versus Perl... just less hostility.
- Packed the popularity of Rails, and the upcoming Ruby 2.0... I think the momentum will change for Ruby.
- According to http://www.tiobe.com/tpci.htm, Ruby is growing strong.

@Andy,

Great write up, thanks for linking it here. Your points reiterate a lot of what I feel about the matter, but I wanted to keep the main post open-ended to encourage discussion.

What exactly is a "Ruby job?" What do you do?

I've seen so many of my friends say "Oh, I'd rather be writing pure Ruby, but at least working in Rails gets me close to that, and it's better than working in <insert_language_here>".

Ruby's cute, but not so special that I'd take a crappy job to get "closer" to it. Sounds like this Ruby fetish is ruining your friends' lives.

@Confused

Well, I do business reporting and internal applications. The type of stuff where you should just pick the language that you're most comfortable with, ideally. My clients have been kind enough to let me do that, so I use a lot of camping and ruport day to day. Occasionally we have to dive into other languages, I've used perl, python, C#, C, and Java within the last two years.

But whenever it's an all-things-considered-equal deal, I like to write Ruby, it's not a fetish, just a preference.

So it's not really a matter of finding a "Ruby job" per se, but of finding a job where you have satisfactory "wiggle room" when it comes to choosing your tools?

@oh,

It goes a little bit more deep than that. I didn't realize that this post was going to be offensive to folks who were thinking I was saying "Ruby IS THE ONE TRUE GREAT LANGUAGE", but that I've seen misconceptions about it be harmful.

For example, I had mentioned that I wanted to do a simple web service interaction gig in Ruby, and had a client say "No, I'd rather you use perl, because I don't want you to have to set up a web server and database". That's a clear case of Rails market penetration harming Ruby job possibilties. Sure, working in perl wasn't that bad, I know perl pretty well. But I would have been faster in Ruby because that's where I spend my time.

It's that kind of thing that makes me worried. I'm not a language zealot by any means.

Selling your favorite language to managers/clients, dispelling misconceptions about it, etc. are advocacy issues. You may not be a zealot, but you are advocating.

Your example just goes to show that which dynamic language you use is really of no consequence. Employers should offer more wiggle room in this space. I don't think it goes any deeper.

@Gregory

I don't know if what you took away from my comment was Ruby bashing as it was not meant that way. I really do not think Ruby bring enough to the table (without Rails) that would push it over already entrenched languages like Python and Perl. It could happen though and that would be okay.

@Robert,

I think that Perl and Python are more mature than Ruby, and certainly capable. I just don't think Ruby should be excluded based on misconceptions.

My question was really directed towards Rubyists, not people who are already happily working in other languages. My hope is that the things we can work on to make things better will come to light, and some misconceptions can be dispelled if we work on it.

I guess because Ruby isn't entrenched, it doesn't hurt to advocate a little. But I'm definitely not suggesting that Ruby should be stealing jobs from Python or Perl hackers. Well... unless you're still writing Perl 4.

I've been doing at least some of my development work in Ruby for about four years now, and I think that the whole Ruby vs. Perl vs. Python issue is largely overblown. The issue is far more about library and platform familiarity, which is why Rails as a toolkit is so much more important than the underlying language.

When you commit to really learning a language, the majority of that time is really spent becoming intimately familiar with its standard library, as well as the preferred editors/IDEs, testing tools, and community forums. It is almost certainly a minority of developers who could really explain, say, the metaobject protocol of their preferred day-to-day hacking language in depth, regardless of which language that might be.

I also work in a systems administration group, and have to say that, while Perl is the default choice, (largely due to its use in a bunch of high-profile tools like SpamAssassin) I haven't encountered a lot of resistance to using Ruby for background scripts. Few Perl programmers seem to have all that much trouble picking up Ruby, at least for maintenance and minor tweaks of existing scripts.

Better yet, ask why Ruby as a language has not caught on even though it has existed for a decade and more? Certainly one reason is that Perl and Python got established first. Ruby's designer is Japanese and that certainly hampered any initial adoption in the U.S. (e.g. lack of good English documentation). Ruby, as a language, also doesn't offer all that much more to replace other existing scripting languages - especially when you consider the rich set of accumulated libraries available in Perl and Python. The language features of Ruby which may excite programmers aren't reasons why sysadmins would want to learn it. Performance of Ruby has also historically always been poor. Rails as a framework is insightful and innovative - sufficiently so as a reason to learn the language it requires. Otherwise there aren't many compelling reason to learn Ruby for the Enterprise.

I agree with risottoinc and andrew - Ruby is redundant in the sysadmin space.

Large companies that currently use bash/Perl will resist switching to Ruby, or any other newcomer, for the same reason they continue to use COBOL/FORTRAN/C: the large investment in the existing languages and infrastructure, and the cost of conversion and retraining.

When I was in college - back in the day - we had to take a class called Computer Languages. The concept was pretty straightforward: implement a handful of basic algorithms in every language they could get to run on the mainframe at the moment. Execution was rather harder, though, in some cases: recursion in 360 BAL, string searches in COBOL, anything you had to read again later in APL...

That class taught me two important lessons. First, language bigotry is stupid. Every language has its strong points and weak points. Having a set of tools to choose from can make certain problems easier to solve.

Just as imporantly, though, IMO, that experience got me past the whole "Oh, look! Another language!" thing. Rather than immediately jumping on the bandwagon when I run across a new (to me)language, I take some time to learn its strengths and weaknesses. Unless the strengths fill a gap in my current set of tools, the language stays on the shelf with that big shop air compressor and all the other tools that are not currently worth the investment, but might be worth picking up in the future.

PERL is pervasive and has been around since the 80's. It has been included "by default" on almost every *NIX distro for a very long time. One thing I can tell you (as a system admin) is that you are more likely to learn tools that are installed everywhere by default than become all gung ho with tools that yield resistance on multiple levels. The first being that you have to install it on every system you touch (unless you're the big cheese and include it on an install image you have), but for very large organizations with IT fiefdoms and such, this may not even be an option. Then there is the issue that if you create scripts with a language such as Ruby, most of your peers will not be able to manage those scripts. Yes, you can extoll the virtues of the language, but that doesn't mean they are going to run out and buy a Ruby book and learn it.

Having learned EMACS during my hard core developer days and being incredibly proficient at it, invariably I always defer to VI for editing since it exists everywhere.

It's simply a chicken and egg problem. Given enough time it may join PERL as a de facto standard, but that day is still a ways off.

-M

@MP

There is no "PERL" installed anywhere. It is "Perl" for the language and "perl" for the interpreter.

Hahaha, yeah, I've been chuckling every time I see PERL mentioned in this thread. At least people haven't been saying RUBY.

Hello,
I can only speak from my perspective. Actually I like ruby and try to use it when possible (smaller scripts). But I am claimed to use perl. My chief and colleagues argue that also other people not knowing ruby should be enabled to maintain the code and the most code is written in perl. I personally think, that it is much easier to understand ruby-code then perl-code and even if you know perl you can get into trouble understanding the code of someone else.

There was a message to a local mailing (seattletechstartups.com) list for Seattle entrepreneurs this morning that included:

"Oh, and we're hiring Ruby developers. (Is there an echo in here?)"

Every recent post that's been about jobs has been for Ruby. And this is in Seattle (aka "Microsoftland"), where Microsoft's influence is huge, on a non-Ruby mailing list.

I'm going to stick by my earlier point: HTML is how the vast majority of new applications communicate with their users. Rails is the GUI generator of choice for Ruby. Since a solid majority of apps need a GUI, trying to separate out Rails jobs from Ruby jobs isn't a useful exercise. How many C# jobs are there that don't also require WinForms or Web Forms?

What we used to think of as GUI libraries are really dead technologies; the world has voted, and HTML has turned things like X Windows and Windows Forms into niche platforms . When you say that "Single user, offline apps, do not need Rails," you've got something of a point, but the number of those apps is tiny.

Is always the same problem for emerging tecnologies..all the technical people are pure innovators while all managers (who decide) are totally conservative.
Is the same in IT and all other high tech stuff( I work in the field of high-end or new-generations servo hydraulics systems and the applications are still very few compared with the traditional hydraulics solutions).

I think the smaller number of available modules and libraries, and the lack of sufficient documentation on existing one may also contribute to the slower adoption of ruby in the real world of system administration.

a. Big companies (I used to work at one) like to Standardize. Python is slightly older, and so once a big company has Standardized on it, Ruby is locked out. So sad.

b. The libraries just aren't there. 5 years ago I went looking for a new language to learn. I looked at Ruby and Python and decided that Ruby looked nicer. Then I saw it had none of the libraries I needed (GTK+, OpenGL, Unicode, etc.) so I learned Python instead. Ruby is a great language, but the libraries one needs for writing desktop apps with it just aren't there yet.

There are still a huge class of problems for which Ruby would be a great solution, but due to #1 and #2 people look for a way to do them in Python/Perl.

Despite Daniel's comment, Mj is right: where's Ruby's JIT? Now, it probably doesn't matter most of the time, but if you're trying to sell Ruby against an entrenched language with better libraries, you've got to have *some* selling point. Today, that's ... Rails.

It sounds like you need a DHH of desktop Ruby apps. Somebody to assemble a full-stack like Rails for desktop apps. (Heck, steal half of Rails for this: ActiveRecord, ActiveSupport, ...) Until then, Ruby will continue to be used for its strengths (Rails).