Another Reason Why Enterprises Don't Like Dynamic Languages
Again, I'm trying to get a handful of our developers to look at different approaches and languages to develop applications. We have many, internal applications that the customer never sees but, still get used by thousands of employees all the time throughout the day. Recently, we identified a new series of apps we need to build and instead of using a heavyweight framework plus Java, I suggested something a lot more lightweight and more suited to rapid development since these applications don't need to be engineered to the same tolerances as our customer-facing applications do. Again, I have to bring up scalability.
When I need to run applications in crowded, power-constrained data centers, every CPU cycle counts. Supporting thousands of simultaneous users takes a lot of boxes, even more so when I have to consider performance numbers like these. Ruby zealots should be particularly embarrassed; the language has been out almost as long as Python and that's the best it can do? And as for Smalltalk, at least make a middle-aged language go as fast as that other middle-aged language: Lisp. I'd even be more confident recommending Smalltalk if it were as zippy as C# Mono. Sure, we enterprisey types are the target of a lot of cheap shots (and even get a rare chance to take one) but, when a new data center costs $25 million to build and we have to consider the cost of power in KWhs where pennies make a big difference, feature development time becomes irrelevant vs. the year-over-year operating cost of those apps on a large scale.
When I try to take a stand and be a voice for change in the face of hundreds (literally!) of C++ and Java developers who have a need for speed, benchmark results like the ones at the end of the URL, above, don't help my case at all. It pretty much gets me and your favorite language laughed right out of the room. Add to that the the typical software developers' stubborn and irrational resistance against trying something new, and the battle is pretty much lost from the start. It's actually very frustrating and discouraging.
Addendum: Many thanks to "keith" for showing me the way to ST/X which, after reading the docs, looks to be exactly what I'm looking for with regards to performance.
Posts
3 comments:
Here's the main thing: Your internal app won't have anything like the scaling needs that Twitter does, and the Twitter crew have kept that up (it's written in Ruby). If you think you need the same level of scaling, then you aren't paying attention...
Enterprise = All applications
I'm referring to our B2C and B2B applications, not the ones behind the firewall that only employees see.
(Caveat - I'm one of the great many large-scale ex-Perl programmers who don't yet have large-scale experience on Ruby. But by large-scale, I mean millions of customers, not tens of thousands.)
Part of the reason that Enterprisey types are targets may be that those of us on the Perl/Ruby side of the fence see numbers like "thousands" and wonder why that's considered a scaling problem. Anyone can scale anything to thousands of users - we used to joke that our cat's appointment calendars needed that kind of performance. Myspace scaled ColdFusion (much to everyone's astonishment and horror...).
We've also seen Java rearchitecting projects turn into fiascos; very, very good Java teams can turn out very, very good code. The same is true on the Perl side. But mediocre development teams? Java is far easier to do badly, in my experience, and doing the same thing in a bloated Java environment is much more expensive and hard to scale than the equivalent in Perl.
Look at the big sites and ask yourself how many of them use what you normally think of as Enterprise tools. Certainly not Yahoo, Google, Amazon. Ebay uses Java, but they're not big users of the standard enterprise Java toolsets. IMHO, "enterprisey" means small and medium size environments, with at most hundreds of thousands of users.
Post a Comment