Pros/Cons of Turbogears/Rails?

ruby-talk
1

First, I don't intend this to be a flame war, please. Python
and Ruby are the only two languages I'd willingly work in
(at least amongst common languages), and TurboGears and
Rails seem roughly equivalent.

I'm much more knowledgable about Python, but that's a minor
issue--I've been intending to learn more Ruby anyway.

Here are the pros and cons that I'm aware of and consider
important:

Turbogears:
+ SqlObject allows working with the DB tables without
using SQL itself.
+ Likely to be faster because as far as I'm aware, Python
is significantly faster.
+ Easy access to other libraries (such as the Python
Imaging Library) that Ruby, being a relatively newer
language, doesn't have equivalents to.
+ Built-in default SQLite makes it easier to set up?
(as far as I can tell, Ruby requires MySql by default--don't
know how easy this is to change.)
+ I find the templating system somewhat cleaner; code in
py: xml namespace allows pure .html templates, instead
of equivalent of .rhtml files.

Ruby:
+ More mature system. More stable? More features?
+ Much better documented. This is a biggie.
+ Built-in Rubydoc system would make documenting the
system easier. (IMHO, developers almost always
underestimate the need for good documentation that
is written along withe the system.) Is there a
Python doc system that has received Guido's blessing
yet? D'oxygen would seem an obvious choice.
+ Better coordination with Javascript helper code?

I was initially leaning towards Rails due to maturity,
but the most recent version of TurboGears seem to have
fixed a lot of the "ad hoc" feeling I got from previous
versions. But I'm still very much up in the air.

Thanks,
Ken

P.S. If I wanted to provide an image by streaming the
file data directly over the connection, rather than by
referring to an image file, how would I do that? I'd
like to build code that would allow images to be assembled
into a single-file photo album (zip or bsddb file), and
so can't refer to them as individual image files.

2

First, I don't intend this to be a flame war, please. Python
and Ruby are the only two languages I'd willingly work in
(at least amongst common languages), and TurboGears and
Rails seem roughly equivalent.

I'm also not trying to attack Turbogears, as I know nothing about it. I will respond to some of those points with a Rails slant though, just for your information.

Here are the pros and cons that I'm aware of and consider
important:

Turbogears:
+ SqlObject allows working with the DB tables without
using SQL itself.

Rails has migrations which allow you to manipulate the database in Ruby. You can also use Rails's console script to interactively play with your database.

+ Easy access to other libraries (such as the Python
Imaging Library) that Ruby, being a relatively newer
language, doesn't have equivalents to.

Ruby does have an imaging library called RMagick.

+ Built-in default SQLite makes it easier to set up?
(as far as I can tell, Ruby requires MySql by default--don't
know how easy this is to change.)

You have to change one line of a config file to use an SQLite database with your Rails application. Its very easy.

+ I find the templating system somewhat cleaner; code in
py: xml namespace allows pure .html templates, instead
of equivalent of .rhtml files.

Just FYI, rhtml files are just one way to build output with Rails. You might want to look at using Builder, which is a pure Ruby interface.

Hope that helps.

James Edward Gray II

···

On Aug 27, 2006, at 3:10 PM, kenneth.m.mcdonald@sbcglobal.net wrote:

3

Kenneth -- a few comments below...

My knowledge of Rails is slight, so others may
contradict me. If so, they are likely right.

First, I don't intend this to be a flame war, please. Python
and Ruby are the only two languages I'd willingly work in
(at least amongst common languages), and TurboGears and
Rails seem roughly equivalent.

I'm much more knowledgable about Python, but that's a minor
issue--I've been intending to learn more Ruby anyway.

Here are the pros and cons that I'm aware of and consider
important:

Turbogears:
+ SqlObject allows working with the DB tables without
using SQL itself.

Rails can do this.

+ Likely to be faster because as far as I'm aware, Python
is significantly faster.

Perhaps. If you do measurements, share your findings with us.

+ Easy access to other libraries (such as the Python
Imaging Library) that Ruby, being a relatively newer language, doesn't have equivalents to.

I don't know what that is, but we do have RMagick, which
binds to GraphicsMagick or ImageMagick.

+ Built-in default SQLite makes it easier to set up?
(as far as I can tell, Ruby requires MySql by default--don't
know how easy this is to change.)

Ruby can do SQLite. I think Rails makes it pretty easy to
change databases.

+ I find the templating system somewhat cleaner; code in
py: xml namespace allows pure .html templates, instead
of equivalent of .rhtml files.

Matter of taste. I don't have an opinion really.

Ruby:
+ More mature system. More stable? More features?

Perhaps. I know *nothing* about TurboGears.

+ Much better documented. This is a biggie.
+ Built-in Rubydoc system would make documenting the
system easier. (IMHO, developers almost always
underestimate the need for good documentation that
is written along withe the system.) Is there a
Python doc system that has received Guido's blessing
yet? D'oxygen would seem an obvious choice.
+ Better coordination with Javascript helper code?

Did you mean RDoc?

I was initially leaning towards Rails due to maturity,
but the most recent version of TurboGears seem to have
fixed a lot of the "ad hoc" feeling I got from previous
versions. But I'm still very much up in the air.

Thanks,
Ken

P.S. If I wanted to provide an image by streaming the
file data directly over the connection, rather than by
referring to an image file, how would I do that? I'd
like to build code that would allow images to be assembled
into a single-file photo album (zip or bsddb file), and
so can't refer to them as individual image files.

Hmm... I did this once. Had something to do with the content-type.
It's usually text/html or text/plain, but if you change it to
the proper string and set the content-length appropriately also,
I think it Just Works.

You might try the old trick of telnetting into a web server on
port 80 and pretending to be a browser. (If you can remember
exactly how to do this; I don't). Use a URL that points directly
to a small image and watch the stuff you get back.

Cheers,
Hal

···

kenneth.m.mcdonald@sbcglobal.net wrote:

4

Just output the encoded / compressed byte stream the image manipulation library of choice can surely provide to the HTTP connection? Setting the MIME type of the response accordingly. You might want to look up hacks on how to do efficient byte-pushing for this, standard Ruby IO might or might not be optimal.

David Vallner

···

kenneth.m.mcdonald@sbcglobal.net wrote:

P.S. If I wanted to provide an image by streaming the
file data directly over the connection, rather than by
referring to an image file, how would I do that? I'd
like to build code that would allow images to be assembled
into a single-file photo album (zip or bsddb file), and
so can't refer to them as individual image files.

5

Looks like you mixing comparisons.

Ruby:
+ More mature system. More stable? More features?

uh, no, Python predates Ruby by a good bit
Rails might be "older" than Turbogears but it still JUST went 1.0
officially.
It can't be called "mature' by any defintition.

+ Much better documented. This is a biggie.

Rails has no documentation, period. The authors acknowledge this
openly.

+ Built-in Rubydoc system would make documenting the
system easier. (IMHO, developers almost always
underestimate the need for good documentation that
is written along withe the system.) Is there a
Python doc system that has received Guido's blessing
yet? D'oxygen would seem an obvious choice.

Pydoc IS standard. This has been around for a long time.

+ Better coordination with Javascript helper code?

Again, is this a Python vs Ruby or Turbogears vs Rails post, you seem
highly confused on the distinctions between language vs framework.

I was initially leaning towards Rails due to maturity,
but the most recent version of TurboGears seem to have
fixed a lot of the "ad hoc" feeling I got from previous
versions. But I'm still very much up in the air.

again, Ruby can't be considered 'mature' by any definition.

Thanks,
Ken

P.S. If I wanted to provide an image by streaming the
file data directly over the connection, rather than by
referring to an image file, how would I do that? I'd
like to build code that would allow images to be assembled
into a single-file photo album (zip or bsddb file), and
so can't refer to them as individual image files.

???

···

kenneth.m.mcdonald@sbcglobal.net wrote:

6

First, I don't intend this to be a flame war, please.

Then avoid crossposting to both c.l.ruby and c.l.python !-)
(BTW, fu2 c.l.python).

Python
and Ruby are the only two languages I'd willingly work in
(at least amongst common languages), and TurboGears and
Rails seem roughly equivalent.

I'm much more knowledgable about Python, but that's a minor
issue--I've been intending to learn more Ruby anyway.

Here are the pros and cons that I'm aware of and consider
important:

Turbogears:
+ SqlObject allows working with the DB tables without
using SQL itself.

I personnaly don't like SqlObject. SqlAlchemy looks like a much better
solution IMHO. And FWIW, Ruby has it's own ORM too.

(snip)

I was initially leaning towards Rails due to maturity,
but the most recent version of TurboGears seem to have
fixed a lot of the "ad hoc" feeling I got from previous
versions. But I'm still very much up in the air.

Then take a few days to play with both Rails and TG and go with the one
that better fits your brain.

FWIW, you may also want to check Pylons (another Python Web-MVC framework).

My 2 cents

···

kenneth.m.mcdonald@sbcglobal.net wrote:
--
bruno desthuilliers
python -c "print '@'.join(['.'.join([w[::-1] for w in p.split('.')]) for
p in 'onurb@xiludom.gro'.split('@')])"

7

As I read in another post on this thread, do some initial scoping out
of either framework and pick the one that seems to suit your way of
thinking/coding the best. If you scan over some sample code on the
projects' websites you should get a basic idea of what they will be
like.

Although a bit more obscure than the two frameworks you are
considering, have you checked out Seaside (http://seaside.st)? It's a
Smalltalk framework that interests me personally. I've had the
opportunity to check it out briefly, but haven't had a chance to
actually mock up an app using it. If you check it out as well as a neat
AJAX library that can overlay it called Scriptaculous
(http://script.aculo.us) you can do some pretty slick things concisely.
I doubt that something like this will immediately skyrocket to the top
of the commercial developer's hit list, but it is something that I
would play around with since it will only expand my knowledge base. And
I can have fun while doing it :slight_smile:

Out of what I've seen working with Rails and checking out TurboGears I
chose Rails since it fit in with my way of thinking the best. Everyone
has their own taste so I wouldn't take any one person's (or one
group's) opinion. Read up on them a bit and see which one looks the
most interesting to you.

···

kenneth.m.mcdonald@sbcglobal.net wrote:

First, I don't intend this to be a flame war, please. Python
and Ruby are the only two languages I'd willingly work in
(at least amongst common languages), and TurboGears and
Rails seem roughly equivalent.

I'm much more knowledgable about Python, but that's a minor
issue--I've been intending to learn more Ruby anyway.

Here are the pros and cons that I'm aware of and consider
important:

Turbogears:
+ SqlObject allows working with the DB tables without
using SQL itself.
+ Likely to be faster because as far as I'm aware, Python
is significantly faster.
+ Easy access to other libraries (such as the Python
Imaging Library) that Ruby, being a relatively newer
language, doesn't have equivalents to.
+ Built-in default SQLite makes it easier to set up?
(as far as I can tell, Ruby requires MySql by default--don't
know how easy this is to change.)
+ I find the templating system somewhat cleaner; code in
py: xml namespace allows pure .html templates, instead
of equivalent of .rhtml files.

Ruby:
+ More mature system. More stable? More features?
+ Much better documented. This is a biggie.
+ Built-in Rubydoc system would make documenting the
system easier. (IMHO, developers almost always
underestimate the need for good documentation that
is written along withe the system.) Is there a
Python doc system that has received Guido's blessing
yet? D'oxygen would seem an obvious choice.
+ Better coordination with Javascript helper code?

I was initially leaning towards Rails due to maturity,
but the most recent version of TurboGears seem to have
fixed a lot of the "ad hoc" feeling I got from previous
versions. But I'm still very much up in the air.

Thanks,
Ken

P.S. If I wanted to provide an image by streaming the
file data directly over the connection, rather than by
referring to an image file, how would I do that? I'd
like to build code that would allow images to be assembled
into a single-file photo album (zip or bsddb file), and
so can't refer to them as individual image files.

8

In my understanding, which relies completely on the judgements of
co-workers regarding the rails side of the debate, TurboGears is more
flexible. Tasks which fall inside the scope of Rails' "opinion" are
probably easier there, but anything outside of what Rails was built to
do is harder than equivalent deviations from TurboGears. Obviously this
amounts to little more than hearsay, but nonetheless I think it is an
important element to look into.

I can say that each of them has their own genius decisions, and neither
is so lacking in documentation or community support to preclude
choosing either framework based on how well it suits your project.

9

+ SqlObject allows working with the DB tables without
using SQL itself.

Rails has ActiveRecord ORM, which IMO has nicer and simpler
syntax than SQLObject. Rails has migrations, TB - not (Migrations is
versioning system for evolving database schema)

+ Likely to be faster because as far as I'm aware, Python
is significantly faster.

Python is maybe faster, but with YARM (which is not stable yet) Ruby
will be about 10x faster. YARM is full virtual machine like Java.

+ Easy access to other libraries (such as the Python
Imaging Library) that Ruby, being a relatively newer
language, doesn't have equivalents to.

Ruby is not so young you think. It became more popular
when Rails has appeared.

+ Built-in default SQLite makes it easier to set up?

What? :slight_smile: YAML is much easier.

(as far as I can tell, Ruby requires MySql by default--don't
know how easy this is to change.)

Change in config/database.yml driver: mysql to any you want,
like db2, postgres, sqlserver, sqlite, firebird, oracle etc. You can
change
default settings as well. See: rails --help

+ I find the templating system somewhat cleaner; code in
py: xml namespace allows pure .html templates, instead
of equivalent of .rhtml files.

But rhtml is much more flexible because it can generate *any content*,
not only xml. But Rails has THREE template systems: rhtml (main), rxml
(for rss and xml generation) and rjs (for javascript and AJAX).

And last but not least, TG is based on poor, unstable and buggy
CherryPy server. We had huge problems with CherryPy. I think that
Django or Pylons are much better frameworks. IMO TG is no competition
for Rails at all. The only real competition is Django or Pylons.

···

kenneth.m.mcdonald@sbcglobal.net wrote:

--
Jaroslaw Zabiello
http://blog.zabiello.com

10

The name of the virtual machine that runs Ruby 1.9 and up, is YARV (not YARM).

I'm not sure what makes you say it's "10x faster," but that sounds a little high to me. My recent playing with the VM showed a little over a 2x increase in speed, for the code I was running. This was a very unscientific test for sure, but it *may* be a little closer to the average speed increase people are likely to see.

James Edward Gray II

···

On Aug 31, 2006, at 9:30 AM, Jaroslaw Zabiello wrote:

kenneth.m.mcdonald@sbcglobal.net wrote:

+ Likely to be faster because as far as I'm aware, Python
is significantly faster.

Python is maybe faster, but with YARM (which is not stable yet) Ruby
will be about 10x faster. YARM is full virtual machine like Java.

11

"Jaroslaw Zabiello" <hipertracker@gmail.com> writes:

+ SqlObject allows working with the DB tables without
using SQL itself.

Rails has ActiveRecord ORM, which IMO has nicer and simpler
syntax than SQLObject. Rails has migrations, TB - not (Migrations is
versioning system for evolving database schema)

TG supports SQL Alchemy as well. With SQL Alchemy I believe you'll have a
better experience than with Rails' ORM.

With regards to Migrations, SQL Object does support something like that, but
you have to explicitly code it and then you can run sqlobject-admin upgrade
(or the equivalente tg-admin sql upgrade, since it is a wrapper...).

But rhtml is much more flexible because it can generate *any content*,
not only xml. But Rails has THREE template systems: rhtml (main), rxml
(for rss and xml generation) and rjs (for javascript and AJAX).

Well, TG has a few templating systems... MarkUp, Kid, Cheetah, ZPT, and
others. You can choose the one that best fits your needs / brain. You can
even have multiple template systems used depending on what was requested for
the same controller...

Which one is better isn't of my concern. I've already tested then and decided
what I want to use. The best thing is try them and see what works. You don't
have to choose only one -- but you have to use one per project to make it less
messy :wink:

···

kenneth.m.mcdonald@sbcglobal.net wrote:

--
Jorge Godoy <jgodoy@gmail.com>

12

Well, TG has a few templating systems... MarkUp, Kid, Cheetah, ZPT, and
others. You can choose the one that best fits your needs / brain. You can
even have multiple template systems used depending on what was requested for
the same controller...

Just to complete the comparison, Rails can also use a variety of
templating systems besides the standard three mentioned.

Liquid
MasterView
Markaby
Amrita2

and many more each day. Many are listed in the plugins page of rails wiki
http://wiki.rubyonrails.org/rails/pages/Plugins

Blessings,

Jeff Barczewski
MasterView project founder
http://masterview.org/

13

Jaroslaw Zabiello wrote:

> + SqlObject allows working with the DB tables without
> using SQL itself.

Rails has ActiveRecord ORM, which IMO has nicer and simpler
syntax than SQLObject. Rails has migrations, TB - not (Migrations is
versioning system for evolving database schema)

I don't really see TG sticking with SQLObject. In moving to SQLAlchemy
it would pick up not only a migration system but also a much more
flexible abstraction system due to the use of a Data Mapper pattern
instead of the Active Record pattern. There already is an
implementation of Active Record on top of that, so that benefit stays
as well.

> + Likely to be faster because as far as I'm aware, Python
> is significantly faster.

Python is maybe faster, but with YARM (which is not stable yet) Ruby
will be about 10x faster. YARM is full virtual machine like Java.

I tried to check out information on this, but the only docs I found
that looked like what I wanted were written in japanese. Do you have
any links discussing the status of this project? Does it make any
breaking changes to the Ruby implementation that will have to be fixed?
Has the RoR project already agreed to port to this when it is stable?

> + Easy access to other libraries (such as the Python
> Imaging Library) that Ruby, being a relatively newer
> language, doesn't have equivalents to.

Ruby is not so young you think. It became more popular
when Rails has appeared.

Although that is true there are not as many libraries available for
Ruby as there are for Python. This will probably change as the language
gains popularity, but for right now it pays to look into library
support before considering anything else about the language.

> + I find the templating system somewhat cleaner; code in
> py: xml namespace allows pure .html templates, instead
> of equivalent of .rhtml files.

But rhtml is much more flexible because it can generate *any content*,
not only xml. But Rails has THREE template systems: rhtml (main), rxml
(for rss and xml generation) and rjs (for javascript and AJAX).

Kid can be used to generate xhtml, rss, xml, pretty much anything that
is xml-based. I have even seen it used to generate xul applications for
firefox. The only thing on your list that it doesn't do is javascript.
Personally I would rather learn one templating language that is able to
treat all of my xml as xml no matter what use it is put to.

And last but not least, TG is based on poor, unstable and buggy
CherryPy server. We had huge problems with CherryPy. I think that
Django or Pylons are much better frameworks. IMO TG is no competition
for Rails at all. The only real competition is Django or Pylons.

I have never had much in the way of problems with CherryPy. From what I
have heard the project has made a lot of improvements recently, so it
may have changed since you last took a look at it.

Actually that point right there is where I think TG is a lot more
competitive that you believe. When a new version of any of the
foundation projects comes out, or a better project to fill that
particular need, TG can absorb it in the next version. The TurboGears
developers can spend most of their time working on additional code that
makes the project more useful instead of bug fixes and minor feature
upgrades to the core components. This philosophy is proven to work for
most other open source projects, and I have yet to hear a good argument
why it would not be successful for a web framework.

-Adam

···

kenneth.m.mcdonald@sbcglobal.net wrote:

14

Jaroslaw Zabiello a écrit :

Python is maybe faster, but with YARM (which is not stable yet) Ruby
will be about 10x faster. YARM is full virtual machine like Java.

Google doesn't find YARM and so, YARM does not exist. Care to provide an URL or something?

15

I believe he was referring to YARV (yet another ruby virtual machine)
which is planned to accompany the Ruby 2.0 release. YARV is in active
development now but early indications are positive with regards to
perfomance improvements.

http://www.atdot.net/yarv/

···

On 8/31/06, Christophe <chris.cavalaria@free.fr> wrote:

Jaroslaw Zabiello a écrit :
> Python is maybe faster, but with YARM (which is not stable yet) Ruby
> will be about 10x faster. YARM is full virtual machine like Java.

Google doesn't find YARM and so, YARM does not exist. Care to provide an
URL or something?

16

TG supports SQL Alchemy as well. With SQL Alchemy I believe you'll have a
better experience than with Rails' ORM.

I would not be so sure. I have tried to work with SQL Alchemy (using
Pylons) and I have been disappointed. :frowning: It's syntax for selects is ugly
and not intuitive. Django ORM looks much better. SQLAlchemy has to be added
to Django as alternative ORM but *without breaking* current, clean API:
http://groups.google.com/group/django-developers/browse_thread/thread/5149e1c60dc65bff/a177bb34cfde1ec7

But rhtml is much more flexible because it can generate *any content*,
not only xml. But Rails has THREE template systems: rhtml (main), rxml
(for rss and xml generation) and rjs (for javascript and AJAX).

Well, TG has a few templating systems... MarkUp, Kid, Cheetah, ZPT, and
others. You can choose the one that best fits your needs / brain.

This is another topic. Rails can also use another third-party template
system (like Liquid which was inspired by Django). For me using many,
different template systems *for the same task* make no sense. Rails uses
three templates, but for *different tasks*. Its RJS is perfect for AJAX.
Really cool, simple, and almost no javascript is required. Just clean Ruby
for everything.

···

On Thu, 31 Aug 2006 11:42:47 -0300, Jorge Godoy wrote:

--
Jarosław Zabiełło
http://blog.zabiello.com

17

I've found that familiarity with Windows in the Ruby/Rails community is
less than in the Python/TG community. Ruby/Rails seems to have been
mainly *nix until fairly recently.

Sometimes the Windows version of a module or tutorial will lag
significantly. (ldap comes to mind.) Sometimes Windows-oriented
questions get pretty short shrift along the lines of: "Perish the
thought!" or "Why would you?" instead of serious treatment.

It's not a deal-breaker and neither community is perfect in this
respect. I now work mostly with Ruby/Rails, but I did Python/CherryPy
for quite a while, and that's my impression.

Ron

···

kenneth.m.mcdonald@sbcglobal.net wrote:

I was initially leaning towards Rails due to maturity,
but the most recent version of TurboGears seem to have
fixed a lot of the "ad hoc" feeling I got from previous
versions. But I'm still very much up in the air.

Thanks,
Ken

18

Jaroslaw Zabiello wrote:

+ Built-in default SQLite makes it easier to set up?

What? :slight_smile: YAML is much easier.

*adding oil to the flames*

Oh, -please-. Can we please not compare things that are totally incomparable? Data storage != database. The former is a tool for storing data, the latter for manipulating data. DataBASES usually being of the table-oriented paradigm because then let you manipulate data in other ways than more imperative programming languages, and thus they enhance your toolbox with more than just data storage capabilities if you can use them.

True enough, you usually only use the data storage of databases when you use an ORM layer, and persisting as [insert format here] might turn out just fine. Still, I wouldn't let any data storage without atomic transaction support near a production web application under a multithreaded / multiprocess server.

David Vallner

19

Looks like you mixing comparisons.

> Ruby:
> + More mature system. More stable? More features?

uh, no, Python predates Ruby by a good bit
Rails might be "older" than Turbogears but it still JUST went 1.0
officially.
It can't be called "mature' by any defintition.

Python itself predates Ruby only three years.

> + Much better documented. This is a biggie.

Rails has no documentation, period. The authors acknowledge this
openly.

Rails has plenty of documentation, it's just that the quality of the
API isn't as good as everyone wishes. That's actively being worked on,
with funds raised by the Caboose folks, and plenty of community
participation. However, there are plenty of materials on Rails itself,
including Agile Web Development with Rails from the Pragmatic
Programmers which is itself an awesome resource.

> I was initially leaning towards Rails due to maturity,
> but the most recent version of TurboGears seem to have
> fixed a lot of the "ad hoc" feeling I got from previous
> versions. But I'm still very much up in the air.

again, Ruby can't be considered 'mature' by any definition.

As far as speed is concerned, I know Ruby isn't the fastest out there,
but is not slow. That is, you can tweak things to make Rails run
really fast. There is plenty out there documenting how to set up
Mongrel with Apache2.2 and mod_proxy_loader or Pound or whatever the
hell you want. Basically: you can make Rails very fast.

And as far as SQLObject, the ActiveRecord library is very good, and
produces the SQL for you. It works with a number of RDBMSes, including
SQLite, MySQL, and, my favorite, PostgreSQL. ActiveRecord is also
connected to Migrations which allows you to handle revisions in the
schema, and actually generating/modifying your databases without SQL
at all. Also, ActiveRecord has the distinct quality of not requiring
you to specify what columns the table has: it finds this out for you.

As far as templating goes, I've found that the _concept_ of Rails'
templating system was a bit jarring, but in practice it's actually
quite beautiful and easily understood. I think it's so easy a design
team wouldn't have any problems picking it up (if they can function
logically).

For me, the only reason to use the Python-based TurboGears would be a
specific Python library. And, given that, I'd probably go with Django.

Cheers,

M.T.

20

Looks like you mixing comparisons.

> Ruby:
> + More mature system. More stable? More features?

uh, no, Python predates Ruby by a good bit

Where 'good' means 'shifted left once?' (2 years -- 93 vs 95)

Rails has no documentation, period. The authors acknowledge this

openly.

http://api.rubyonrails.org/

... wha?

> I was initially leaning towards Rails due to maturity ...
again, Ruby can't be considered 'mature' by any definition.

Looks like you['re] mixing comparisons.

···

On 8/27/06, fuzzylollipop <jarrod.roberson@gmail.com> wrote:

kenneth.m.mcdonald@sbcglobal.net wrote: