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?
GO RUBY GO!
ROR bites. Try zope instead.
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.
Nothing like fanning the flames of an already hot topic between J2EE & RoR developers. Just watch, it's impossible to have an intelligent discussion between the two groups.
...
/overengineered / whatever? Ruby on Rails MAY be much better but any evidence like this is hardly valuable, that's why I would not even bother to RTFA
without reading TFA, any comparison of this sort does not have much value. Maybe if he reimplemented his app using same Java he would get 50% speed and codebase improvement? Maybe the original was just too poorly coded
...remember good 'ol times when IP used to mean Internet Protocol....
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. --
"Ruby is getting a new optimized bytecode compiler for its upcoming 2.0 release. Will Ruby on Rails become even faster as a result?"
Nah, that couldn't happend, could it???
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.
I recall one of the rather trivial Ruby on Rails tutorials having a remote code execution exploit.
RoR is a cool concept, but definately not ready for any kind of real deployment.
Conformity is the jailer of freedom and enemy of growth. -JFK
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*
So how is java compared to ruby? Is ruby a lot faster or on par with the speed of Java (on most systems)? And how does ruby compare to java at the moment? I wonder if its worth switching over from java to ruby..
Mirror Here.
RoR is a toy comparing to Hibernate and Spring. There is no serious caching, no serious transation capabilities, or messaging mechanisms. hype and buzz. Also, Check this page for a comparison of RoR and Hibernate. However, it is probably better than Php. http://www.theserverside.com/articles/article.tss? l=RailsHibernate
Java is big and slow! But would it have survived the slashdotting?
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.
First post!
--
Posted Via JFPB - Java First Post Bot
lexbaby
"Be Brave, Be Loyal, Be True." -- Hawkeye Pierce
Well, the thing about Ruby vs. Java is that Ruby is a general purpose programming language (unlike PHP).
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
I was stunned when I used the Ruby on Rails package and had content driven web-apps up and running in a few hours, without the headache of deployment descriptors and no need to wrap them up in War/Jar/Ear files.
The language and it's syntax are VERY lean and elegant. It's almost as if Ruby is what Java could have been (without the bloat)
And with the GUI, Database, XML, Network, and the rest of the other bindings it is fairly complete runtime environment.
So, the point of this study is to show that Java is inefficient?
Yes. A Java developer intentionally set out to show that his preferred language was inefficient.
I don't mean to troll
Are you sure about that? You don't seem to have read the Slashdot summary, let alone TFA.
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.
just write it in C if speed and size are issues.
+1, Embarassingly stupid
Another one bites the dust
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.
I see the masters are still at work. bravo.
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
When was the last time that you used and evaluated Java?
Thats all well and good until your clients reach 4 digits, maybe even 3 digits. Java is also quite fast and makes an excellent server platform. It is constantly optimizing its own code on the fly, how cool is that? It is also purposely verbose as it makes large projects involving many members in different teams easier. Comments are sure nice, but in the end the code does the talking. So many ignorant people that have never been involved in enterprise really need to read up.
Regards,
Steve
1) How is that a Java problem?
2) I've run OS X since the first Public Beta and never had that type of issue on a lot slower of machine. Even my new Powerbook does not have that issue. Sure nothing else is bringing your computer to a halt?
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
Rails will win with the market because it is easy to find cheap hosting for Ruby on Rails. Not as cheap as PHP currently, but very reasonable already. Java lacks in this department.
Apache + FastCGI = cheap hosting
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.
Every time a good coder rewrites an app, it gets better. Especially a large, complex app. Ususally the new design insights afforded by a "warmup" cycle have to battle the tedium of repetition. But rewriting in a new language, especially one in which you're fluent, and interested in exploiting for performance, is a real motivator for optimization. I'd like to see comparitive benchmarks for another rewrite, *in Java*, to see how much performance gain is from the language, and how much is from the educational rewrite cycles. Deriving the motivator of "interest" is going to be harder, though still a factor.
--
make install -not war
with the awesome /. powers
and now I can't read the article.
You can't handle the truth.
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
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
Actually what you just pointed out is that you won't or *can't* "admin a huge corporate dynamic website". A good technologist could make RoR or Java work just as well as your "stack" of Pico, PHP and MySQL (which, as we all know is inherintly easier to maintain than a Java app).
Ahh, okay. That makes a lot more sense. However, what about clustering your boxen, *then* running all your company's IT needs from it; thereby eliminating issues such as that? Couldn't you make damn sure everything you were using, and were likely to use, ran on that "One machine", then optimise it through the teeth to allow you to do more?
Though I do really see where you're coming from.
My UID is prime. Is yours?
Does anyone know about the feasability of using Ruby on Rails for the Captain Crunch method of object serialization? I've heard good things, that there's a lot less code to write, but it's harder to understand for a novice.
Has anyone had any experience with this?
Java sucks on Macs.
It is a problem because it sucks on Solaris, on Linux, on HP-UX and on Windows.
PHP is a general-purpose scripting language. You can write shell scripts in PHP. You can write GUI applications in PHP. It started off as web-only, but that hasn't been the case for years.
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.
Linux is not Windows
Planet Ruby on Rails (bunch of RSS feeds). The Ruby community is growing like a wild fire. :-)
Robby Russell
PLANET ARGON
Robby on Rails
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...
Don't read too much into this. Ruby is a nice language and Active Record is a nice ORM solution, BUT... There are severe limitations for RoR. It can't work with legacy databases, since it relies on the object model based on the database tables and their relations. There is no caching of data either. Simplistic performance comparisons are very naive. People are jumping into conclusions based on a tiny toy demo. It only proves that: Ruby is good for small apps. It is better than Java in this scope, but only when you get to create the whole application from ground up. There is no proof beyond that, and there won't be any time soon because Ruby does not have support for many critical features that larger applications require. Ruby is a scripting language, meant for scripting. Do not try to imagine anything else.
is going to be the same as what Ruby does and maybe more. Lean java might outperform Ruby, but Java/Spring/Hibernate (heck, toss in Struts), is so bloated with framework, I'd wager that its trying to do more than Ruby, in order to get the exact same result in the end (serving web pages).
-Phantom of the Operating System
Why isn't this modded up?
This has been the only valuable contribution so far.
Listen up, Ruby-fanwhores who think they know something about "teh computer stuff": your shitty toy language is ugly and slow. It may be enough to run your blog with 2 visitors (you and the virtual stalker that wanks off to your profile-picture), but it just does not cut it in the real world.
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.
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.
FUD. Where is Rails missing scalability or distributability? You can distribute it over as many servers as you like. What's wrong with Rails' caching? Please explain.
As it stands today, I can work on my Java app on my Wintel desktop, or my Mac laptop, and then deploy it all to the mixed-Solaris/Linux environment that is our production cluster. Web apps under Java are extremely portable-- much, much moreso than even the simplest PHP application.
Imagine a PHP application where all of the PHP server config, PHP app config, all the PHP files, required libraries, images, etc etc, were in a single zipfile and could be moved from machine to machine without any modification. That's what a Java WAR (Web ARchive) file is, and that's how hot deployment works.
And most of the posters admit they haven't even read the article yet.
Haven't read, because the site crashed. Always embarassing when that happens.
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?
You never really had to deal with the issue to attach to one of those big irons did you? You never had the issue to develop for an RS6000 which was a very valuable production machine and no software install basically was allowed, and you never really until install time you were able to even get access to the machine? Java is not the best solution to quickly hack the average guestbook, but it definitely shines once you have to cross platforms.
Speed matters.
Period.
Why is your browser/OS/emailclient/imageprocessor/compiler etc. written in C or C++.
Speed, baby.
Sorry, but as the flamebaiter AC mentioned above, C is still the King !!!
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'm primarily a GUI programmer, particularly in accounting situations. I've been moving over to Java (slowly) from VisualBasic, but am not so dedicated to it that I couldn't switch. How well do the Ruby GUI libs work, and have platform independent are those libs?
The world's burning. Moped Jesus spotted on I50. Details at 11.
Yeah, the site crashed. Its, ummmm, well, Mambo and WordPress, if you must know. I'm trying to get a hold of the good folks at TextDrive to see how to handle all you slashdotters.
It is also purposely verbose as it makes large projects involving many members in different teams easier. Comments are sure nice, but in the end the code does the talking
Errrr... so the more code there is, the easier it is to read and understand? That flies in the face of ideas like logical abstraction ( http://c2.com/cgi/wiki?OnceAndOnlyOnce ), code reuse , and higher-level languages in general and certainly doesn't agree with my experience...
...Ruby is getting a new optimized bytecode compiler for its upcoming 2.0 release. ...
Wasn't (or rather isn't) parrot supposed to be some wiz-bang bytecode interpreter for scripting languages, designed to be an underlying bytecode engine for multiple scripting languages?
I find it kind of sad that we could have a good framework for a common bytecode engine.
We could write different parts of something in different languages if we wanted, with common bytecode for each. Someones ruby code could work with someone elses php/perl/rexx/??? code.
Portions that need high optimization could be written in the lower level "psuedo-assembler"
But... we never actually see anything like this in practice. It's always 15 different languages and 15 different sets of libraries.
Sure would be nice to write *portions* of something in ruby and other portions in another language. We'll never see this, because the ruby people would probably not want to cross boundaries with the "others".
Its an internal server error.
Man, there's so much wrong FUD being thrown around here, it's not even funny.
Rails DOES have caching. Rails CAN DO I18N. Rails can scale. Rails does have documentation (and a few books are coming out in a couple months).
http://manuals.rubyonrails.com/read/book/16 for how to use gettext with Rails.
Tomcat is certainly not known for performance, well, not known for it in a positive way anyhow. How about doing the same benchmarks using resin or a commercial java server instead of tomcat?
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
I love Hibernate. Hibernate is not a speed demon. It's a scalability demon. It's a OR mapping demon. It's a flexibility in persistence demon in spades.
It ain't fast. It's not dog slow, but you've got to pay the piper somewhere. If you cache out the wazoo you can get some decent performance, but then you pay in memory. (and if you're clustering, in multicast interserver network traffic)
So get over it and use the tool for what it was meant to be used.
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.
Rails is not special or impressive. The only people who seem to like it are people who were using huge bloated java stacks. Try comparing rails to something good like seaside and then see how much it "rocks".
Fortran still wins on numerical integration methods.
-fb Everything not expressly forbidden is now mandatory.
The rails guy is constantly pushing rails at every opportunity, and is smart enough to start lots of java flamewars to get even more attention. Once you start like that, you end up with other people getting excited and pushing it at every opportunity too. Before you know it, every other story on slashdot is about rails.
Nobody has really made any serious attempts to push seaside, or any of the python frameworks, so obviously they are less well known. That's ok though, you don't have to use rails just because its the latest fad.
There's a big difference between "you can put identical copies of your rails app on many servers and it works if everything is normal" and a real distributed app. What happens to the users in the middle of doing something on one server when it goes down? And rails caching is per server, which is a complete waste and starts to look really stupid when you have a big app running on a few dozen machines.
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
You see your post modded down? That's because you pissed off Java programmers by saying that you think that an aspect of something they do is not very perfect. You insulted their egos. Bad bad Kimos. Go sit in the corner.
There are already similar or even better (seaside) frameworks in other languages, including both python and perl. Rails is well marketed, that's all.
what is the difference between python and ruby ?
what is the difference between ruby on rails and zope ?
If you're writting web applications in C... uh, you need help. You're just making it way harder than it needs to be.
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
Now, the question is how long with the job they hold last before it is farmed off to some middle eastern-ish country or is given in to a new mandate at the company to switch to RoR. I give them 6-12 months job security at the most.
No, actually it sees which parts of code are used more often then others and dynamically changes it's bytecode to optimize for the most reoccuring situations. If you start a server and measure performance after an hour, it'll (99% of the time) be faster a week later.
Regards,
Steve
Sorry, but it is.
Yes, they teach you in sophmore programming that speed is not important. And if you don't know what the fuck you're doing, then , yeah, you need to concentrate on readability and correctness first.
In the real world, fast is important.
And you're right. If it's not fast enough, use assembly. Any good C compiler will give you an escape to assembly.
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.
Seems it was recently converted to PHP... check the site.
Hey, how's your Javagator working?
How 'bout that ol' JavaOs you're running?
Is it fast?
If I have a "stock" PHP and I want the gd libraries, I don't do either of your nonsensical choices. I compile the PHP gd module, uncomment the php.ini line that loads the PHP gd module, and reload apache. You don't need to compile everything into PHP you know, and in fact its pretty dumb to do so. Not trying to defend PHP for a large project or anything, I'm not crazy. But you shouldn't challenge people to tests you don't understand.
check out the link. Fortran hasn't been faster since -O3
Well, I think I know what part of the reason is. In a lot of Universities, they switched from C++ to C++ around 1998 or 1999. A lot of these people are coming into the workforce now. They are loathe to study anything else, since they only depend on what the university taught them. Basically, they are just tailormade computer scientists/engineers. They do not have the drive or urge to go out and learn something new. They basically don't even try to find out what's new because they only know what their courses taught them. A lot of them also joined the CS programs because "there's money to be made in computers". There are certain techonologies I like better than others, so as a personal choice I will use the one I like. But if I'm told I need to use the other technology (the one I don't particularly like, or know), then I'll poke through documentation and try and learn it. For example, I don't particularly like ColdFusion. But I had to use it once because that's what the department used. In another scenario, they were using CF, but I suggested that they change to PHP, which they did.
Anyway, so these "fanboys" know Java like the back of their hand, but don't want to switch to anything else. Which is why, just like the GP said, they will attack anything that could invalidate their "experience".
Vivin Suresh Paliath
http://vivin.net
I like
YARV is Rite, now (I linked the announcement Matz made).
The point of YARV is to make Ruby run faster (as in, the VM itself is optimized and has JIT support being built), and help reduce memory footprints (Ruby code-as-text is reduced to ruby-code-as-bytecode). It moves towards both these goals with "superinstructions", which are statistically common groups of instructions that are made into one.
Before people mention it, RISC architectures are considered by many to be best for hardware, but in VMs, CISC architectures are generally better (and that's why YARV is a CISC system).
YARV may not speed up rails all that much though. Rails allready can cache and serve pages at the limit of the web server's caching ability, and with action caching (which is slightly more set back from page caching) you get nearly the full speed (1000req/sec instead of 1500req/sec).
Slashdot. It's Not For Common Sense
You kinda have to try them all and see if you like them, which can be quite annoying when sparse documentation makes trying things take longer than it should. I don't actually care for python though, so I'm not the best person to ask.
I'm tired of over-complicated J2EE messes.
A few years from now, people are going to re-visit the legacy j2ee junk that was written today. They will just junk it and start from scratch. Why? Because no one will want to muck around with the endless unreadable globs of declarative configuration that comprises a j2ee application.
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
Rails has everything you need to make the webapp secure. Everything.
The bug was in a wiki'd tutorial and was only up for about 30 minutes before corrected but you'd think that every single Rails developer has horns now. Most people never even saw the tutorial during that transition.
If I call your SQL line directly, isntead of going through the framework, how exactly can said bypassed framework protect you? Rails gives you a trivial way to safely execute arbitrary SQL, and several ways to execute specific types of common SQL qualifiers on common actions (like find-by-id or find-by-field).
Please, stop FUDing.
Slashdot. It's Not For Common Sense
You don't need to alter objects at run-time to make a rails like framework. That's a rediculous way to try to make ruby seem special. The question is "can problem X be solved by language Y?" and your answer is "no, you would have to do it differently". There's nothing wrong with doing it differently, it still solves the problem. Just because you don't like the perl or python way of doing something, does mean they are wrong and ruby is right. Different strokes for different folks.
But showing how uninformed you are with the lisp flamebait, and the lies about not being able to use python for templating really adds to your credibility, nice touch.
Seaside. That is the list. Nothing else makes the list because they all (rails included) look sad and pathetic in comparison. I do not care for python, so I can't really comment on the quality of various python frameworks except to say that I hated zope (not really a framework, I know).
RoR was taking the entire page output of a new request, caching it, and then sending that entire result for subsequent, similar requests.
The Java stack, OTOH, was using some fairly complex middle and data tier caching inside Spring and Hibernate.
These are VERY different caching strategies. I'd be interested to see the results if the author had used something like OsCache on the Java stack.
My company powered the site for a very large UK awards show, and used OsCache heavily; the results were fairly impressive, allowing us to soak almost half of the server's 100Mbit network pipe at peak traffic without putting a great deal of load on the server (I think top was showing around 0.5/0.6 at peak load, although I realise that this is not a good indicator of load).
Invoicing, Time Tracking, Reporting
People keep telling me this, but where's PHP's threading implementation? You're going to have a pretty limited range of GUI apps if every application can only have a single thread of execution.
I've written my fair share of php web applications and I'd say I've given it a fair evaluation but I don't think it's good for general purpose scripting. I'm not saying it's not capable by any menas, but you don't really leverage its strengths in a shell script. PHP has some acknowledged syntactic flaws that can surprise you if you're not careful. These flaws are tolerated in a web environment because you get a performance boost from php's web feature set, but there's no reason to put up with them in a shell scripting situation when you have perl, python, ruby, and even awk at your disposal.
Stop intellectual property from infringing on me
Of course, you don't need me to tell you this, you could just check the documentation yourself.
C'mon, can you even pretend to look into things before you FUD them? There are plenty of valid criticisms for Rails, if you care to find them.
Slashdot. It's Not For Common Sense
Perhaps another comparison worth making is Rails versus Trails for Java? From the trails site: "Trails is a domain driven development framework in the spirit of Ruby on Rails or Naked Objects."
Channing
All I could think of when i read this headline...
"And now we enter what must the most beautiful concert hall of all the universe. A perfect replica of the old opera house...but who cares?" --DJ Ruby Rhod, The Fifth Element
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
can I use this Ruby on Rails to write ordinary applications like I can with java... you know, ones that you don't require a browser or a server for... totally standalone, ordinary, quick and dirty personal type programs, like I used to hack up in superbasic in the good ol days on my QL???
Donald 'Duck' Dunn: We had a band powerful enough to turn goat piss into gasoline.
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.
I find the publication of books hardly validating to a technology. RoR delivers, it is fast and rather easy to comprehend and use. The #rubyonrails channel on Freenode.net is FULL of technically capable and able people that will immediately answer questions interactively (using pastebot and your own webby for code and sample pages) in seconds. There is no excuse for people to ignore Ruby cause there are no books available now or available down the road.
I have nothing to say about the cache performance differences except that a 15-fold increase cannot be explained by language choice but must point to algorithmic and library decisions.
But more importantly, the reason I'm not convinced is that the author's methodology is rather unsound. He took a first-generation Java application and *reimplemented* it. When you do that, you get to add in all sorts of improvements that you hadn't thought about the first time around. You're not so close to the trees any more. It's entirely possible that the improvements in performance and number of lines were largely due to the fact that he wrote a second generation rewrite, and had less to do with the fact that he wrote it in Ruby. Ruby is a significantly slower language than Java -- I don't think even RoR advocates would debate this. Isn't it possible that the fact that he got his RoR code to run as fast as Java in non-cached mode due to second-generation improvements which countered Ruby's natural computational pokeyness? And the cached mode improvements due to his choice of library?
You can write dang fast stuff in Java if you're careful (and sacrifice Sun's stupid slow libraries). It's not nearly as easy to write dang fast stuff in Ruby or Python. Indeed, all one really can say about them performancewise is that they can outperform highly lazy code in Java -- which is of course what the vast majority of Java coders write, so maybe that's not so back-handed a complement as it sounds.
You can use parts of Ruby On Rails, usually the ActiveRecord component, to do app dev with Ruby. Ruby does have FX, GTK and even Qt bindings if you so desire to use them.
However, much of Rails's work revolves around web work, and so besides ActiveRecord, there isn't much else you can use.
Ruby is a viable choice for building applications, though. Rails is just one expression of this.
Slashdot. It's Not For Common Sense
sudo apt-get install php4-gd
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.
I am not talking about whatever tutorial thing that guy was. I didn't hear about that. I am also not talking about bypassing the framework for the 3rd time, please take the time to read before you jump to defend someone else's baby that you want to live vicariously through.
I am talking about a few months ago when I looked into using rails, there was a mailing list discussion I came across where passing args to a rails function could be done in two ways. One way protected you from SQL injection, the other did not. A user proposed a patch to disable the unsafe way, since he, and many others didn't even realize that way was unsafe. David refused that patch because it might inconvenience people who were using the insecure way, but protecting themselves manually. This is the exact same attitude that prevents me from using microsoft products. I don't care who is writing the software, if they consider convenience more important than security, I will not use it.
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.
I am not digging through the mailing list archives that have no search to find it for you. I am not confused, however if you would like to believe I am than that is fine. I am not asking you not to use rails, I am saying some of us refuse to use it because the attitude of the main developer is that convenience trumps security, and we feel that attitude is harmful.
JSP doesn't do that because JSP isn't a framework. He's not complaining about using mod_ruby + eruby and it not sanitizing input, he is complaining that a framework built on top of ruby technologies doesn't make any attempt at being secure.
Nobody is expecting languages to do these things, but its pretty reasonable to expect a framework specifically built to make dynamic website creation easier would deal with the specific problems that plague dynamic websites.
Leave it to RoR to claim an obviously PHP-site as their own...
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
You can write shell scripts in PHP.
Yup! I can't emphasis that enough. We have started moving away from perl to php for shell scripting.
I have a PHP script that converts a Quark XPressTags document into XML. I have PHP scripts that convert EPS images into jpegs (via ImageMagick).
PHP runs our content management system. Taking things directly from quark and putting them into databases.
And no, it doesn't have code completion. Plus, it uses FOX UI toolkit. Why not GTK? I have no idea whatsoever.
Uh, ok. You seem all worked up.
I don't care if smalltalk is the current fad or not, that has no effect on me. I care about what framework allows me to be the most productive, which is very clearly, by a large margin, seaside. If someone else does better someday, then I'll certainly consider switching. But flaming java frameworks and developers isn't what I consider "doing better", and that's all that rails seems to care about right now.
Why all the venom? This is the fourth or fifth post of yours bashing RoR and praising Seaside. Do you contribute to Seaside or do you just hate that something you like isn't similarly appreciated by others?
;-)
Either way it makes you come off looking like a bit of a nut.
Ruby is Cool. Ruby is Fun. Lots of folks are starting to play with it and that means they're going to develop apps and frameworks that compete with current alternatives - that doesn't mean we all have to turn this into a bloodsport.
I like Smalltalk too - but you've got to tone it down if you expect anyone to listen.
Heck, check out Borges, the Ruby framework that's related to Seaside.
Kevin
You're right, you can do things different ways to emulate what Ruby is doing naturally. But, then you begin to lose the beautiful meta-language-syntax that makes ActiveRecord and ActionPack so attractive.
Python is a great language, and is very powerful. But it lacks true lambdas and closures (yes, you get baby-lambdas, and no, they aren't enough). It also lacks the powerful meta-programming features that Ruby has. Of course, Python has other strengths, but they're not topical here.
Subway will have to discover what is the natural "Python" way for doing what Rails does (which is a great example of the "Ruby Way"). This may or may not be as beautiful and pleasnt as the Ruby way.
This doesn't condemn Subway or Python. It remains to be seen what they can do. So far, I don't think many people have been impressed so far, but we're all waiting to see what happens.
Slashdot. It's Not For Common Sense
See, the larger user base argument has never held any water. Most of the users are just that, users. They do not contribute anything, and as such do not matter to me. And of course, you might think rails has alot of people, but it mostly has alot of hot air. There are way more java developers, so rails really isn't the best example of "choose this because everyone else is", you should be advocating against rails if you care about marketshare. I would be using windows and GaySP.net if I cared about what is popular. Instead, I use whatever makes me most productive, while still meeting the requirements of the project at hand.
Code completion via IRB is in the works. It's just a very hard problem.
As for why not GTK? Compatibility with Windows, Linux and OS X.
Slashdot. It's Not For Common Sense
So, when the entire page is filled with people blindly praising rails, that's all good. But when I say I don't care for rails, and I can't really comment on any other frameworks besides seaside and zope, I am "a bit of a nut"? Honestly, I don't care for python or perl, so I really can't make any comparisons of the various frameworks in those languages, sorry.
To answer your question, no, I do not contribute to seaside, I am just a user. I do not hate that it isn't as well known either. I am simply advocating it, just like dozens of people are advocating rails in this same discussion. I kinda wonder why you feel that pushing software you like is crazy, but only when I do it.
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.
You can do things different ways to emulate what ruby is doing naturally, but that would be dumb. There is no need to emulate what ruby is doing, just step away from ruby and rails for a second, and think of the problem, instead of one particular implimentation of the solution. In ruby it may be natural to solve this problem using techniques rails uses. In other languages its natural to do it different ways, which may be more, less or equally "elegant" depending on the perspective of the person reading the code.
Umm, closing off arbitrary SQL statements would be an incredibly bad idea. ActiveRecord is great, but it is not the Alpha and Omega of all things you could want to do. It's not developer convienience we're talking about here. If you removed that feature there would be some things you just couldn't do.
This isn't about discarding security, it's standard practice. Unchecked SQL queries are unsafe. They're unsafe because they're the final level of the database layer. If you don't know this, you're at a novice level of web programming and shouldn't be using that feature anyways.
Maybe one day ActiveRecord will be so good that you'd never want to use that feature, but that's not now. Sorry.
But you're holding an unreasonable standard with, here. Keep that in mind.
Slashdot. It's Not For Common Sense
The project itself is not open-source; the client is now and shall remain anonymous.
Nobody is going to be convinced either way if the code is hidden from the public. Maybe he used bad Java coding practices. We won't know 'til we see the code.
Table-ized A.I.
The other posts in this thread have nothing to do with this. I am not talking about any tutorial that was exploited, and I know nothing about that case, never heard about it before now. I am talking about a patch David refused. Thanks for the search link though, didn't realize the newsgroup and mailing list were the same. Here's the link for you:
l s/749/match=sql+injection
http://article.gmane.org/gmane.comp.lang.ruby.rai
As you can see, David refuses to make things secure for people who didn't magically guess to do it the "right" way, because it might inconvenience people. This is the wrong attitude, and I do not trust software written by people who feel convenience trumps security.
This has nothing to do with letting people use arbitrary statements. I don't know how you could think that after me already saying repeatedly that I am not talking about users running their own SQL queries. Thanks to the poster above for the search link, this is what I am talking about:
l s/749/match=sql+injection
http://article.gmane.org/gmane.comp.lang.ruby.rai
That is a bad attitude for a developer, and I do not use software written by people with that attitude. I'm not sure why this was such a big deal for you guys to understand, but some people care about security, not just when its convenient.
jesus. don't cover more bullshit with bullshit. get the facts. ruby parrot effort is dead.
and have you even *used* ruby or are you just karma whoring?
And its not a very ambiguous quote, its pretty clear. You claimed ruby is better for making a rails-like framework because ruby is like ruby and python and perl aren't.
However, I did reread what you said just to be sure, and in fact the quote is still there, and is still the same. If I read it over and over will it change or something?
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.
It's easy to get dramatic productivity when your app fits well with what the framework auto-generates.
Performance is a tricky thing to measure accurately here. Unfortunately, Sun spends more time optimizing its Virtual Machine for Intel architectures than it does for PowerPC architectures. This is simply because Intel accounts for more of the market. The result of this is that Java apps often run faster on Intel than they do on PowerPC or even Sun's own SPARC processors.
.NET developer, maybe it's time I take a look at Ruby.
I'd be interested to see some performance numbers on an Intel based architecture.
However, I'm most compelled by some code maintenance aspects of Ruby. As a Java and
It does not support Unicode. No unicode strings, no unicode regexps.
Wrong. Regexes support Unicode, and the standard library provides Unicode string functions. A lot of Rails apps are using UTF-8 without any problems. Switching my app to UTF-8 took two lines of code.The Ruby folk go to extremes sometimes to get developers' attention: here they're presenting Ruby on Rails as something as wonderful and new,whereas every language has such code generators: Perl has Mason, MayPole and many others that do everything RoR does but without the insane premise that "everything is an object" (which Ruby is based).
Ruby is one man's honest effort to objectify Perl. A good effort, I might add, but because it's derived from Perl and has such a small user base, Ruby will remain a niche language.
How about Java Ruby? ;)
http://jruby.sourceforge.net/
You forgot SWT.
Hypotheticaly speaking, is there any reason you couldn't rewrite GD libraries in PHP itself, and then include them?
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 didn't say it was 1.0 or that it should be perfect. That particular instance isn't my problem, just an example. The attitude that security is something to pawn off on users instead of taking responsibility for is my problem. I was very clear about this, you refused to believe me, and now you are trying to pretend it doesn't matter. If it doesn't matter for you that's fine, but I do not use software written by people who don't take security seriously, and rails is one such piece of software.
And the developer knowing the quoting rules for the DB they are using has nothing to do with this, rails could and should prevent errors like this. Also that documentation did not exist at the time this happened, and it still doesn't excuse the attitude. There is no reason at all to make things potentially exploitable by default, and expect users to know enough to avoid the problems themselves. The whole idea of a web framework is so I don't have to worry about the details.
Okay, there is CRUD and then there are CRUD-screens.
Rails automates CRUD class generation. This is a popular and useful pattern. Rails has an outstanding implementation of this. It does have a few performance weaknesses, but they don't seem to inhibt many applications.
Rails also has a CRUD-screen generator set called "scaffolding". Scaffolding isn't really meant for production use. It's a nice way to force the app to get started. You then add things as you go, overiding the generated pages with real pages. It's unfortunate that many demos use scaffolding, because its really a very tiny part of Rails development.
The Rails framework does indeed auto-generate some other things. But they're extrmely generic.
Slashdot. It's Not For Common Sense
Rails comes with this. Indeed, it's preferred for many situations. The template method is best when you're not working with web designers who don't know any programming language and want to make mockups.
It's called XML::Builder, and it's pretty neat. Check it out at this link.
It's nice for generating "Semantic Web" markup.
Slashdot. It's Not For Common Sense
Go to the site, click "Try Basecamp Free" and set up a free account. The external stuff is PHP, probably for legacy reasons.
Basecamp itself is 100% ruby-on-rails, and it's easy to verify once you enter the webapp.
OK, I'm a programmer, I've used database, I've used high-level languages (Perl), and I've done some web programming. And I've also read through a lot of the comments on this slashdot article, and I've read through several pieces of the tutorial at rubyonrails.com, and I read virtually the entire About page at rubyonrails.com (which had lots of comments about Rails and how wonderful it is).
After all that, I still have no idea what "Rails" is supposed to mean. Is it some kind of analogy? Am I supposed to think it's a kickass mechanism that makes Ruby really fly (productivity-wise), so that it's like Ruby is a high speed train on rails? Is it some kind of analogy to Struts? Does the term "Rails" signify that there is a framework that provides abstraction to conceptually support things? Or is it an analogy with transportation? Or maybe an analogy with +5VDC power supply rails?
Why does rubyonrails.com make it so hard for me, as a developer, to learn what it is that Rails does and what it promises to be? I get that it's an application environment for web programming that makes it easy to use Ruby to do some web programming tasks. But there are lots of environments and software systems that aim to make web programming easier, so that's not very useful information. What I want to know when I look at a site that is trying to promote some new thing is what that thing is. I want to know something more specific than "it helps you do web programming" without having to spend 2 hours going through the tutorial. So far all I can gather beyond "it helps you do web programming" is that it helps you do it in Ruby, and that it seems to involve databases (which not all web programming does, of course).
He very plainly and clearly pointed out that he doesn't have to repeat himself to make getter/setter methods in java, its less work than it is with ruby, because he doesn't do it at all, that's what your editor is for. Comparing the final output code isn't a fair comparison, because the java developer doesn't write all that code, lots of it is generated for him/her automatically.
Yes I did exactly what I said I'd do and a lot more. I keep having to explain things over and over again to you Rails activists, but you seem to be unable to understand anything that is only just slightly different from the concepts that you use.
and you still manage to let it be a hefty 340 lines in you awesome concise framework? You just confirmed that you never take the time to check ANY of your statements and just troll on senselessly in the direction of whoever is leading you. SAD! Btw, I'd wouldn't call Bla-bla a RIFE-optimised application at all. Quite the contrary in fact, almost nothing is used of the important features of RIFE. The application is so simple that you never get to leverage any of the benefits since there's never any data flowing around. They are all single actions. I'd rather call Ta-da optimized for Rails since you have your List Act which does all the list handling automatically in the framework. We don't consider CRUD operations a core feature, but will soon release RIFE/crud as a separate packages that address this without any code generation. Bla-bla List doesn't use any of that btw.
Oh, don't worry, I don't comment on your code with micro comparisons as Rails activists seem to love to do. I do comment on the fact that you only implemented 15% of the application and did none of the complicated stuff. /golfclap you just made a total jerk out of yourself, Matt McRay.
Last time I checked, I didn't win the contest (since I came out 300 lines more), but even more, I never did one. All I did was show Java developers that things can be concise and don't have to be totally convoluted. Which rules did I set? I faithfully cloned Ta-da List even though the 'Edit list' part is very stupid and I'll probably re-do it in-line in the GUI. I used Laszlo to build a separated application which has nothing to do with the server-side and merely interfaces with the REST API and interpretes the results that are sent back. It's sad that you don't seem to understa
Geert Bevin
Ruby is dead simple. Ruby on Rails is dead simple. It'll make you wonder why you bother with all of those other languages. /ME is looking forward to Ruby on Greased Rails, the optimised version. (-:
Got time? Spend some of it coding or testing
You can "bust out of it" essentially whereever you like and do whatever you like.
Twenty-five years ago when as a BASIC programmer (think C-BASIC, MBASIC, GWBASIC, sBASIC), I first saw C. It was a revolution. Variable scoping, easy recursion, inline ifs, direct access to all kinds of stuff. Now as a programmer of lots of languages (C, C++, Java, Python, PHP, PERL, BASH, GAWK, assorted BASICs and scripts, assorted assemblers, Forth, yadda yadda), Ruby evokes that same feeling of "Ah! So this is what was missing all along!"
Got time? Spend some of it coding or testing
So it's pretty clear that Ruby is a pretty good language to write web apps in. But I have a another think: Which languages works best for each problem domain? So far, I've gotten C/C++/Javascript/Java/C# sorted but the rest I'm kinda fuzzy about. I'm trying to sort these out regardless of architectural constraints. (Like IIS requiring VBscript or JScript) Feel free to flame if you think this list is totally off.
C: Good for device drivers and very small embedded work.
C++: Good for most embedded work, fast plugin work (ala Maya and Photoshop). Lots of UI architectures
(now with KDE xplatform, could be a good UI option but definitately not RAD)
Java: Fast servlets. Fast cross platform UI??
Javascript: clientsize webpages (duh!)
C#: Same as Java (fixes some of Java's problems though...), Will be default for windows UI development soon
Python: More robust servlets
Ruby: More robust servlets, weakly typed language makes for great RAD, it's where Javascript wants to go. Maybe UI option?
Effile: ?? no idea what functional languages are good for...
Haskill: ?? no idea
Lisp: I personally hate trying to think in it's reverse polish notation schemes. So no idea...
What do you think?
Ben Schleimer Life is like a sewer, what you get out of it depends on what you put into it.
Personally, I wouldn't have included these things. They were extracted into the framework.
Ooof. Why on earth the AC mentioned that app, I have no idea. taskTHIS! is an Ajax tech demo. It's not meant to be something competiting with Ta-da or Bla-bla. Please discard this comparison. Not to belabor any points, but no one argues that Rails does more than RIFE. Most certainly, RIFE can probably out-feature Rails on many different levels. Even when Rails hits 1.0, this will still probably be the case.What many Rails fans (and I think the AC above, in typicall trollish AC fashion) are trying to point out is that the end-all-be-all of a framework is not the result of terminal featuritis. Rails is great for small-to-medium kinds of project. Most of us are aware of this. When Rails is applicable, it's incredibly applicable.
When it's not, we still have RIFE. Rest assured that if Rails ever hits its limits for me, RIFE will be the first place I look (despite your obnoxious behavior, recently). Now, many of the Rails community (including myself) dislike Java strongly. But that doesn't mean we don't know it and aren't prepared to use it if we must.
So I for one thank you, Geert. You showed me an alternative. No stop being such a dick about it. If you're trying to say that DHH behaved innapropriately when he compared Bla-Bla to Ta-da, your point is not well-served by throwing a tantrum every time Rails gets some positive press. Take the moral high ground.
Slashdot. It's Not For Common Sense
I'm a developer not a DBA (Although I've installed Oracle and worked extensively with DB2).
As a developer with many projects that use databases, I'm generally of the opinion is use the database to do what databases do via ODBC. Access data, join tables etc and don't worry about it, let the database worry about the speed. Triggers and other neat DB stuff (usually only available through the DB companies own API) tends to make it hard to move to different databases (Lock in).
Also database are pretty reliable, but I've seen some bad failures with database code.
We hate that. We programmers want control.
Also note the article points out that RNR generates the tables for you. So optimization is a huge leap for those that don't want to create the tables themselves. Creating tables isn't hard but there is a method to table relationships.
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?
I do this:
yum install php-gd
wow, that was easy! Even if I wasn't using rpm packages, I could compile GD and dynamically load it.
Have you mods not seen this joke before? WTF has the new Ruby compiler got to do with Gentoo?
/me goes back to work in a bad mood
Seriously. This is flamebait/offtopic/unfunny all rolled into one. Possibly the worst post EVER on Slashdot.
Also, can you embed Python in HTML? (seems that the whitespace issue would cause a lot of problems with doing that)
no problem at all