Slashdot Mirror
Ruby On Rails Showdown with Java Spring/Hibernate
Paradox writes "Java developer Justin Gehtland recently tried re-implementing one of his web applications in Ruby on Rails instead of his normal Java Spring/Hibernate setup. His analysis of overall performance and application size was startling, to say the least. The Java app's configuration alone was nearly the size of the entire Rails codebase, and Rails application was significantly (15%-30%) faster! At the same time, the Ruby community is abuzz because Ruby is getting a new optimized bytecode compiler for its upcoming 2.0 release. Will Ruby on Rails become even faster as a result?"
...Ruby is getting a new optimized bytecode compiler for its upcoming 2.0 release. Will Ruby on Rails become even faster as a result?
I would assume so, doesn't optimized usually mean faster?
doesn't optimized usually mean faster?
I'd give you an answer, but I haven't been able to fully test out my optimized Gentoo box yet -- it's still compiling.
Just watch, it's impossible to have an intelligent discussion between the two groups.
Is that so, Mr. Poopyhead?
Fifteen to thirty percent faster, and still crushed under the load of Slashdot.
-- This sig is only a test. If this were a real sig it would say something witty. --
It all depends on what you are optimizing for - you can optimize for size, for instance (smaller but slower applications). You can optimize for portability and end up with code that is both slower and larger (but more portable). You can optimize for almost anything you need. Speed is one factor only.
Anyway, in this particular case you may be right.
Beating Java's performance and garrulous xml-based configuration is like shooting dead fish in a barrel.
How much time did it take to develop the site compared to Java?
I ask here because the site is dead, Ruby isn't a magic hammer after all.
Pete
There have been many posts concerning the speed of each and every possible language. Some have gone as far as to link to several studies with nice charts and graphs to conclude that X language is faster or X1 is truly the fastest. You are all wrong.
A laguage, in of itself, cannot be measured by speed. A language is merely a group lexical elements with a particular syntax. That syntax has an associated semantics to it. That is it! It is pointless to compare languages purely on speed.
Now, what we can compare is the implementation of a particular language. For example, we can compare the speed differences between the intel compiler and gcc for the same piece of C code. We might find that in most cases, gcc is slower that the intel compiler. Does this mean that C is slow? No! Now, take the same algorithm and port it to Java. Lets imagine that the Java version was 10x faster. Does this mean Java is inherently faster langauge? NO! It means that the compiler, JIT, and HotSpot implementations are better at tranlating Java source code down to the machine level.
So, in summary, a language by itself should NOT be measure in speed. It should be measured by the following:
Maintainability
Ease of Use
Learning Curve
Clear Semantics
Support
Documentation
Standard APIs
Most often, when languages are compared, you are merely comparing the differences in constants in a language! Lets say we implement the Quick Sort Algorithm in C++ and Python. We will probably find that the C++ version is slightly faster. What does this mean? It means the the implementation of C++ generates fewer constants that the Python Implementation. So, the Python version may be slower, but it is only in constant O(1) differences and in most cases this does not matter! Eliminating extra constants ( in any language ) is stupid when you have chosen the wrong algorithm in the first place! ( such as an order n^3 when it could have been n*log(n) ).
So, what is the moral of this story? Pick the right langauge for the right job. It you are doing advanced GUI development and prototyping, C++ is probably not the way to go ( since it is harder to write fast and correctly ). However, it you are doing low-level real-time I/O where constants do matter, then C/ASM is probably the way to go. After you have chosen he right language for your task, you must choose the right algorithm! Algorithms are the key! Algorithms are the only true way to measure the efficiency on any program in terms of memory and speed.
Article text in full, copied directly from Justin's blog:
So, a few weeks ago I made an offhanded post here about my new-found love for Rails. I'd been skipping off the surface of Ruby for a while, trying to decide if it, or Python, or Groovy, or something else, ought to fill out the empty slot in my tool belt. (I'll save the "why LISP isn't on this list" post for another time.) Rails seemed like an excellent way to put Ruby through a workout, and I had the right sized project to try it out with.
The project itself is not open-source; the client is now and shall remain anonymous. But they are paying me my going rate to do this work, which makes it a commercial Rails project, and it will in the future be installed into some rather large organizations. I can't really say much about what the application's domain is, but I can lay out the general principles of the app.
The application must support multiple users, in the order of 10-100 concurrently. The load isn't particularly high, but the application will be treated like a desktop app (more specifically, a spreadsheet replacement) so it has to be responsive. The application is for managing pieces of a large machine process. There are lots of types of components to be managed, and the relationships between them can be quite complicated. There are no one-to-one relationships in the model, but plenty of one-to-many and many-to-many. In addition to managing the components, the application has to allow for the addition of entirely new categories of components as well as a variety of customizable fields. Finally, the authorization rules call for a breadth of user roles with a complex mapping of permissions to those roles.
I've finally gotten around to running the profiling numbers and doing some comparison between the two systems. I won't spoil the suspense by listing my conclusions up front -- you'll have to scroll through the rest of the post to see them. But, first, let me set the stage: the original application is based on the Java/JSTL/Spring/Hibernate/MySQL stack. I used ACEGI for the security, SpringMVC for the web controller, and was using Hibernate 2.x for the O/RM. To increase performance, I was using the default output caching from SpringMVC and data caching in Hibernate. The re-implementation is in Rails on top of MySQL. The authorization is done through a custom observer and a custom authorization class, which uses a declarative rules file for permission mapping. For performance, I'm using a combination of page caching, action caching, and cache sweepers (observers whose job it is to expire cached pages).
Now, for the comparisons:
Time to Implement
I made a comment about this in the previous posts on the topic, and that comment has been quoted widely out in the wide blogosphere as a classic example of Rails hype. So, let me make it plain: any time you re-write an application, it will go almost infinitely faster because you already have a firm grasp on the problem domain. Such was the case for me in my re-write; we'd spent so much time on the domain model and the database schema that the second time through the application, everything already made perfect sense to me. Any comparison of how long it took to implement one or the other is bogus, since the only fair comparison would be to implement two roughly functionally equivalent projects in the two different stacks and measure the competitive results. Since I have not done that, making statements about how it only took 5 days to re-implement the site are almost meaningless. What I can say is that I had more fun implementing it the second time, but that's just personal preference.
Lines of Code
This one is a lot more interesting. Folks will tell you all the time that there is a running debate about the meaningfulness of LOC comparisons. They're right; there is a running debate. I just think it's moot. For my money, the fewer lines of code I have to write to get a piece of functionality, *as long as those lines are clear in meaning*
Mirror Here.
Language is merely description, implementation is what you can benchmark.
And I also have to say, what we've got here is the single most intelligent AC post in the entire history of Slashdot.
Weaselmancer
rediculous.
I think the crux of the matter is that he was not taking advantage of some of what these java containers offer. Things like queues, soap, RMI, CORBA bindings, remote invocations etc.
The lesson here I think is that unless you plan on running on multiple containers and using asyncronous calls java is overkill.
If you do need those things then ROR won't work at all.
Another thing is that ROR wants you to design the database from scratch to fit it's naming rules. It's not really designed to work with existing databases. For example it can't map the ugly database field names into nice attribute names for your objects. To me that's a pretty big shortcoming.
evil is as evil does
First post!
--
Posted Via JFPB - Java First Post Bot
lexbaby
"Be Brave, Be Loyal, Be True." -- Hawkeye Pierce
Speed is a stupid mesure for web apps. There is nothing easier to scale then webapps in the world. You can cope with any amount of traffic by just throwing more hardware on the problem in a share nothing environment like php, perl or ruby/rails.
Whats interesting is the development speed and thats what the comparison between the java and the rails version highlighted well. For a great analysis look here: weblog
What makes the above link so special are the comments from the java community saying that the two examples are not functionally equivalent. This is really golden because they are really not. The rails version ( which is 3 lines of code ) does everything the java code does plus tons and tons of more things just by taking educated guesses after looking at the SQL schema.
Rails is a remarkable framework and a glimps of what programming will be like in the future. Yarv will just save some hardware costs
--
First they ignore you, then they laugh at you, then they fight you, then you win. -- Gandhi
In addition to that, how well does the ruby implementation scale? My understanding is that a good J2EE implementation is capable of scaling to thousands of clients (one article I read claimed a 250,000 client load), the ruby implementation might start crawling after as little as 50 clients. Turning up a page 125ms faster is more or less meaningless when you can't reach most of your potential customers, and more importantly, after a few start visiting it gets slower and slower. So I'm curious to see what kind of extensive laod testing he did for both implementations. Other important things to consider are how complex his needs are compared to an enterprise and how extensible both implementations are. How exactly did this Joe Schmoe get on the front page of slashdot?
Regards,
Steve
This is all true, but as software developers we tend to use the word "language" loosely to mean, "The syntax, the compiler, the libraries, and the execution environment." So while a language can't be inherently faster than another, some languages have highly efficient, readily available implementations, and others don't.
That's a matter only of constant speedup, assuming that the implementation is competent, and therefore theoretically swamped by the complexity of the algorithm. But if you've implemented the same algorithm using both systems, a constant speedup of 10 is an order-of-magnitude speed improvement. Even with the really, really fast computers we use today that makes a difference to a lot of applications. (And I've used plenty of languages where could get a 10x improvement by switching to a better language.)
In this case there isn't even a single Java environment; there are numerous JVMs out there and I hope they tested several of them before writing the article. (I doubt it, but that's a whole different story.) You're probably not going to get a 10x difference, but 2x wouldn't be uncommon for certain applications.
So you're using the terminology correctly and everybody else is using it wrong. They should talk about the "Java system" or "Java environment" rather than Java language. But I think nearly everybody reading the article knew what was meant.
Justin is a respected and skilled Java developer who's got a Developer's Notebook for Spring set to hit the shelves any day now.
The app he wrote was quite complicated, and he freely admits that Rails got some free jump-starting because of his understanding of the domain. But you're going too far in saying he'd get a 50% speedup from a rewrite. His Java codebase needs work, but not that much work.
He observed that the more complex the action, the faster RoR ran compared to Java. This is very counter-intuitive, so he went into an explanation of why.
Slashdot. It's Not For Common Sense
...without reading TFA, any comment of this sort does not have much value. Maybe if he re-read the article his comment would get a %50 improvement? Maybe his original thoughts were poorly conceived/whatever? This comment MAY be insightful but any comment like this is hardly valuable, that's why I would not even bother to RTFP
Oh please.. Author talks aout line counts and method numbers.. You count getter setter methods? you count the lines for {} symbols and getter-setters? You know that they can be produced lets say in 3 seconds with any modern Java IDE.. it has no meaning what so ever to put them into consideration in terms of productivity.. sigh.
It's a little bit like using something like MS Access. If you play along with MS Access, and don't try and do things that it doesn't do particularly well, then you can actually build desktop database systems very quickly. If you try and go outside of the "Access way", it becomes a quagmire.
There are tens of thousands of sites out there that don't need to have queues, SOAP, RMI etc. They might be someone's list of restaurant reviews or something. Maybe RoR has a good place for that.
Slightly off topic, but thought some might be interested.
There is a pretty cool and full featured MVC framework for PHP called Mojavi. If you like PHP and think Ruby on Rails or any other MVC framework is what you're into, you might want to check it out.
15% - 30% faster! Wow. I hope anyone who ever developed anything for java is reading this so that they can start reimplementing all their code right away.
Another showdown I'd like to read about is that between Rails and Cherrypy. Not in terms of technological superiority, but in terms of marketing skill. Why is the web abuzz with Rails, while Cherrypy is almost unknown.
This isn't flamebait. I'd really want to know how they did it.
http://flosspick.org finding the right open sour
Does this mean the code will be faster?
What does the Slashdot community think about that?
Is this the end of free software?
This whole damn site is a discussion site. What does "What do slasdotters think about this?" add? Especially bad is the monthly article on total cost of ownership or the invalidity of the GPL ending with the "Is this end of FOSS?"
Hibernate seems to be the most hyped technology for webapps on java right now. I evaluated it to use it on my thesis.
.xml file and use them with very few lines of code. It maps the results of the queries to your javabeans. Really simple, but powerful, there's a whole way of doing dynamic queries (i.e, if some object exists, do something with it, else don't)
I don't trust/want something to auto generate my sql tables and such based on my objects. That leads to problems, since the queries can't be tuned or maybe you don't get what you expect.
So, i am using SqlMaps. You put your sql queries in a separate
Disclaimer: i don't have any relationship with sqlmaps, i am just a happy user.
Open Source Java Web Forum with LDAP authentication
Are you serious? I would argue that if there is such a thing as a J2EE "fanboy" (to use a gaming term) then that is an individual who cares only about job security and not about being a good technologist. I'm a developer with 10 years of experience. My experience is in everything from ASP with VB/JScript to PHP to Java. I use whatever the company deems best at the time or whatever I feel is the best solution at the time. I think there is a virtue in being agile and being able to pick up new technologies. The downside is that you don't go as deep. So I don't have 5 years of J2EE on my resume. The upside is that I'm not a J2EE fanboy and if next week my company decides that Ruby is the way to go then I pick up a Ruby book, start poking through the documentation and learn Ruby.
I think J2EE "fanboys" are either too lazy to learn something new, too philosophically rigid to allow for the possibility that there are other ways to accomplish the task at hand or don't, or they're worried that RoR becoming popular would invalidate their 5 years of J2EE experience.
I know people that probably fit this bill in some manner. I would hope for their sake and the sake of their organizations, however, that they'd be willing to pragmatically look at the problem being presented and make a decision based on what's best for the organization, be it Java or Ruby. At the end of the day I believe being a good technologist and a good communicator, being eager to learn and willing to try new things is more valuable than just being a Java wonk. Flexibility is a virtue. I imagine most Java developers are more flexible than you give them credit for. Although I know there are exceptions.
Java as a "dynamic deployment platform", as you put it, offers trivial matters such as load balancing, server-independent sessions, and hot deployment (where new sessions get the new codebase, while old sessions get the old codebase), just to name a few. These three items alone are nearly impossible to pull off in a PHP/MySQL configuration, without keeping your sessions in a database and reloading them for every single pageview. Nearly every Java app server gives you these without having to write any code.
And I think that's where a lot of these pseudo-flamewars get started. On an individual page basis where all I'm doing is "SELECT * FROM NEWS WHERE ID = ?", on one machine, of course PHP and MySQL are going to run faster. But once you start deploying your application to multiple boxes, the advantages of Java become clear.
Additionally, I would challenge you to this test: let's say you have a stock PHP installation, without the GD libraries linked into the PHP binary. Now let's say you want to create a PHP application that uses GD. Do you A) recompile your PHP server, or B) give up platform-independence and run some kind of system call? Under Java, the answer is C) add in a GD jarfile to your application, and you're done, without any recompilation or configuration on your part.
My point, and I do have one, is this: in exchange for the inefficient startup time of the VM and potentially inefficient bytecode (depending on your app server-- Tomcat is a real dog in this aspect) Java gives you a ton of freedom. With hardware getting faster every day, I'll make that tradeoff every single time.
Slashdot. It's Not For Common Sense
Nice FUD... Except that its made up. Rails is very secure by default (uses pepared statements and things like this).
It does whatever it can do to make the framework part of the application secure and even offers a book on security on the hieraki bookshelf for the user side of things: Securing your Rails application .
This is a great example of rails quality documentation. have a look at the bookshelf itself: Hieraki bookshelf
And the application which powers it is open source (MIT) at www.hieraki.org
There was a brief example of this on ONE of the wiki-based tutorials in which the person posting the tutorial didn't use Rails's built in SQL search features or safety features. Because of this, there was an SQL injection hole. It was promptly corrected.
No amount of safety can make up for novice mistakes. Rails provides everything you need to make secure webapps, and it lets you do it painlessly.
Slashdot. It's Not For Common Sense
Some Numbers at Last
So, a few weeks ago I made an offhanded post here about my new-found love for Rails. I'd been skipping off the surface of Ruby for a while, trying to decide if it, or Python, or Groovy, or something else, ought to fill out the empty slot in my tool belt. (I'll save the "why LISP isn't on this list" post for another time.) Rails seemed like an excellent way to put Ruby through a workout, and I had the right sized project to try it out with.
The project itself is not open-source; the client is now and shall remain anonymous. But they are paying me my going rate to do this work, which makes it a commercial Rails project, and it will in the future be installed into some rather large organizations. I can't really say much about what the application's domain is, but I can lay out the general principles of the app.
The application must support multiple users, in the order of 10-100 concurrently. The load isn't particularly high, but the application will be treated like a desktop app (more specifically, a spreadsheet replacement) so it has to be responsive. The application is for managing pieces of a large machine process. There are lots of types of components to be managed, and the relationships between them can be quite complicated. There are no one-to-one relationships in the model, but plenty of one-to-many and many-to-many. In addition to managing the components, the application has to allow for the addition of entirely new categories of components as well as a variety of customizable fields. Finally, the authorization rules call for a breadth of user roles with a complex mapping of permissions to those roles.
I've finally gotten around to running the profiling numbers and doing some comparison between the two systems. I won't spoil the suspense by listing my conclusions up front -- you'll have to scroll through the rest of the post to see them. But, first, let me set the stage: the original application is based on the Java/JSTL/Spring/Hibernate/MySQL stack. I used ACEGI for the security, SpringMVC for the web controller, and was using Hibernate 2.x for the O/RM. To increase performance, I was using the default output caching from SpringMVC and data caching in Hibernate. The re-implementation is in Rails on top of MySQL. The authorization is done through a custom observer and a custom authorization class, which uses a declarative rules file for permission mapping. For performance, I'm using a combination of page caching, action caching, and cache sweepers (observers whose job it is to expire cached pages).
Now, for the comparisons:
Time to Implement
I made a comment about this in the previous posts on the topic, and that comment has been quoted widely out in the wide blogosphere as a classic example of Rails hype. So, let me make it plain: any time you re-write an application, it will go almost infinitely faster because you already have a firm grasp on the problem domain. Such was the case for me in my re-write; we'd spent so much time on the domain model and the database schema that the second time through the application, everything already made perfect sense to me. Any comparison of how long it took to implement one or the other is bogus, since the only fair comparison would be to implement two roughly functionally equivalent projects in the two different stacks and measure the competitive results. Since I have not done that, making statements about how it only took 5 days to re-implement the site are almost meaningless. What I can say is that I had more fun implementing it the second time, but that's just personal preference.
Lines of Code
This one is a lot more interesting. Folks will tell you all the time that there is a running debate about the meaningfulness of LOC comparisons. They're right; there is a running debate. I just think it's moot. For my money, the fewer lines of code I have to write to get a piece of functionality, *as long as those lines are clear in meaning*, the better off I am. Obfuscated Perl programs don't make the
With fastcgi and a decently tuned server, I've heard people getting 1000 req's per second. And lighttpd doesn't take up much memory. And you can always add more applications servers if that's not fast enough.
Dear Moderators,
THIS IS NOT INFORMATIVE. It is INTERESTING. If the poster had supplied supporting evidence at all, it would have been a start towards informative.
As it is:
1. Which tutorial was it?
2. Was the problem a fundamental problem with Ruby on Rails, or the tutorial itself.
3. If it was a problem with Ruby on Rails, can it be fixed?
Improvements in performance and application size are always welcome, but there are some important outside issues to consider when picking a platform for your project.
One is, how deep is the library? With Java or Perl, there are libraries of open-source tools such as Apache Jakarta Commons and CPAN that often mean that with a quick download an enhancement request is 80% done. All new platforms (naturally) have a disadvantage in the department.
Another is, how easy is it to find developers with applicable skills? If an organization commits to Ruby and their Ruby developer leaves, how hard will it be to find a suitable replacement? This is a problem for all platforms except the juggernauts like Java, but especially new platforms. Looking at this another way, a platform choice can be a multi-decade committment. Choose carefully.
So the summary of the summary of the summary is that software development doesn't take place in a vacuum. Ruby is the coolest scripting language ever, but I can't recommend it until I learn more about its library and community.
org.slashdot.post.SignatureNotFoundException: ewg
This article is a good look at RnR(ruby) and Hibernate (java). The author is a java developer and doesn't claim to be a ruby expert, but its interesting analysis about each one.Technical pros and cons of each without a lot of flame bait.
Actually, this is possible. Rails complains the most about having your primary key be something other than the field named "id". A snippet from a recent post on the Rails ML:
:foreign_key => "person_id"
class XXX "Person",
def self.table_name() "YYY" end
def self.primary_key()
"myprimarykey_id"
end
End
So, you can tell active record what the primary key is for each model, and
you can spell out what foreign keys to use for has_many and belongs_to,
etc., as well as what the table name is.
# of clients can be misleading. If it's the number of daily users, it could mean as little as 10 requests/second in an 8 hour day. Just about anything can handle that kind of load. If it's the number of simultaneous connections, then with a gigabit connection you could only serve about half a packet a second to 250000 clients, and I know Java doesn't scale to 250000 simultaneous threads. If they're talking about a horizontal scaling, as in a cluster, then load comparisons becomes almost meaningless without specifying the hardware. Depending on the application, with 10x servers you can usually handle nearly 10x the users, no matter what language you're using.
Notice that Slashdot is written in Perl, with nearly all dynamic pages. According to the FAQ, which may or may not be up to date, they have 8 single processor 600mhz PIII web servers and 1 quad 550mhz xeon MySQL server.
I checked out the video demo at http://media.nextangle.com/rails/rails_setup.mov and I have to admit that I'm pretty impressed. This framework eliminates a lot of the tedium that goes into developing web apps... Here's my problem though... Is there any reason it has to be in Ruby? I've heard of python's equivalent 'subway' ( http://subway.python-hosting.com/ ), and I'm wondering if Ruby has some language feature that makes it inherently more suitable than other languages (like python) for this 'rails-style' of development...
Otherwise, I think I'd just rather stick with Python... It seems to have a bigger and more mature standard library, and I can find more web hosts to support it... I'm not trying to start a language war, I'm just looking for the practical solutions...
Nowhere in the article it is claimed that the "The Java app's configuration alone was nearly the size of the entire Rails codebase".
What is said is that it's the configuration files are nearly the size of the ruby implementation of the example application.
I know that rails makes you write less code but don't over do it.
You should try one of these dynamic languages sometime. You'd be surprised how easily Python or Ruby lets you roll your own messaging systems, simply because they are so easy to work with. You can often roll up a custom solution that exactly matches the domain in less time than it would take to set up a Massive All-Purpose Java solution. I know, I've done it at least twice now.
Does my custom solution do absolutely everything that the Massive All-Purpose Java solution does? No, and that's half the point. I can still add what I need faster than you'd believe.
Normally I'm all about using libraries, but there is a cost to them as well (bending your app to the library's assumptions), and these languages make some things so easy it's not worth it anymore.
The funny thing is you obviously didn't read the article, where the author noted that Java was faster for the less-complicated things but the more complex the pages got the more that Rails kicked ass.
Considering that this guy wrote the Spring: A Developer's Notebook for O'Reilly, I'm inclined to believe that he has a clue when it comes to the Java side of things.
Full disclosure: I don't particularly like the Rails way of doing things with databases, because it bases its data interaction semantics as if MySQL were a good (rather than an "easy") database.
That said:
The assessment on the Rails blog is, I think better. The numbers are impressive but meaningless -- there are tweaks that can be done in any case. The real point is that this shows that Ruby Isn't Slow and that Rails (or any other application environment) can be used in a production environment.
Ni bhionn an rath achx mar a mbionn an smacht (There is no Luck without Discipline)
The first one seems to be in PHP anyway.
(Please browse at -1 to read this comment.)
Sure you can.
In the model for the class:
def first_name
fname
end
There might be a better way to do it, but that works.
I've been meaning to try out some RoR development for a while now, it looks like an incredible language. That being said, I keep thinking of something I read on another forum - don't trust a language until someone can explain to you why it sucks. Right now RoR is in full hype mode, with 100% gushing and not a lot of discussion of its weaknesses, things like that. So that being said, can anyone tell me why RoR sucks?
This is why I gave up on rails. The developers take the attitude of "its your problem, you make sure its secure". No, that's wrong. You are making a web development framework, then YOU make it secure. If you don't read the rails code and find out how things are implimented underneath, then you don't know if your own code is vulnerable to SQL injection or not. That's rediculous, all the rails automatic SQL generation should be safe, you shouldn't expect every user to guess which is the safe way to use rails and which is the unsafe way. And when David dismissed a patch to fix an issue like this "because that would inconvenience people who are using the potentially insecure method securely", I knew he had no business writing software for the web.
I feel the same way about "complement" and "compliment."
You know, I've made a tone of cash begging to differ with this. Perhaps you should ammend that statement to be "There is nothing easier in the world to scale than trivial webapps".
First off, a webapp is not a peice of code on a web server; it is a functional system that does desirable work. Yahoo Search is a web app, but I'd be really impressed if it ran on one server. The front end may be easy enough to scale out, as long as you've figured out how to effectivly manage session handling (either by not using them, having the state kept on a 3rd party system, or assigning a session to always go to one web server).
Now, if we're talking only the front end part, than it makes it a whole lot easier to scale out by throwing money at it. The problem I've always run into is the various resource utilizations on the web server.
If your webapp calls up an application framework and calls up a ton of copies of it, or even just takes up a lot of memory, you run out of it, which now asses a 10,000% penalty on access thanks to swapping. You won't see this if the framework requires a couple megs, and is going to be pooled in some way, but it suddenly gets real interesting when you have hundresd of copies floating around (for whatever reason). When this happens, you now need to know how much of a monetary hit you take to get it to an acceptable level. It may just end up being way too much cash spent to get you to the next level. Then you may have to do it again.
I wound up doing a job that each web app used about a gig of RAM if it ran long enough. I told them to fix the leak. They said the programmer just quit. So we throw money at it. They ran up to 60 web apps on Windows. Guess what.... it would have taken $20,000 and a bunch of downtime to do the upgrades. Once the guy stopped yelling, he realized they were forced to fix the app.
Same priciple applies to anything that hits the disk more than it should, tries to factor large numbers, or tries to download all the Internet porn right now. You run out of something, and have to either see if you can spend money, or fix it so it should have to.
Basically, if you've got a simple app, it's easier to throw hardware/money to scale it. If your app is a large system with complex requirments, it may be possible to do that to an extent, but it's much better to have different tools that may provide much better results.
- Dan
At the Milwaukee No Fluff Just Stuff conference, I was invovled in a lunchtime conversation with Justin and [Pragmatic] Dave Thomas about this subject, just days after Justin completed the Ruby code.
The concensus at that point: it probably wasn't a difference in *execution* speed, but smarter data retreval strategies used by Rails persistance layer. While Hibernate has excellent support for lazy loading, both developers thought that Rails was being *lazier*.
Justin's new numbers also point to faster caching in RoR's persistance layer: while both applications performed about equally without pre-cached data, RoR performed 20x better than the Java stack with cached data [both versions using similar caching strategies].
As for those questioning Justin's java skills: he's one of the best programmer's I've had the privilege to know, one of the best speaker's I've listend to, and is freaking hilarious to boot. He's the co-author of O'Reily's Better, Faster, Lighter Java, and he regularly speaks on advanced Hibernate, Spring, and a bunch of other Java topics.
He also points out a *significant* decrease in Lines of Code[Java:3293 RoR:1164] and Lines of Configuration [Java:1161 RoR:113]. While not an accurate gauge of effort, it is another point in Ruby's favor.
Last point for Ruby: Every single *top notch* Java programmer I know is at least playing with Ruby and RoR, with a large percentage [>50%] transitioning to Ruby as a first choice for new project work.
Don't call it a toy until you've played with it. There's some pretty convincing evidence that Ruby/RoR can beat Java for development effort, and now we're seeing it can beat it for performance, too.
Scott Severtson
Senior Architect, Digital Measures
Speed is important, but not the most important thing. If that were true, then your Browser would not be written in C or C++, but in Assembler.
Yeah, right.
Java is an old man in todays hyper-development environment. Teh old man still has a few tricks up his sleeve though, and he can get the job done. He's just not the upstart he was in his youth.
CS is CS -- there's more to development than language. In 10 years Ruby will be supplanted as well -- and we'll be talking about the NEXT great language.
Face it brother developers, in this profession, we cannot sit around and become complacent. Learning a new language is somethign you should do joyfully. All my pay work in still in Java, and I don't anticipate that changing -- but I thinkI am going ot move some of my pet projects to RoR -- just to see what it's like.
Nothing great was ever achieved without enthusiasm
I earn most of my living writing custom web apps using (usually just part of) the J2EE stack. I love J2EE because it is rock solid - debugged web apps seem to run forever :-)
:-)
That said, I have been working through the fantastic second edition of "Programming Ruby" and I have been using Ruby on Rails. Another great technology for use in my consulting business!
While I understand that it is good for developers to share their experiences as per what works for them and what does not, I think that these J2EE vs. RoR discussions are starting to loose value based on the time spent on them.
Now, to get up to speed on J2EE probably takes several months of dedicated study and lots of experience. Ruby and specifically Ruby on Rails might take a half dozen evenings of study instead of watching TV. If you are a J2EE developer the cost of trying RoR is low. The cost of trying J2EE is much higher.
The choice of platform does not have the impact that design choices make on the success of projects. This is obvious, but: do some up front analysis and then try to use the best tool for a job.
BTW, I have a few open source projects in both Java and Ruby (shameless plug
Rails sucks because its written in ruby, which is slow (excruciatingly slow for recursion and text processing), and doesn't support OS level threads. The fake threads ruby does have can under uncertain circumstances cause the entire interpreter to block.
Rails sucks because David thinks security is your problem, and leaves in functionality that can easily be misused to create a security problem if you haven't read the rails code thoroughly to understand what its doing underneath. Convenience trumps security in rails development.
Rails sucks because its development is incredibly mysql centric, and doing anything beyond the basics with real databases will result in tons of bugs, and then you are told "try again in a few weeks when there's a new version, it should be fixed by then". Then the new version has different bugs instead. Continue this cycle until you decide to use mysql or stop using rails.
That's all I've got, any other problems I've seen are personal preference issues, or things that can easily be fixed as rails matures.
Scaffold is vulnerable, input any data like
and when you see the data it will happily execute that code.
The bug tracking system they use is also full of XSS holes. Browse their database and you risk giving your login/password to anybody.
Even on the tutorials, they teach people to write XSS vulnerable software. From the first tutorial:
The user only has to input
for the title, and presto, he can get all other user's cookies
All the other tutorials have the same vulnerability.
The developers don't care about these. Some people even activelly oppose fixing them. I can only imagine what else is in there. I wouldn't touch ruby on rails with a 10 foot pole for anything where security mattered.
In sixteen years of developing for large-cum-huge organizations, I've found that there is one overriding criterion for EVERYTHING that such companies do: stability.
People who are "fanboys" may just be so invested in [something] that to achieve the same depth of _tested_ knowledge in [something else] would take five years. They may in fact be looking at things like Ruby, but they aren't planning on switching their production development to it until both they and it are seasoned because it would be insane to do so. It's not just THEIR level of comfort that is in question, it is the organizations ability to accept it.
Before someone slams on corporate culture limiting your godlike creative powers, it's actually pretty reasonable. A business is a machine. You want to get some return on the machine before you rip the engine out and retool it--and that timeframe is generally ~5 years. Think of it like buying a car. YOU may be able to afford to replace yours every year or maybe you're a grease monkey who does a frame-off rebuild every spring just for kicks, but the vast majority don't want to go through the hassle and expense on an annual basis.
So, Ruby has now reached the point where it is a serious contender. Expect it to start replacing J2EE somewhere between 2008-2010.
I think there's a good chance this is part of the problem. I assume you meant universities switched from C++ to Java, right? They did locally where I live. I think that's a shame. I'd rather learn something more challenging like C++ as my first language (my first language was C) so that that way I can understand basic concepts of programming at a lower level before moving on to Java, etc.
I think part of this also is what you pointed out, people who went into CS because that's where the money was. For my part I studied English in college. I wrote a lot. I read a large chunk of the classics of post-modern, modern and earlier literature. And then somewhere halfway through college I fell in love with computing. So I bought "Teach Yourself C on the Macintosh" (I think because it was the book in the store that came with a compiler, whereas the Pascal book didn't).
Then when I graduated from college, being a former landscaper, I applied for a couple different jobs. One was as a landscaper. One was for $10 an hour doing HTML, JavaScript, CSS, Photoshop, etc. I got the web job first, so I became a programmer. I didn't seek it out, but rather fell into it and enjoy it enough to keep learning new things.
I think you're right that there is a distinct difference in mindset there. I wasn't looking for a career. I was looking for a job I enjoyed. And all the same I won't fight against new technologies to cling to my newfound career. I could easily be happy doing landscaping if for some reason all the world needs is Java experts. But if they need generalists who love what they do, then I won't be planting trees again for a while.
That's how I look at it.
I wonder how Zope 3 (python web application framework+more) compares to these?
Lodragan Draoidh
The more you explain it, the more I don't understand it. - Mark Twain
Funny, I don't recall JSP templates scanning for javascript and rejecting them. How is this ROR's problem? You get the same thing in JSP, ASP.NET, PHP, and anything that lets you substitute values from the environment.
Oh look, the shell lets me type rm -rf. I better stop shell programming.
The tutorials are sloppy. This doesn't mean Rails is.
I am no longer wasting my time with slashdot
Java Trails is a Java version of RoR. A domain driven collection of tools that allows you to quickly get a CrUD web app up and running. Since it uses Spring, Hibernate, and Tapestry you have complete flexibility to customize code if trails doesn't do what you need.
https://trails.dev.java.net/
Scuttlemonkey is a troll
This whole thing is easily blown out of proportion, in the opinion of the author. Pay attention, people! Use the right tool for the job- all this guy is saying is that in his one instance, he found he was working on a simple project in which the caching of Ruby on Rails worked very well.
Measurable slowness of individual functions in Ruby were overcome by an agressive caching scheme. It's entirely possible that similar or better results could be had in Java, but it would take effort. YMMV. More than a few more comparisons might be needed before you decide to dump Java for Ruby. Think and test. He's just relating a positive experience with a new tool- one which contradicts many people's assumptions about the speed of Ruby as a deployment solution. It's one interesting datapoint, and a fairlly anecdotal one at that... nothing more. I'm definitely not saying it's not significant, but it is what it is, folks shouldn't make it out to be anything more.
So.... I should make my next platform decision based on some guy's blog where he quotes some suspicious looking numbers within some unknown domain space and refuses to open the source code for public scrutiny? The Ruby trolls are really out in full force lately.
Your pizza just the way you ought to have it.
The second post of yours is much more intelligent and much less ignorant and arrogant than your first post. I rolled my eyes when I read your first post.
Depth is far more valuable than breadth, especially in a real corporation. In a real corporation, the objective is to make money, not see how many different disparate technologies can be strewn around and later supported for the next 10-15 or more years. The objective is also to get the job done as quickly and efficiently as possible. If Java does the job better than than Java gets chosen for our enterprise project. If Java and do the job equally well, but we already have a Java programmer and not a programmer, then Java gets chosen. Every minute you spend barely getting deeply involved in a language, such as you claim to do in your first post, makes you more useless to a corporation, not more useful.
From an educational standpoint, I agree than both depth and breadth are of utmost importance. But from a business standpoint, I completely disagree with you.
It does not support Unicode. No unicode strings, no unicode regexps. So if you write your apps with l10n/i18n in mind, Java is still your best choice (or .NET/C# if you're on Windows).
Unicode is expected in v2.0, but nobody knows when it will come out.
Plus, the IDE doesn't support code completion, and having worked with code completion for years now I'm now much less productive without it.
1. I don't believe your SOAP comment is correct. Remember, ROR doesn't provide SOAP per se; it's SOAP4R that does. ROR may provide basic SOAP4R capabilities, but that in no way means that it's using 100% of the features. The ROR team may have decided that the typical use of SOAP with a ROR site is likely to be 25% of the SOAP capabilities. You can *still* do the full SOAP support -- you just have to work a bit harder on it.
s e.html for more information.
2. Yes, but J2EE is an overblown, overladen framework to begin with. When people need queueing and remoting technologies with ROR, it will be added. In fact, the remoting technology -- at least in part -- is already there through DRb (if you haven't looked at it, you should) and Florian Groß's breakpoints code. I would strongly disagree with your assertion that the J2EE components for these are "comprehensive" and especially "unified."
3. Again, you *can* do field name mapping, but it's a bit more work to do so. There's no reason you can't create aliases, e.g.:
def deg_f=(fahrenheit)
write_attribute("celsius", (fahrenheit - 32) * 9 / 5.0))
end
def deg_f
(read_attribute("celsius") * 5 / 9.0) + 32
end
See http://ar.rubyonrails.com/classes/ActiveRecord/Ba
Field name mapping is easy; not as easy as simply following the Rails model, but it's *easy*. SOAP is a bit harder, and other stuff maybe a bit harder still. It's all still easier than trying to pick up all of J2EE.
-austin
Ni bhionn an rath achx mar a mbionn an smacht (There is no Luck without Discipline)
Ruby does not have a canonical IDE, unlike Java.
However, most developers agree they are more productive in languages like Python, Ruby or OCaml than they are in languages that do have auto-complete environments (e.g., C++, Java, C#, etc...).
This shouldn't be taken as a "We don't need no stinkin' code completion" comment. It's just an observation that code completion would be icing on the cake, but the cake is allready there, tasty and full of chocolate.
If you want to try ruby with code completion, check out FreeRIDE. It is not done yet, but it'll show you the direction things are going.
Slashdot. It's Not For Common Sense
I hope this inspires a lot of people to use Rails in demanding production enviornments. That way after they have picked the arrows (if any) out of their backsides, the rest of us can follow along. In all seriousness, I'd be on the rails bandwagon right now if it had a bit more of a track record, and if certain highly specialized java libraries I use were available in ruby.
Post may contain irony: discontinue use if experiencing mood swings, nausea or elevated blood pressure.
To which I'd like to add, "et cetera: et = and, cetera = the rest" . There is no work "eck" in the Latin language, and the phrase "Eck cetera" is nonsense. And you sound stupid if you say it. And, while I'm on the subject, there are two "s"s in the word asterisk. It's not an asterick, even if you verb it.
The fact that bringing ignorance to the attention of the general populace is considered worse than being ignorant itself is a sure sign that we've reached a period of pure intellectual unenlightenment - the second dark ages hath begun. Well, Paradox, let me be the first to stand behind you in solidarity in the battle against stupidity and deliberate ignorance.
Proud neuron in the Slashdot hivemind since 2002.
He asked what sucks about it. I told him. Seriously, nothing is perfect, including your precious rails, get over it. The list is only three items long, you should be proud, not trying to make up excuses.
l s/749/match=sql+injection
I think I formed my opinions before the 0.10.0 release too. I tried what was being hyped as the greatest thing ever. These were the problems. Sorry you don't like it, but that's what I found. There has been no indication of a change in attitude with regards to security:
http://article.gmane.org/gmane.comp.lang.ruby.rai
and a simple scaffolding blows up with the current version of rails for me, so I think clearly the mysql specific issue has not been dealt with sufficiently.
As for speed, benchmark ruby yourself, its recursion is an order of magnitude slower than other languages, PHP being the other language sharing this undesirable trait. And benchmarking rails vs some mess in tomcat doesn't mean anything about rubys performance. Benchmark ruby and java, java is WAY faster. I don't think this is that big of a deal, but you can't deny that this is one of the weaknesses rails has in it, which is what the poster specfically asked for. Everything has its downsides, and wanting to know about them from the start is a pretty smart move.
Trails has been mentioned earlier as the Java copy of RoR. You will probably find the following video pretty interesting -- it demonstrates how quickly one can develop an application with Trails. It is a part of Chris Nelson's weblog.
Rails assumes that each model is one table. In the database, the table can also be a view, but you have to add capabilities in the database to update/insert into that view if you want that functionality.
Mappings should be done in the databases - that's what they are there for.
Whatever you wish to say about 'real corporations' is fine with me. There are many different kinds of working environments in the world. I have no turf to protect and I am neither ignorant nor arrogant.
What I was simply saying is that in your first post you very much sounded like you were bashing people who are intimately in-depth with one particular language. Especially if those people resist learning 20 new languages simply for the sake of having to learn them. That is a waste of everyone's time and money, especially if the project can be accomplished in the language the programmer is most comfortable with and happy using. Not everyone's reason for resistance is 'protecting their turf'. If you are trying to talk specifically about some people who you know, in a very finite view, then that is fine.
Personally, I love to program in Java and would move most of our corporation to the platform if the opportunity were to present itself. In a small generalist corporation, it may be beneficial to have 20 different programming languages being learned on a superficial basis by 20 different people, none of them experts on any one particular field. Generally, but not always, you get what you pay for in the end product with a group of people like that too. You've heard the saying "Good at everything but exceptional at nothing". Like I said, that does not apply to everyone as some people can be absolutely exceptional at anything and everything they want, and those people are exceptional talents, but you get my point. In a much larger corporation, such as the one I currently work at, software goes into production cycles on scales of 10-15 years. In-house talent and support dictates how projects get implemented. A very small, finite number of excellent programming languages, a small group of programming language experts, and reuse and homogenization at every possible step saves not only time but money.
Intelligent people are not just the ones who are the most flexible, but are absolutely the ones who are the most singular and focused on the job at hand. And on top of it, if they are passionate about their work too, then more power to them.
I agree that with your point that learning should never end and that adaptation and flexibility is key to growth. But, you need to learn respect and be understanding of those people who are most in-depth in their work too. On your point about flame-wars being stupid, I completely agree.
I would read the article but the site is down.
My first issue with this is that he uses spring and hibernate and then compares speed. WTF is this about? You use an OR mapping tool that is fairly robust and you then talk about speed? Why didn't he just code all the SQL by hand and forget Hibernate. On a LOT of applications this would perform much better. Heck he could even rip Spring out and again do what he needs by hand.
How much would that have reduced the size?
Now for my next question. How did both applications scale? Where both speeds acceptable at the required load/user level? Heck if you are building a system that you want to maintain, and potentually switch out databases, then Hibernate ROCKS. Yes there is some overhead, but for 99% of the applications on todays hardware this will not be an issue.
The more I learn about science, the more my faith in God increases.
I am not a J2EE fanboy, but I depend on it for my bread and butter. As long as I work within the federal/enterprise development sphere, I will probably depend on it for quite some time. This is because big organizations in the U.S. are standardizing on J2EE, and to some extent dot-NET.
One reason for this is because their IT departments discovered a few years ago that they have accumulated all sorts of crufty code written against multiple languages and platforms, and had no way to manage it because all the contractors who wrote it had taken the money and run. Seeing shrinking IT budgets, and new platforms (like ROR) coming out every year, they decided to make their lives easier by standardizing on the most best-of-breed (read: most resumes available) platforms. This would allow their IT folks to only have to learn one set of technologies to deploy and manage applications internally.
IT managers like standard platforms, because they are sold on the idea that they can develop "web services" which can let apps "transparently share data" and allow for "collaborative whatchamacatchie". Most often, the reality is that these organizations still have a tremendous amount of data scattered across N databases and M organizations, and no magic dev platform is going to solve that without effort.
I regard most of the J2EE architecture as over-engineered and overkill on most projects I've done. I prefer to use it stripped-down as I can get away with. Heck, I could probably embed a Jython interpreter in a servlet and use it on a project without anyone noticing. But for large organizations, the trend is toward less diversity.