Actually, despite the fact that I love Ruby a lot, I'm inclined to
partially agree with him on this. Presently, our company does have
some Rails-based web applications deployed but they're predominantly
applications geared for use by only a few people (internal client use
only); we've not yet tried to deploy a real public-facing web
application based on Rails. For that, it works really well. We're
taking a wait and see attitude before we attempt to use Rails for any
high load applications; my own experiences attempting to optimize
plain Ruby code for performance have been simultaneously frustrating
and rewarding. I doubt I could do the same with a Rails app. So for
now we're gonna stick with PHP for our public facing web applications,
even if it is even worse for i18n/l10n/m17n applications than Ruby
is...
Hi,
I am very proud he mentioned Ruby in one of his essays. Actually, I
agree with his conclusion:
that's not a safe choice for at least another year or six. that's not
a safe choice for at least another year or six.
He is a businessman, not a geek, so he does not have to risk himself
using Ruby (and Rails). It doesn't matter. He will not pay me
anything even if he choose Ruby.
But we disagree in the middle.
(1) it displays a stunning antipathy towards Unicode and
(2) it's known to be slow, so if you become The Next MySpace, you'll
be buying 5 times as many boxes as the .NET guy down the hall.
(1) Although we took different path to handle m17n issue from other
Unicode centric languages, we don't have any "stunning antipathy".
(2) Although Ruby runs slower than other languages in those
micro-benchmarks, real bottleneck in the most application lies in
either network connection or databases. So we don't have to buy 5
times as many boxes.
matz.
···
In message "Re: Joel Spolsky on languages for web programming" on Fri, 1 Sep 2006 20:30:02 +0900, "Dido Sevilla" <dido.sevilla@gmail.com> writes:
He is a good writer, and I really like how he cuts through the
rhetoric and is firmly grounded on practical programming matters.
His core point on technology choice is valid:
"How do you decide between C#, Java, PHP, and Python? The only real
difference is which one you know better. If you have a serious Java
guru on your team who has build several large systems successfully
with Java, you're going to be a hell of a lot more successful with
Java than with C#, not because Java is a better language (it's not,
but the differences are too minor to matter) but because he knows it
better. Etc."
His point is valid too if you have a big Rails guru on your team, someone who
has built large successful Rails systems, then you pick a Rails solution.
The performance/scalability of Rails as an enterprise web-fronted system is
continually questioned. People point to Basecamp etc. as examples that Rails can
do it.
But thats missing the point - those systems are successful becuase those
companies have very good, experienced Rails engineers. Rails n00bs would
probably make a lot of mistakes that clash with the framework and
compromise its scalability.
He also has a point about his wait-and-see attitude wrt Rails. Rails development
is moving quickly, and in a year's time the major issues like unicode support,
deployment, support ecosystem (tools, etc.) and performance could be
solved problems.
···
On 9/1/06, Dido Sevilla <dido.sevilla@gmail.com> wrote:
Language Wars – Joel on Software
Actually, despite the fact that I love Ruby a lot, I'm inclined to
partially agree with him on this.
I find it amusing that he says Rails is too risky and new, yadda
yadda, but then he goes on to talk about their in-house language,
"Wasabi":
"Wasabi, a very advanced, functional-programming dialect of Basic with
closures and lambdas and Rails-like active records that can be
compiled down to VBScript, JavaScript, PHP4 or PHP5."
So Rails is too risky, but inventing your own language isn't? Did
someone say "not invented here" ??
Also, I could see how looking at unicode in Rails could scare large
enterprise apps, but the scaling and slowness thing is just FUD.
- Rob
···
On 9/1/06, Dido Sevilla <dido.sevilla@gmail.com> wrote:
Language Wars – Joel on Software
Actually, despite the fact that I love Ruby a lot, I'm inclined to
partially agree with him on this. Presently, our company does have
some Rails-based web applications deployed but they're predominantly
applications geared for use by only a few people (internal client use
only); we've not yet tried to deploy a real public-facing web
application based on Rails. For that, it works really well. We're
taking a wait and see attitude before we attempt to use Rails for any
high load applications; my own experiences attempting to optimize
plain Ruby code for performance have been simultaneously frustrating
and rewarding. I doubt I could do the same with a Rails app. So for
now we're gonna stick with PHP for our public facing web applications,
even if it is even worse for i18n/l10n/m17n applications than Ruby
is...
--
and rewarding. I doubt I could do the same with a Rails app. So for
now we're gonna stick with PHP for our public facing web applications,
even if it is even worse for i18n/l10n/m17n applications than Ruby
is...
An interesting performance test is to take some task and implement it in Rails or Nitro or IOWA or Camping or whatever, and then implement it in a PHP framework with equivalent functionality.
I have done some of this using CakePHP, which is a reasonably good PHP web development framework, and the results are interesting. While PHP will benchmark faster than Ruby for isolated benchmark tasks, when one starts looking at frameworks with equivalent capabilities, PHP loses that performance advantage, at least in the limited testing that I have done so far.
Kirk Haines
Language Wars – Joel on Software
Actually, despite the fact that I love Ruby a lot, I'm inclined to
partially agree with him on this. Presently, our company does have
some Rails-based web applications deployed but they're predominantly
applications geared for use by only a few people (internal client use
only); we've not yet tried to deploy a real public-facing web
application based on Rails. For that, it works really well.
If anything, your hitherto positive expeirence should cast an
optimistic outlook for Rails' performance in a wider-audience
application.
high load applications; my own experiences attempting to optimize
plain Ruby code for performance have been simultaneously frustrating
and rewarding. I doubt I could do the same with a Rails app.
Rails performacne optimization is very different from Ruby
optimization. There's only so much you can to optimize Ruby for simple
operations. Web applications, however, are usually complex. Solving or
even merely identifying bottlenecks involves making and testing broad
changes rapidly. And that's where Ruby/Rails really shines.
There are many significant optimizations I was able to discover and
implement in Rails, that I simply wouldn't be able to do in PHP
because of its less modular and malleable nature. In fact, I think
VHLLs like Ruby (in conjuction with appropriate frameworks like Rails)
have a solid advantage there over lower level languages, and this edge
will only increase in the future.
So for
now we're gonna stick with PHP for our public facing web applications,
even if it is even worse for i18n/l10n/m17n applications than Ruby
is...
The first steps I took in Rails were rewriting existing PHP
applications with it. So I have a certain estimate about how the Rails
compares to PHP for very similar applications. Keep in mind those
initial translations were completely naive; I didn't know Rails at the
time, and I didn't do anything like the optimizations mentioned above.
Generally, those naive applications weren't significantly slower than
their PHP equivalents (which themselves were old, tested, optimized
code). At most, the PHP was twice as fast (would handle twice the
requests over the same time period). And that's a maximum estimate -
generally, any difference was hardly noticeable.
In my experience a lot of production PHP applications can be optimized
to at least 2-3 times of their existing performance (and that's
assuming there wasn't really sloppy programming going on, in which
case the gain might easily be many times more). So I don't see why
Rails is any less viable than PHP in that regard. In fact, quite the
contrary: Rails applications I worked on frequently ended up getting
some refactoring after going production, and becoming 2-3 times more
efficient. Refactoring a working PHP application, however, is commonly
such a PITA, I was happy to close the hood after the engine was
running and not bother opening it again unless in the unfortunate
event of a bug.
Regards,
-Alder
···
On 9/1/06, Dido Sevilla <dido.sevilla@gmail.com> wrote:
Dido Sevilla wrote:
Language Wars – Joel on Software
Actually, despite the fact that I love Ruby a lot, I'm inclined to
partially agree with him on this. Presently, our company does have
some Rails-based web applications deployed but they're predominantly
applications geared for use by only a few people (internal client use
only); we've not yet tried to deploy a real public-facing web
application based on Rails. For that, it works really well. We're
taking a wait and see attitude before we attempt to use Rails for any
high load applications; my own experiences attempting to optimize
plain Ruby code for performance have been simultaneously frustrating
and rewarding. I doubt I could do the same with a Rails app. So for
now we're gonna stick with PHP for our public facing web applications,
even if it is even worse for i18n/l10n/m17n applications than Ruby
is...
Interesting post Dido 
I have never seen one web project fail due to slow language execution,
yet I have seen many fail because developers boggled down with
complexity, bloat and sluggish time to market!
After a couple of week's worth of work in Perl, people would say "wow
that's totally awesome" but with Java they say "hmmm, is that all"?
Java and C# are no guarantee for success. Sure the production
environments are solid but you cannot ignore the development economics,
you seem to need 10 instead of 3 people and 5 times as long. These are
serious issues!
Ok, sure Java's OO may be nicer than Perl 5's but once you brew
HTML/Javascript/JSP/JSTL/EL/tags/JSF or Struts together the result
isn't exactly what I'd call pretty. Java is in no way a safe bet.
How about C#, well it runs in Windows and without serious and expensive
firewalls you just can't go anywhere near the Internet. Yes .net is
prettier than the java's web stack but there is still way too much to
learn and when the framework doesn't do what you need you're left in
the cold big time. Again .NET is no guarantee to success either.
Ruby and Rails just get straight to the point. They make common things
easy and elegant. If execution speed really is a problem then I reckon
it'll get fixed.
As for developing major sites with Rails, most managers don't have the
balls. They'd rather pay millions to get a java solution, it isn't
their money on the budget so they gutlessly pour it down the java hole
and hope for the best. If the project fails they blame the team or
throw more money and bodies at the problem, of course it's not java's
fault or theirs.
Anyway I don't hold prejedice again java or c# but they are in no way a
safe bet.
Cheers.
In the context of the enterprise, I agree too. But only in the sense that 'safe' implies availability of skills, and perhaps tools to some extent. IMO, Ruby and Rails are 'safe' in the sense that they have longevity, which I think would be the next biggest concern of enterprise users.
···
On 1 Sep 2006, at 14:00, Yukihiro Matsumoto wrote:
Actually, I agree with his conclusion:
that's not a safe choice for at least another year or six. that's not
a safe choice for at least another year or six.He is a businessman, not a geek, so he does not have to risk himself
using Ruby (and Rails). It doesn't matter. He will not pay me
anything even if he choose Ruby.
I too found that beyond ironic.
James Edward Gray II
···
On Sep 1, 2006, at 9:20 AM, Rob Sanheim wrote:
I find it amusing that he says Rails is too risky and new, yadda
yadda, but then he goes on to talk about their in-house language,
"Wasabi":
Rob Sanheim wrote:
So Rails is too risky, but inventing your own language isn't? Did
someone say "not invented here" ??
Where would be but for Not Invented Here?
···
--
James Britt
http://www.ruby-doc.org - Ruby Help & Documentation
Ruby Code & Style - The Journal By & For Rubyists
http://www.rubystuff.com - The Ruby Store for Ruby Stuff
http://www.jamesbritt.com - Playing with Better Toys
I find it amusing that he says Rails is too risky and new, yadda
yadda, but then he goes on to talk about their in-house language,
"Wasabi":
So Rails is too risky, but inventing your own language isn't? Did
someone say "not invented here" ??
Yes, *Joel* did. He makes quite a strong case for it:
"in defense of not-invented-here syndrome"
Also, I could see how looking at unicode in Rails could scare large
enterprise apps, but the scaling and slowness thing is just FUD.
The unicode issue is scary to an enterprise mindset, where having
a valid unicode mechanism that is 'non-unicode centric' still qualifies
as 'unicode antipathy'. The enterprise mindset has become happy
with the fact that unicode support is one of those things that they
don't have to think about in the languages/frameworks they favour.
The scaling/slowness thing though I can kind of understand (the
concern that is). I get
the feeling that Rails performs properly when you stick to the promoted
model, but if you deviate from it (processing too much, rather than
using the stack properly) you can choke your performance. Other
languages are probably more forgiving in this respect.
Don't forget the original context of Joels post: "Which web technology
would you bet your company on" (and by implication you house &
savings and whatever other assets you have used to get capital)
···
On 9/1/06, Rob Sanheim <rsanheim@gmail.com> wrote:
Yukihiro Matsumoto wrote:
Hi,
(2) Although Ruby runs slower than other languages in those
micro-benchmarks, real bottleneck in the most application lies in
either network connection or databases. So we don't have to buy 5
times as many boxes.
Allow me to rant on what we performance engineers do for a living ... 
Most web applications I've encountered are not engineered for
performance -- *ever*. There's this little slogan they teach
programmers, which I've heard repeated numerous times on this list:
Beware premature optimization.
As a performance engineer, I don't consider premature optimization a
sin, of course. But leaving that aside, what it translates to is "make
it work, then make it pretty, then deploy it." Once it's deployed, it's
faster to "throw hardware at it" than it is to do the performance
optimization aka performance *re-engineering*.
Incidentally, the person who coined that slogan, Edsger W. Dijkstra,
said also that programming should separate the concerns of correctness
and efficiency. He *never* said to *only* worry about correctness. Part
of the discipline of programming is to pay attention to the efficiency
in equal measure to the correctness. That somehow seems to have been lost.
OK ... on with the rant:
1. Those of you who claim to be doing "test-driven development": If
performance testing isn't part of your test-driven development, you
aren't *really* doing test-driven development.
2. Micro-benchmarks are important. A few weeks ago, I ran and profiled a
micro-benchmark on "Matrix", which I posted to the YARV mailing list and
on my RubyForge project page. It's four times as fast in YARV as it is
in Ruby 1.8.5.
Whether it's YARV or some other low-level implementation techniques
really isn't important. What *is* important is that the Ruby "inner
interpreter", to borrow a term from Forth, *must* be as fast as it can
be given the other design constraints like compilers and portability.
The way to achieve this is with profiling on micro-benchmarks.
3. The future of "throw hardware at it" is multi-core processors and
storage array networks (SANs). If you aren't designing your applications
to take advantage of multi-processors, or if you aren't paying attention
to the "lower-level" I/O characteristics of your applications, they're
going to throw hardware at someone else's code.
Speaking of throwing hardware at it, there are ways to know what *kind*
of hardware to throw at it. Learn them.
4. An application with a network bottleneck is very often poorly
designed. One of the goals of performance engineering is *minimizing*
the amount of traffic between the client and the server.
Of course, if you're streaming audio, displaying high-definition video,
etc., the network traffic *is* the application, but an on-line banking
application should *not* have to send back more than a couple of
kilobytes to confirm that I've made a payment.
5. Database "bottlenecks": Most of the "industrial strength" databases
-- Oracle, PostgreSQL, MySQL, SQL Server 2005, DB2, etc. -- are
co-optimized with the operating systems and the platform hardware.
They've done their homework; they've done their performance engineering,
profiling and micro-benchmarking.
As good as they are, a poorly engineered database schema can make the
RDBMS work much harder than it needs to, requiring more hardware than is
necessary.
Yukihiro Matsumoto wrote:
> (2) it's known to be slow, so if you become The Next MySpace, you'll
> be buying 5 times as many boxes as the .NET guy down the hall.
(2) Although Ruby runs slower than other languages in those
micro-benchmarks, real bottleneck in the most application lies in
either network connection or databases. So we don't have to buy 5
times as many boxes.
Agreed. I manage engineering at Edgeio (http://www.edgeio.com/\). We
don't use Rails, but we do use Ruby extensively on our _backend_. All
of our backend was initially written in C++, but I decided to start
migrating it to Ruby because:
1) It massively cut complexity. As an example I replaced a very
primitive, simple messaging middleware system with 700 lines of Ruby
that was significantly more advanced. Adding the same features to the
C++ version would easily have brought it to 3000-4000 lines of code.
More importantly, it took less time to write the Ruby version than to
write the much more primitive C++ code. And that system was my first
ever Ruby app, while I've been doing C/C++ for more than 10 years.
2) We hardly ever max out CPU's. We _can't_ buy boxes with slow enough
CPU's to make it become an issue for most of our servers. The messaging
middleware app handles millions of messages per day and rarely takes up
10% of a single CPU on the servers it runs on.
3) Most of the CPU time used by our Ruby apps is spend waiting for IO.
For the messaging middleware server, a conservative estimate is that
about 80% of the time is spent _in the kernel_ in read() or write()
syscalls. So even assuming that we could get a 10 times speedup of the
code we have written from moving the code back to C/C++, that would
only translate to a reduction in CPU use from 10% to 8.2% (reducing
time spent in userspace from 2% to 0.2%). Heck, even a 100 times
speedup of the userspace code would still only reduce the CPU use from
10% to 8.02%...
4) Servers are cheap. Engineers are not. A relatively senior engineer
easily costs USD 8k-12k a month (salary+social costs). A single
man-month of wasted effort could buy me a lot of extra processing
power.
5) When we scale, the limitations we run into are from most to least
important: disk io capacity, memory, network latency, cpu. Optimizing
algorithms to minimize disk writes, minimize memory usage (granted,
this is an area were we have to be careful with Ruby) and minimize
latency are all more important than reducing cpu usage. As a result,
because we'll generally have to buy/lease more servers based on io
capacity and memory, we have a lot of wasted CPU capacity. For _most_
(not all) of our backend code, spending time speeding up the code would
not save us anything.
6) IF/when we have to rewrite things in C/C++ to speed it up at any
time, it'll still be far more effective to translate small, isolated
parts of working, well tested Ruby code directly and create extensions
of them, than to write the whole apps as C/C++.
Vidar
···
In message "Re: Joel Spolsky on languages for web programming" > on Fri, 1 Sep 2006 20:30:02 +0900, "Dido Sevilla" <dido.sevilla@gmail.com> writes:
Sure it is. You'll (almost) never have to fear for your job based on a
decision to go with Java or a Microsoft "solution", even if it is
entirely the WRONG decision. You could cost the company millions, end
up getting dozens of people laid off, and tank the entire project, but
if the language by which you did so is Java or C# you may still have job
security (as long as you haven't made other high-profile bad decisions).
The problem with job security in that circumstance only really arises if
there was a bitter power struggle over whether to go with Java or .NET,
and your side "won", then the project tanked at a cost of millions. The
opposing "side" might just blame the language/framework decision.
On the flipside, even where from a technical standpoint it's almost
impossible to avoid thinking something like Ruby on Rails, or Perl's
Catalyst, or Python's Django, is the best option, you may well find
yourself losing a job even if you made the right decision and the
project was well on its way to being a howling success. All it takes is
a poorly-timed change in management structure, and they may junk all the
work that has already been done at a cost of millions to rewrite
everything in Java or C# (or, God forbid, VB.NET), and fire you and all
your buddies for doing great work very quickly in the "wrong" language.
Corporate politics. Whee.
···
On Sun, Sep 03, 2006 at 07:15:32AM +0900, Alvin Ryder wrote:
As for developing major sites with Rails, most managers don't have the
balls. They'd rather pay millions to get a java solution, it isn't
their money on the budget so they gutlessly pour it down the java hole
and hope for the best. If the project fails they blame the team or
throw more money and bodies at the problem, of course it's not java's
fault or theirs.Anyway I don't hold prejedice again java or c# but they are in no way a
safe bet.
--
CCD CopyWrite Chad Perrin [ http://ccd.apotheon.org ]
Ben Franklin: "As we enjoy great Advantages from the Inventions of
others we should be glad of an Opportunity to serve others by any
Invention of ours, and this we should do freely and generously."
Utter pants. I mean, you used the word "bloat", which should make people lose any debate by default.
Alvin Ryder wrote:
Java and C# are no guarantee for success.
Neither is Ruby / Rails. *No technology* is a guarantee for success, no technology ever was, and I'll bet a gold bar against a plastic spoon no technology ever will. Technology used is a very important decision to make, but it never single-handedly moves you from doable to undoable or vice versa.
you seem to need 10 instead of 3 people and 5 times as long.
Pure, unadulterated shite. Give me numbers. Credible statistics and real research, not random anectodal success stories that are too pathethic to sell Herbalife diet pills.
Also, initial development cost isn't a very important factor. Recalls your uni software lifecycle charts about how much of a project's life is maintenance. For a successful project, the numbers are very much true. With a successful product comes the responsibility of supporting it and keeping it successful, and in some cases this responsibility creates ongoing costs that dwarf the initial development horribly.
Ok, sure Java's OO may be nicer than Perl 5's but once you brew
HTML/Javascript/JSP/JSTL/EL/tags/JSF or Struts together the result
isn't exactly what I'd call pretty. Java is in no way a safe bet.
Noone cares about pretty. It's also a completely irrelevant issue when deciding on implementation language if you're at least remotely responsible.
How about C#, well it runs in Windows and without serious and expensive
firewalls you just can't go anywhere near the Internet.
You need to tighten off Unix-based servers too. Heck, there are even serious and expensive firewalls for Linux around too, because not everyone has an in-house iptables guru.
Ruby and Rails just get straight to the point. They make common things
easy and elegant.
Sometimes things aren't so common. Ruby and Rails DO have faults. Just google around, I'm not going to go namecall out of respect and out of a sense of realism - every technology has flaws and any mudslinging would only lead to a pointless flamewar. Sometimes they are uneducated rants and / or whining, but some of them are valid.
And if you do NOT go out and learn about these flaws, and what impact they could have, and be fully aware of them when making the implementation technology decision on a project to consider the severity of their impact under the circumstances of your project, then your decision may cause a lot of trouble.
> If execution speed really is a problem then I reckon
> it'll get fixed.
Speaking purely theorethically, Ruby can not be made as performant as Java or C# could be made if they had ideally performing implementations. Latent typing makes it almost impossible to do certain optimizations as static typing does. That's pure fact. Of course, it's not saying Ruby can't be fast enough - but there have been people with more experience at the performance side of software development that talked much better about that
As for developing major sites with Rails, most managers don't have the
balls.
I advise you go on throught freshman year on a management school. It's the managers' job to "not have balls" and risk when there's apparently nothing to be had from taking it. If you want to be a Ruby advocate, you need to be able to persuade them, not yourself, of the advantages or using it.
They'd rather pay millions to get a java solution, it isn't
their money on the budget so they gutlessly pour it down the java hole
and hope for the best. If the project fails they blame the team or
throw more money and bodies at the problem, of course it's not java's
fault or theirs.
That's because it's not. Since projects never fail purely on a technology solution - they fail on results of bad project planning more often than not (assigning novice programmers to large projects that will probably go over their heads), mistaken business objectives as whoever contracted the software finds he isn't really interested in what the tech demos had to show at all.
And the stereotype of lazy management that never gets punished is good to make Dilbert strips from - in real life, it probably doesn't hold true outside of a select few huge moloch companies, or on the opposite side of the spectrum small short-lived hick-led shops where the bosses kids and nephews gets all sort of crap assigned to get better allowance. In a well-led company with working internal management processes, when the shit hits the fan, everyone gets the stink.
David Vallner
In the context of the enterprise, I agree too. But only in the sense
that 'safe' implies availability of skills, and perhaps tools to some
extent. IMO, Ruby and Rails are 'safe' in the sense that they have
longevity, which I think would be the next biggest concern of
enterprise users.
There is another take on what's risky and what's safe:
Regards,
Rimantas
···
Hi,
···
In message "Re: Joel Spolsky on languages for web programming" on Fri, 1 Sep 2006 23:28:09 +0900, James Edward Gray II <james@grayproductions.net> writes:
On Sep 1, 2006, at 9:20 AM, Rob Sanheim wrote:
I find it amusing that he says Rails is too risky and new, yadda
yadda, but then he goes on to talk about their in-house language,
"Wasabi":I too found that beyond ironic.
That indicates that he trusts himself, and not me (Ruby). And I think
he's right.
matz.
Well, to be fair, it's not quite that.
Start with The Road to FogBugz 4.0: Part III – Joel on Software --
they had a VBScript app and it needed to be on PHP. So they wrote
a VBScript to PHP compiler.
Good choice, given the market pressures.
Three years later, they've extended that compiler a little in the
direction of a FogBUGZ specific DSL and given it a silly name.
Not particularly surprising, nor particularly relevant to language
debates.
Bill
James Edward Gray II wrote:
···
On Sep 1, 2006, at 9:20 AM, Rob Sanheim wrote:
I find it amusing that he says Rails is too risky and new, yadda
yadda, but then he goes on to talk about their in-house language,
"Wasabi":I too found that beyond ironic.
James Edward Gray II
On second though, maybe Joel was just trolling a bit here? Maybe just
a bit of an in-joke, knowing that the bloggers would go nuts about the
obvious contradiction?
It seems to nutty to be true...
- rob
···
On 9/1/06, James Edward Gray II <james@grayproductions.net> wrote:
On Sep 1, 2006, at 9:20 AM, Rob Sanheim wrote:
> I find it amusing that he says Rails is too risky and new, yadda
> yadda, but then he goes on to talk about their in-house language,
> "Wasabi":I too found that beyond ironic.
James Edward Gray II
--
It seems to me that Joel has accused us of having too much *fun* with
Ruby and with Rails. Way too much. And we all know that fun can't
possibly go hand in hand with productivity and *real* business.
-- Mike Berrow
···
--
Posted via http://www.ruby-forum.com/.