# Joel Spolsky on languages for web programming **URL:** \ **Category:** ruby-talk\ **Created:** [1 September 2006 11:30 UTC](https://rubytalk.org/t/joel-spolsky-on-languages-for-web-programming/30561 "2006-09-01T11:30:02Z")\ **Posts on this page:** 20\ **Page:** 1
**Author:** ![Dido\_Sevilla](https://avatars.discourse-cdn.com/v4/letter/d/9dc877/32.png) [@Dido\_Sevilla](https://rubytalk.org/u/Dido_Sevilla)\ **Post date:** [1 September 2006 11:30 UTC](https://rubytalk.org/t/joel-spolsky-on-languages-for-web-programming/30561/1 "2006-09-01T11:30:02Z")
> **[Language Wars](https://www.joelonsoftware.com/2006/09/01/language-wars/)** > > An old friend emailed me to ask: “I wanted to get your response to some basic questions concerning technologies available for creating an enterprise level application that is built upon a Web… 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... ---
**Author:** ![Yukihiro\_Matsumoto2](https://avatars.discourse-cdn.com/v4/letter/y/b9e5f3/32.png) [@Yukihiro\_Matsumoto2](https://rubytalk.org/u/Yukihiro_Matsumoto2)\ **Post date:** [1 September 2006 13:00 UTC](https://rubytalk.org/t/joel-spolsky-on-languages-for-web-programming/30561/2 "2006-09-01T13:00:25Z")
Hi, > [Language Wars – Joel on Software](http://www.joelonsoftware.com/items/2006/09/01.html) 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" \ writes: ---
**Author:** ![Richard\_Conroy1](https://avatars.discourse-cdn.com/v4/letter/r/57b2e6/32.png) [@Richard\_Conroy1](https://rubytalk.org/u/Richard_Conroy1)\ **Post date:** [1 September 2006 13:14 UTC](https://rubytalk.org/t/joel-spolsky-on-languages-for-web-programming/30561/3 "2006-09-01T13:14:33Z")
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 \ wrote: > > > [Language Wars – Joel on Software](http://www.joelonsoftware.com/items/2006/09/01.html) > > > > Actually, despite the fact that I love Ruby a lot, I'm inclined to > > partially agree with him on this. ---
**Author:** ![Rob\_Sanheim1](https://avatars.discourse-cdn.com/v4/letter/r/7ea924/32.png) [@Rob\_Sanheim1](https://rubytalk.org/u/Rob_Sanheim1)\ **Post date:** [1 September 2006 14:20 UTC](https://rubytalk.org/t/joel-spolsky-on-languages-for-web-programming/30561/4 "2006-09-01T14:20:32Z")
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 \ wrote: > > > [Language Wars – Joel on Software](http://www.joelonsoftware.com/items/2006/09/01.html) > > > > 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... > > -- > > > **[Home](https://robsanheim.com/)** > > > > Just another WordPress site > > > **[Stock Market Analysis & Tools for Investors](https://seekingalpha.com/)** > > > > Join Seeking Alpha, the largest investing community in the world. Get stock market news and analysis, investing ideas, earnings calls, charts and portfolio analysis tools. > > > **[Purchase Intent Data for Enterprise Tech Sales and Marketing | TechTarget](https://www.techtarget.com/)** > > > > Identify, influence and engage active buyers in your tech market with TechTarget's purchase intent insight-powered solutions. Activity matters. ---
**Author:** ![Kirk\_Haines](https://avatars.discourse-cdn.com/v4/letter/k/c6cbf5/32.png) [@Kirk\_Haines](https://rubytalk.org/u/Kirk_Haines)\ **Post date:** [1 September 2006 14:39 UTC](https://rubytalk.org/t/joel-spolsky-on-languages-for-web-programming/30561/5 "2006-09-01T14:39:36Z")
> 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 ---
**Author:** ![Alder\_Green](https://avatars.discourse-cdn.com/v4/letter/a/db5fbb/32.png) [@Alder\_Green](https://rubytalk.org/u/Alder_Green)\ **Post date:** [2 September 2006 13:53 UTC](https://rubytalk.org/t/joel-spolsky-on-languages-for-web-programming/30561/6 "2006-09-02T13:53:59Z")
> [Language Wars – Joel on Software](http://www.joelonsoftware.com/items/2006/09/01.html) > > 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 \ wrote: ---
**Author:** ![Alvin\_Ryder](https://avatars.discourse-cdn.com/v4/letter/a/67e7ee/32.png) [@Alvin\_Ryder](https://rubytalk.org/u/Alvin_Ryder)\ **Post date:** [2 September 2006 22:15 UTC](https://rubytalk.org/t/joel-spolsky-on-languages-for-web-programming/30561/7 "2006-09-02T22:15:32Z")
Dido Sevilla wrote: > [Language Wars – Joel on Software](http://www.joelonsoftware.com/items/2006/09/01.html) > > 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. ---
**Author:** ![Derek\_Chesterfield1](https://avatars.discourse-cdn.com/v4/letter/d/e56c9b/32.png) [@Derek\_Chesterfield1](https://rubytalk.org/u/Derek_Chesterfield1)\ **Post date:** [1 September 2006 13:41 UTC](https://rubytalk.org/t/joel-spolsky-on-languages-for-web-programming/30561/8 "2006-09-01T13:41:29Z")
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. ---
**Author:** ![James\_Edward\_Gray\_II](https://avatars.discourse-cdn.com/v4/letter/j/ea5d25/32.png) [@James\_Edward\_Gray\_II](https://rubytalk.org/u/James_Edward_Gray_II)\ **Post date:** [1 September 2006 14:28 UTC](https://rubytalk.org/t/joel-spolsky-on-languages-for-web-programming/30561/9 "2006-09-01T14:28:09Z")
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": ---
**Author:** ![James\_Britt3](https://avatars.discourse-cdn.com/v4/letter/j/b782af/32.png) [@James\_Britt3](https://rubytalk.org/u/James_Britt3)\ **Post date:** [1 September 2006 14:53 UTC](https://rubytalk.org/t/joel-spolsky-on-languages-for-web-programming/30561/10 "2006-09-01T14:53:24Z")
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](http://www.ruby-doc.org) - Ruby Help & Documentation > [Ruby Code & Style](http://www.artima.com/rubycs/) - The Journal By & For Rubyists > [http://www.rubystuff.com](http://www.rubystuff.com) - The Ruby Store for Ruby Stuff > [http://www.jamesbritt.com](http://www.jamesbritt.com) - Playing with Better Toys ---
**Author:** ![Richard\_Conroy1](https://avatars.discourse-cdn.com/v4/letter/r/57b2e6/32.png) [@Richard\_Conroy1](https://rubytalk.org/u/Richard_Conroy1)\ **Post date:** [1 September 2006 15:44 UTC](https://rubytalk.org/t/joel-spolsky-on-languages-for-web-programming/30561/11 "2006-09-01T15:44:36Z")
> 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" > **[In Defense of Not-Invented-Here Syndrome](https://www.joelonsoftware.com/2001/10/14/in-defense-of-not-invented-here-syndrome/)** > > Time for a pop quiz. 1. Code Reuse is: a) Goodb) Bad 2. Reinventing the Wheel is: a) Goodb) Bad 3. The Not-Invented-Here Syndrome is: a) Goodb) Bad Of course, everybody knows that you should always… > 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 \ wrote: ---
**Author:** ![M\_Edward\_Ed\_Borasky1](https://avatars.discourse-cdn.com/v4/letter/m/e9c0ed/32.png) [@M\_Edward\_Ed\_Borasky1](https://rubytalk.org/u/M_Edward_Ed_Borasky1)\ **Post date:** [1 September 2006 18:00 UTC](https://rubytalk.org/t/joel-spolsky-on-languages-for-web-programming/30561/12 "2006-09-01T18:00:58Z")
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. ---
**Author:** ![Vidar\_Hokstad1](https://avatars.discourse-cdn.com/v4/letter/v/8e8cbc/32.png) [@Vidar\_Hokstad1](https://rubytalk.org/u/Vidar_Hokstad1)\ **Post date:** [2 September 2006 11:10 UTC](https://rubytalk.org/t/joel-spolsky-on-languages-for-web-programming/30561/13 "2006-09-02T11:10:33Z")
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/\](http://www.edgeio.com/%5C)). 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" \ writes: ---
**Author:** ![Chad\_Perrin1](https://avatars.discourse-cdn.com/v4/letter/c/977dab/32.png) [@Chad\_Perrin1](https://rubytalk.org/u/Chad_Perrin1)\ **Post date:** [2 September 2006 23:56 UTC](https://rubytalk.org/t/joel-spolsky-on-languages-for-web-programming/30561/14 "2006-09-02T23:56:35Z")
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](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." ---
**Author:** ![David\_Vallner](https://avatars.discourse-cdn.com/v4/letter/d/eb9ed0/32.png) [@David\_Vallner](https://rubytalk.org/u/David_Vallner)\ **Post date:** [3 September 2006 16:01 UTC](https://rubytalk.org/t/joel-spolsky-on-languages-for-web-programming/30561/15 "2006-09-03T16:01:14Z")
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 ---
**Author:** ![Rimantas\_Liubertas](https://avatars.discourse-cdn.com/v4/letter/r/e8c25b/32.png) [@Rimantas\_Liubertas](https://rubytalk.org/u/Rimantas_Liubertas)\ **Post date:** [1 September 2006 14:07 UTC](https://rubytalk.org/t/joel-spolsky-on-languages-for-web-programming/30561/16 "2006-09-01T14:07:28Z")
> 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: > **[From Java to Ruby: Risk](https://www.infoq.com/articles/From-Java-to-Ruby--Risk/)** > > "Ruby is risky" is a common perception. As Ruby on Rails moves closer to the mainstream, that risk will decrease. In this article, Bruce Tate examines the changing risk profiles for Java and Ruby from a managers perspective, examining Java's initial... Regards, Rimantas > **···** > > -- > [http://rimantas.com/](http://rimantas.com/) ---
**Author:** ![Yukihiro\_Matsumoto2](https://avatars.discourse-cdn.com/v4/letter/y/b9e5f3/32.png) [@Yukihiro\_Matsumoto2](https://rubytalk.org/u/Yukihiro_Matsumoto2)\ **Post date:** [1 September 2006 14:36 UTC](https://rubytalk.org/t/joel-spolsky-on-languages-for-web-programming/30561/17 "2006-09-01T14:36:19Z")
Hi, > **···** > > In message "Re: Joel Spolsky on languages for web programming" on Fri, 1 Sep 2006 23:28:09 +0900, James Edward Gray II \ 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. ---
**Author:** ![William\_Grosso](https://avatars.discourse-cdn.com/v4/letter/w/2bfe46/32.png) [@William\_Grosso](https://rubytalk.org/u/William_Grosso)\ **Post date:** [1 September 2006 14:46 UTC](https://rubytalk.org/t/joel-spolsky-on-languages-for-web-programming/30561/18 "2006-09-01T14:46:48Z")
Well, to be fair, it's not quite that. Start with [The Road to FogBugz 4.0: Part III – Joel on Software](http://www.joelonsoftware.com/articles/FogBugzIII.html) -- 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 ---
**Author:** ![Rob\_Sanheim1](https://avatars.discourse-cdn.com/v4/letter/r/7ea924/32.png) [@Rob\_Sanheim1](https://rubytalk.org/u/Rob_Sanheim1)\ **Post date:** [1 September 2006 14:52 UTC](https://rubytalk.org/t/joel-spolsky-on-languages-for-web-programming/30561/19 "2006-09-01T14:52:01Z")
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 \ 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 > > -- > > > **[Home](https://robsanheim.com/)** > > > > Just another WordPress site > > > **[Stock Market Analysis & Tools for Investors](https://seekingalpha.com/)** > > > > Join Seeking Alpha, the largest investing community in the world. Get stock market news and analysis, investing ideas, earnings calls, charts and portfolio analysis tools. > > > **[Purchase Intent Data for Enterprise Tech Sales and Marketing | TechTarget](https://www.techtarget.com/)** > > > > Identify, influence and engage active buyers in your tech market with TechTarget's purchase intent insight-powered solutions. Activity matters. ---
**Author:** ![Mike\_Berrow](https://avatars.discourse-cdn.com/v4/letter/m/f9ae1b/32.png) [@Mike\_Berrow](https://rubytalk.org/u/Mike_Berrow)\ **Post date:** [1 September 2006 14:54 UTC](https://rubytalk.org/t/joel-spolsky-on-languages-for-web-programming/30561/20 "2006-09-01T14:54:27Z")
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/](http://www.ruby-forum.com/). [Next page](https://rubytalk.org/t/joel-spolsky-on-languages-for-web-programming/30561.md?page=2)