Slashdot Log In
Ruby On Rails Showdown with Java Spring/Hibernate
Posted by
Hemos
on Mon Apr 04, 2005 10:29 AM
from the battle-of-the-overhead dept.
from the battle-of-the-overhead dept.
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?"
This discussion has been archived.
No new comments can be posted.
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
Full
Abbreviated
Hidden
Loading... please wait.
Faster? (Score:5, Funny)
I would assume so, doesn't optimized usually mean faster?
Re:Faster? (Score:5, Insightful)
Parent
Obligatory (Score:5, Funny)
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.
Parent
Re:Faster? (Score:5, Insightful)
Parent
Re:Faster? (Score:5, Insightful)
Parent
Re:Faster? (Score:5, Informative)
Ruby has one other massive advantage over Java on the medium-term horizon: Parrot. The Ruby-on-Parrot effort is progressing nicely, and when that is complete, Ponie [poniecode.org] will give Ruby transparent access to all of CPAN (thought yet another JITted bytecode system) even for those who don't like or can't use Perl.
At that point, Ruby becomes (IMHO) the most attractive HLL in existance (until Perl 6 lands... IF Perl 6 lands...)
Parent
Not a safe or true assumption (Score:4, Insightful)
Anyway, in this particular case you may be right.
Parent
Not fast enough for Slashdot... (Score:4, Funny)
You are all wrong (Score:5, Insightful)
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.
I couldn't agree more (Score:5, Informative)
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.
Parent
Re:You are all wrong (Score:4, Insightful)
If you're the only one using a language, it can get pretty lonely. Plus, managers like technology that is generally popular in case you get hit by a bus.
Parent
No need to be pedantic (Score:5, Informative)
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.
Parent
Re:You are all wrong (Score:5, Insightful)
Not so.
There are purely functional languages that are -- for all practical purposes -- impossible to optimize as well as either procedural or hybrid procedural/functional languages.
However, that's beside the point. Java in particular is NOT just a language. Java is a specification for a fair amount of the IMPLEMENTATION as well. Java specifies the behavior of GC, type storage, and many other implementation details ot a level that precludes many hardware or OS specific optimizations.
There are non-conforming compilers that ignore these strictures (and get excellent performance), but they are not -- strictly speaking -- compiling Java.
Languages like Ruby, Python, Perl and PHP on the other hand, make no such strict demands, and thus can be optimized appropriately for the platform.
Parent
Article Text (Score:5, Informative)
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 (Score:5, Informative)
First Post! (Score:5, Funny)
--
Posted Via JFPB - Java First Post Bot
Application (Score:5, Insightful)
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 [rubyonrails.com]
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
Re:Application (Score:4, Informative)
No, the comparison did not highlight this. The development speed was not comparable because when the app was written in Ruby, it was not the first time the app was written. As such, many development problems had already been resolved. This is noted by the author in the post.
Parent
Application scaling (Score:5, Insightful)
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.
Parent
Re:Application (Score:5, Funny)
Yes there is. Writing shakespeare. Just add more monkeys and more typewriters.
Parent
Mojavi (Score:5, Informative)
Slightly off topic, but thought some might be interested.
There is a pretty cool and full featured MVC framework for PHP called Mojavi [mojavi.org]. 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.
Hibernate too hyped (Score:5, Insightful)
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.
Re:Hibernate too hyped (Score:5, Insightful)
Perhaps you should try actually using Hibernate.
First, Hibernate works just fine with hand-generated SQL tables. Indeed, that's the only thing I've ever used it for. Second, you can happily tune your queries through hinting to Hibernate and careful choices of object relationshiops, and the recently released Hibernate 3 allows to you hand-write all the SQL if you choose.
Third, you're kinda missing the point of Hibernate. Using Hibernate akin to using Java itself in that both of them hide a lot of details about the underlying operations so that the programmer can spend their time and energy focusing on the essential problems rather than the details of the technology.
Most programmers doing SQL stuff in Java let the weirdness of SQL databases distort their designs heavily. They don't really do OO programming because they spend all their time thinking about database operations. Hibernate lets you do good OO design and have 95% of the SQL rituals handled under the hood.
It's possible that you lose some performance to Hibernate, although I never noticed it, and Hibernate's built-in caching [hibernate.org] means that many apps will be faster [hibernate.org]. But really, if performance is all that important to you, you shouldn't be using a database at all. Serializing all your data every time you need to work with it is incredibly expensive. There's a reason that things like Google and Quake aren't built on top of SQL databases.
Parent
Meta-application issues (Score:4, Insightful)
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.
Hibernate Vs. Ruby on Rails- flame free! (Score:5, Informative)
looks interesting, but does it have to be ruby? (Score:5, Interesting)
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...
Re:looks interesting, but does it have to be ruby? (Score:5, Interesting)
Oh, of course you are. Might as well just admit it.
As far as Ruby vs. Python features go:
1) code blocks. Ruby lets you pass code blocks around. Sounds pretty dull, eh? But in fact it's what makes it possible to create Domain Specific Languages in Ruby quite easily without needing to create a special parser. In many ways Rails can be thought of as a domain specific language built on Ruby.
2) classes are always open in Ruby(including the Class class). By 'open' I mean you can always add new methods to a class (or even a particular object). Another feature that makes it easy to create DSLs
3) continuations. (Not that Rails makes use of them, but some other Ruby-based web programming frameworks do)
4) Ruby has true lambdas. AFAIK Python's lambdas are pretty limited (limited to one expression?)
Also, can you embed Python in HTML? (seems that the whitespace issue would cause a lot of problems with doing that)
I'm just looking for the practical solutions...
Give RoR a try. You might just find that it'll do everything you need it to do now without needing to wait around for a Python-based clone. What could be more practical?
Parent
Re:looks interesting, but does it have to be ruby? (Score:5, Interesting)
def func():
def my_code_block():
print "Hello, World!"
return my_code_block;
f = func();
f();
Of course. You're basically passing around a function reference. That's not what I'm talking about.
What Python doesn't have is nice, clean, anonymous code blocks
That's what I'm talking about. In Python you can't do something like this:my_while looks like a natural extension of the language. I'm sure you could duplicate this function in Python, but it wouldn't look like a natural part of the language.
Parent
RoR sounds great, but... (Score:5, Insightful)
Sure. (Score:5, Interesting)
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.
Parent
Spoke to Justin about this... (Score:5, Informative)
At the Milwaukee No Fluff Just Stuff conference, I was invovled in a lunchtime conversation with Justin and [Pragmatic] Dave Thomas [pragmaticprogrammer.com] 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 [oreilly.com], 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.
I use both J2EE and Ruby on Rails (Score:5, Interesting)
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
Zope 3 (Score:4, Interesting)
Conclusion holds the key (Score:4, Insightful)
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.
Re:Here we go again (Score:5, Funny)
Just watch, it's impossible to have an intelligent discussion between the two groups.
Is that so, Mr. Poopyhead?
Parent
Re:Here we go again (Score:5, Interesting)
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.
Parent
Re:Here we go again (Score:5, Interesting)
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.
Parent
Re:any comparison like this... (Score:4, Interesting)
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.
Parent
Re:any comparison like this... (Score:4, Informative)
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.
Parent
Re:any comparison like this... (Score:5, Informative)
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.
Parent
Re:any comparison like this... (Score:4, Insightful)
Regards,
Steve
Parent
Re:any comparison like this... (Score:4, Informative)
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.
Parent
Re:any comparison like this... (Score:5, Insightful)
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.
Parent
Re:Wait..... (Score:4, Insightful)
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.
Parent
Re:Ruby is a toy (Score:5, Informative)
Parent
Re:Security (Score:4, Informative)
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 [rubyonrails.com] .
This is a great example of rails quality documentation. have a look at the bookshelf itself: Hieraki bookshelf [rubyonrails.com]
And the application which powers it is open source (MIT) at www.hieraki.org [hieraki.org]
Parent
This is a flawed recollection. (Score:5, Informative)
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.
Parent
Re:Security (Score:5, Insightful)
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?
Parent
Re:Line counts, method counts.. all lies. (Score:5, Interesting)
Good point about the getter/setter methods. To which I reply: You know they can be generated for you if you use a modern language like Ruby.
class Foo
attr_accessor
end
Now the class Foo has accessor methods (getter and setter) for the instance vars bar, baz and foo.
A total of six methods were created from that one line of code. No need for a 'modern Java IDE' - vi or emacs work fine. You want read-only access? Use attr_reader then only the getter methods will be created.
This is probably why the method count for Ruby in the article was significantly less than for the Java version.
Parent
Re:Ruby on rails performance (Score:5, Interesting)
-----
A few problems with your testing that I could see:
"So, for the sake of total specificity, the following numbers were generated on a 1.5GhZ Mac OSX (10.3.7) PowerBook with a 4200rpm hard drive and 1GB of RAM."
The Java Virtual Machine running on Macs has always been questionable. Its not Sun's implementation and has not been as heavily updated by Apple. First I would start by running your tests on a Windows or Linux box using the Sun JRE 1.5.
"The Java app is running on Jakarta Tomcat v 5.0.28, while the Rails app is running in Lighttp with FastCGI. The setups are standard for each application stack."
As mentioned by a prior poster, Tomcat is only a reference implementation. Its not built for speed. The Ruby setup you used, on the other hand, is. This alone is a major oversight in your testing.
"Number of Methods:
Rails: 126
Java: 549"
Having to write 4 times as many methods is a clear indicator that you are using the wrong framworks to get the job done. There are hundreds of frameworks for building web applications between the languages. Spring with Hibernate must not be the right mix.
"Configuration Lines
Rails: 113
Java: 1161"
I am guessing you used Xerces for parsing on the Java side. This is bad since Xerces is not a very quick parser and there are plenty of Java XML parsers that are much better suited when speed is concerned. Look at using XPP or Lightning instead. With JAXP (if Hibernate and Spring support it) you will not have to change code to use these in place of Xerces. Also, any time you are comparing a XML parsed document versus and non-XML parsed document the latter will always win. Try using frameworks that do not depend on XML configuration files.
True language performance comparisons should never be done with web applications. There are simply too many variables. I know this was not your intent (doing language performance comparisons), but that is how your article is being viewed by others. People are always itching for a battle between the languages.
Different languages are suited for different tasks better than others. For example, I once had to translate a Perl application to Java for my work. Due to what that Perl code was doing, the finished Java application was several times larger and slower. Perl was better due to the task at hand.
Parent