Why are there no Ruby jobs?

by Gregory Brown

Here's an open question that I'm hoping will get some interesting discussion going:
Why are there so few Ruby jobs out there?

Those of you who have been to RubyConf in recent years have been asked the question "How many people get paid to write Ruby?", and you'd see that in the last year or two, the number of people who raise their hand has absolutely skyrocketed.

However, at Gotham Ruby Conference, someone asked "How many people are paid to write plain Ruby, no Rails". I think like 3 hands went up, and I was one of them, out of 120 or so people. It's possible that we just have a lot of Rails work in NYC, but I think the issue might be deeper than that.

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

Is Ruby really only viable for database driven web applications? I doubt it. I think it can stand its ground anywhere Perl or Python could. So why is it that most job postings you see are for some sort of "Web Rockstar", and not like, a sysadmin with scripting experience, or an internal applications developer?

I guess it could be a lot of things, any of the below or a combination might be to blame:


  • Lack of good marketing for non-web oriented Ruby

  • Assumption that Ruby is not general purpose as a side effect of the success of RoR's marketing

  • Technical issues that I can't think of that make it an inferior choice to other languages

  • Ruby adoption might be in nature slower than Rails adoption, but on it's way

  • MRI isn't robust enough for the 'enterprise', so companies are waiting on JRuby



I don't really know what it is. I understand when corporate politics get involved, all things go out the window, but I think that Ruby's success as a commercially viable language outside of Rails is less than what it should be at this point. Do other people feel the same way?

UPDATE: Buried deep within the mixed replies to this post is a great writeup by Andy Peters which states more assertively what I was implying here...

83 Comments

Mj
2007-06-06 10:15:50
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.

Daniel
2007-06-06 10:33:52
Nice ignorant flaimbait Mj. Other commenters, please don't follow that path.
Curt Hibbs
2007-06-06 10:41:30
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.
Brian Guthrie
2007-06-06 10:44:14
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.
John Hornbeck
2007-06-06 10:48:52
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.
Sergio
2007-06-06 10:57:12
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.
Lori
2007-06-06 10:57:24
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.
Gregory
2007-06-06 10:58:23
@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... :-/

Gregory
2007-06-06 11:03:35
@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.

AdSR
2007-06-06 11:21:32
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.

James Moore
2007-06-06 11:23:05
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.

Gregory
2007-06-06 11:30:55
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.

Gregory
2007-06-06 11:33:44
@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.

Brian Guthrie
2007-06-06 11:52:37
@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.
AdSR
2007-06-06 11:59:32
@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.

Gregory
2007-06-06 12:03:08
@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.

Gregory
2007-06-06 12:06:14
@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)

Scott Becker
2007-06-06 12:20:37
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.

AdSR
2007-06-06 12:25:13
@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 :)

Gregory
2007-06-06 12:44:31
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.

Ray
2007-06-06 14:00:31
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?

chromatic
2007-06-06 14:07:02
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.
Gregory
2007-06-06 14:34:58
@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.

Mark
2007-06-06 18:51:02
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?
Amr
2007-06-06 19:22:39
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).


Chris
2007-06-06 20:28:45
Ruby has a strong foothold in the QA/tester community. Do a job search for "Watir".
Francis Hwang
2007-06-06 20:48:15
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.

hgs
2007-06-07 04:34:04
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.

Mark
2007-06-07 05:33:06
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".

Robert Fischer
2007-06-07 05:55:55
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.

Laurent Szyster
2007-06-07 06:09:47
"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.

Paul Novak
2007-06-07 07:13:31
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.
Gregory
2007-06-07 07:22:54
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. :)

Dave Fayram
2007-06-07 07:36:05
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.

Gregory
2007-06-07 07:52:05
@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.

sean
2007-06-07 08:09:55
"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.

Gregory
2007-06-07 08:25:18

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

UncleOxidant
2007-06-07 09:32:36
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.

Gregory
2007-06-07 09:38:49

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

carlos
2007-06-07 10:05:43
There seem to be quite a bit of ruby jobs at https://jobs.rubynow.com . Although many do seem to be rails specific.
carlos
2007-06-07 10:06:35
Sorry, I wrote the wrong url, its http://jobs.rubynow.com
Gregory
2007-06-07 10:15:53
@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)

risottoinc
2007-06-07 10:32:48
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...

Gregory
2007-06-07 10:50:32

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

bloppo
2007-06-07 11:13:19
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.

Michael
2007-06-07 11:18:01
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.

Gregory
2007-06-07 11:27:22
@Michael,


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

Violent Acres
2007-06-07 13:22:28
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.
RMB
2007-06-07 15:21:45
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.
Gregory
2007-06-07 15:32:46
@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