|
Hi Scott,
There are several points to this, one of this being that actually handling the DB that size is so complex that it is a science of its own. To do what they achieve, FB must have queues between the data centers etc. that just is not sensible to cover in a framework like Grails. It would be like shooting sparrows with cruise missiles.
Regarding your initial questions, we are currently migrating some stuff froma historically grown spring app to a merge of grails and spring with a view on migrating the stuff by porting vertical bits to grails, moving in small increments from working system to working system till the porting is over. By this, I was able to see that Grails is impressively flexible. We now have our app running, it uses JAVA, iBatis, Spring, classical JSP, a servlet even, and currently this peacefully coexists with Gorm-backed GSP. We are not done, yet, but things look good. So much for JAVA interoperability.
Before that I did some toy projects on grails. There are gotchas, but not so many of them, I like the quality of the Grails docs, but I also know some people who would like even more. I do think it is sufficiently easy to learn grails when you are a JAVA person. The one big thing I did not find out by myself (memory leak on insertion of many huge records) I got helped by Graeme and Burt on this list.
One gotcha I found out with colleagues (which is a problem rails will highlight, too) is that some JAVA developers are used to find more stuff at compile time than a language as Groovy can permit you to find. For those people, learning grails actually requires some technique on how to avoid typos or render them more visible. I've seen people lose days on WebFlow stuff due to some typo. Reading error messages with a keen eye helps a lot.
Best, Wolfgang On Fri, Aug 5, 2011 at 8:14 PM, Scott Eisenberg <[hidden email]> wrote:
|
|
On Aug 5, 2011, at 10:50 PM, Müller, Wolfgang wrote:
I must say though, that the code completion in IntelliJ (and probably also STS), has come a long way. I'm really amazed by how much of my types IntelliJ is able to infer, even if I spreads lots of 'def's around. So I seldom need to spell something out by knowledge/documentation. Most of the time, code completion is available. Heck, even when I'm in a GSP, IntelliJ knows the type of my models from the controller! Never did that with Struts. And I get code completion even on attributes to self written taglibs, without a tld. Deeply impressed! Even though the compiler doesn't care, the IDE does. And then there are great tools like CodeNarc as well. Ronny |
|
In reply to this post by Scott6666
On 5 August 2011 18:52, Scott Eisenberg <[hidden email]> wrote:
> Critical questions: > * Does anyone know if it scales (and if so how to do so)? When I am Facebook size will I still be on Grails? Scaling doesn't matter. Ever. Period. Well, admittedly it does matter if you're Facebook, Google or Twitter. Chances are you aren't and chances are you'll never be so don't worry about scaling at all. If your company should become that large against all odds you'll use neither vanilla Rails nor vanilla Java but some homegrown stack. Having said that, Rails does scale better than Java / Grails when you're small because Java / Grails consumes more memory than Ruby / Rails. Rails can be hosted much cheaper in the beginning. However, hosting costs don't matter all that much if in return you get an environment you're comfortable with. > * Can I mix and match Grails with Java with Generics (and if so how do I learn)? Yes. > * Are there sufficient grails developers out there in case I want to expand the team (in DC area)? It depends. There are much fewer than Rails developers and they tend to be more expensive. There are much more Java developers than Rails developers on the other hand. If all of those are comfortable with Grails and web development might be a different story. -- Best regards, Björn Wilmsmann --------------------------------------------------------------------- To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email |
|
In reply to this post by Scott6666
<RANT> some of the criticism here seems to be made without thinking. he may be or may never be facebook size but what about the existing huge applications? developers would like grails and want to switch their huge applications to grails or mount a grails application into their existing ecosystem. shouldn't they worry about how things would go? how it'd perform? how it'd scale? let me explain it with an example. we are running a huge turkish portal here and i have built a real-time statistics application for it because we don't want to pay thousands of dollars to chartbeat each and every month. i needed it to be freaking huge and scaling because tens of thousands of requests flowing through main app is exactly coming to the statistics app as well. that app handles more than 35K requests per second. (no, i have not developed that application with grails or rails despite the fact that i love those tools because i needed the request flow as minimal as it can be so i have choosen pyramid [a python web framework] for that.)
another thing.. i saw official grails people and many grails developers suggesting to use java where performance matters. not all of us are java developers. not all of us are familiar with its ecosystem and technologies. i can be a python, ruby or php developer and want to switch to grails. why do i need to learn java and write java when i need my application to perform better? why are you making things worse for me? why are you turning me off? if i wanted to use java at all, i'd learn java and go directly with spring or tapestry. if groovy is not enough for grails then switch to something better and we all go that route. notes: - i don't just like groovy and grails, i love them. - groovy developers are working on making groovy perform as much as it can. i follow the progress and i appreciate that.
</RANT> now, i would like to give the OP some real-world advice and i will be grails specific where possible. - design your application first in paper or something, do not just start developing. when you realize you need more/better things than you have or can build things in a better way than you did, it will suck. so hard.
- is your application a database driven app? if so, keep everything minimal. if you have a one to one relationship or many to one relation ship, let's say with user and post, do not just add user_id field to your post table but also add the username field. that'll prevent joins. just a single query will do it then.
- are you going to have complex queries? try not to but if you fail, do write them in HQL. do not make GORM to generate those queries. - are you going to support a search functionality? don't hit the db for that. use an external tool. grails has an awesome plugin called "searchable" that uses lucene as its search engine which is cool.
- cache your data as much as you can. caching saves life. even better, you can generate static pages and render them and do the dynamic parts with ajax. however if your application makes you enough money, you can buy a netscaler and let it deal with those. it's awesome.
- write tests. test the hell out of it. grails 2.0 made the testing great. use a continous integration tool. many of us prefer hudson/jenkins. - hardware is very very important.
- freebsd is awesome for a web server. p.s. the grails community is awesome. none of your questions will go unanswered. both on irc and the ml. i can't say the same thing for groovy but when you have questions you can try the ML. it'll be answered. wherever possible. :) 2011/8/5 Scott Eisenberg <[hidden email]> I know this is a bit like kicking a hornet's nest but... |
|
Wow. Thanks for all the info. PS. My daughter is visiting Turkey now. I gather she's loving it there. On Aug 6, 2011, at 7:28 PM, "Muhammet S. AYDIN" <[hidden email]> wrote:
|
|
In reply to this post by Scott6666
Hi Scott, I guess I'm a bit late at the party but I think I can add some
points that will be hard to find in this list, as most developers here, differently from me, love Grails. While answering to your message, the answer became too big that I decided to write an article comparing Grails to Rails instead. It's far from a complete review but was based in the response I was going to send to you. I hope it could be useful though: http://rosenfeld.heroku.com/en/articles/programming/2011-08-07-why-i-prefer-rails-over-grails Cheers! Rodrigo. Em 05-08-2011 13:52, Scott Eisenberg escreveu: > I know this is a bit like kicking a hornet's nest but... > > I'm starting a project and I want to know if I should use Grails or ROR. I've been watching and playing with Grails since the 1.x days and wonder if the framework is secure enough to use for a real, large scale, project. > > Critical questions: > * Does anyone know if it scales (and if so how to do so)? When I am Facebook size will I still be on Grails? > * Can I mix and match Grails with Java with Generics (and if so how do I learn)? > * Are there sufficient grails developers out there in case I want to expand the team (in DC area)? > * Are the GORM Gotchas either fixed enough or documented enough for me to understand what will look like errors as I try to learn associations? > * Is VMWare really behind this framework? > * Does VMWare provide paid support if I need it? Does anyone else. > * Is it too buggy to be happy with? > > I sense there is enough Rails history and community that if I need help I can get it. Not so sure with Grails. I see a lot of simple (and complex) issues on this mailing list that don't seem to be answered that I have concerned. That said, I don't know ROR that well and would be starting from scratch learning it and getting into the communities. For all I know it has the same issues I perceive Grails to have. > > Thanks in advance for any guidance. --------------------------------------------------------------------- To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email |
|
In reply to this post by Scott6666
> I'm starting a project and I want to know if I should use Grails or ROR. I've been watching and playing with Grails since the 1.x days and wonder if the framework is secure enough to use for a real, large scale, project.
> > Critical questions: > * Does anyone know if it scales (and if so how to do so)? When I am Facebook size will I still be on Grails? The problem with asking whether something scales is that it's akin to "how long is a piece of string". Which bit of the system needs to scale? Is the datastore going to be the limiting factor? Or the request processing? Can you use caching of the HTML pages or do these need generating for every request? Note that you can scale your web application by clustering servlet containers. As far as I'm aware, there's nothing in Grails that will cause issues. You just have to be aware that you need to keep your HTTP session as small as possible. > * Can I mix and match Grails with Java with Generics (and if so how do I learn)? > * Are there sufficient grails developers out there in case I want to expand the team (in DC area)? > * Are the GORM Gotchas either fixed enough or documented enough for me to understand what will look like errors as I try to learn associations? There is an open issue to get these into the user guide. > * Is VMWare really behind this framework? Yes. > * Does VMWare provide paid support if I need it? Does anyone else. Yes. Regards, Peter -- Peter Ledbrook Grails Advocate SpringSource - A Division of VMware --------------------------------------------------------------------- To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email |
|
In reply to this post by Mengu
Responses inline a bit further down...
> <RANT> > some of the criticism here seems to be made without thinking. he may be or > may never be facebook size but what about the existing huge applications? > developers would like grails and want to switch their huge applications to > grails or mount a grails application into their existing ecosystem. > shouldn't they worry about how things would go? how it'd perform? how it'd > scale? > let me explain it with an example. we are running a huge turkish portal here > and i have built a real-time statistics application for it because we don't > want to pay thousands of dollars to chartbeat each and every month. i needed > it to be freaking huge and scaling because tens of thousands of requests > flowing through main app is exactly coming to the statistics app as well. > that app handles more than 35K requests per second. (no, i have not > developed that application with grails or rails despite the fact that i love > those tools because i needed the request flow as minimal as it can be so i > have choosen pyramid [a python web framework] for that.) With response caching or not? Are you sure Grails and Rails (particularly JRuby on Rails) can't handle that amount of traffic with enough application instances? Scaling is too scenario-dependent to give a general answer to the question unfortunately, although it would be useful to have some metrics as to how much traffic certain applications are handling with how many instances, what type of caching etc. But much of that may be confidential. > another thing.. i saw official grails people and many grails developers > suggesting to use java where performance matters. not all of us are java > developers. not all of us are familiar with its ecosystem and technologies. > i can be a python, ruby or php developer and want to switch to grails. why > do i need to learn java and write java when i need my application to perform > better? why are you making things worse for me? why are you turning me off? How do you make your Ruby and Python applications run faster? The recommendation to fall back to Java only applies when Groovy is identified as being the bottleneck, which only happens when you're trying to do some heavy duty, in-memory work. Perhaps the "fall back to Java" argument is given out too loosely so that it appears Groovy doesn't perform well. And you can always take a look at Groovy++ if you have identified a bit of Groovy code that is a bottleneck. But how many people have identified Groovy code as the bottleneck in their applications? That's a genuine question, so if people have specific examples, I'd be happy to hear them. Regards, Peter -- Peter Ledbrook Grails Advocate SpringSource - A Division of VMware --------------------------------------------------------------------- To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email |
|
On Aug 8, 2011, at 11:49 AM, Peter Ledbrook wrote: > But how many people have > identified Groovy code as the bottleneck in their applications? That's > a genuine question, so if people have specific examples, I'd be happy > to hear them. The only Groovy-related bottleneck I have experienced, is trying to create a more than super-trivial XML with XMLBuilder. Ref: http://grails.1312388.n4.nabble.com/XMLBuilder-very-cpu-intensive-tt2280915.html Didn't receive any replies to the question, but it wasn't a show stopper, as there are other alternatives for creating XML. I didn't even need to fallback to Java. Ronny --------------------------------------------------------------------- To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email |
|
tldr: Java ecosystem good. Should you? Definitely Maybe. I've liked it. Give it a try and see what happens. You can always tweak the generated bits of architecture yourself and remove Grails from the equation later.
Not so tldr; Following up on Peter's point about scaling, let's not forget that Grails targets J2EE containers. I know Rod Johnson started Spring as a renaissance away from "heavy-weight beans" and a lot of the unnecessary cruft that made it into J2EE, but that doesn't take away from other a lot of good initiatives that made it into J2EE architecture, such as JPA, JMS that are worth mentioning and discussing. J2EE has been harped on for years for being overly-complex. A lot of that complexity arose out of trying to take care of "enterprise class problems." Issues such as concurrency control, ACID properties, and lot of other "scaling considerations" were specifically considered, discussed, and designed around in the architecture. Whereas other initiatives (my home-brewed index.php that I want to turn into Facebook) have to "reinvent the wheel" and discover most of the lessons learned themselves, J2EE has many of those considerations baked in.
So while a legacy J2EE application for writing my blog's home page may be using a cannon to swat a fly, if I _were_ trying to build Facebook, I'd want to do it on a proven architecture that has had Better Minds Than Mine (a hard thing for any developer to admit) devote man-hours, sweat, and tears to worrying about all the scaling issues and baking that it.
This is why Grails is so sexy. Because you get all the "ease of use" features of a framework like Rails, you get nicer OOP with ORM and scaffolding and sugar than you get from something like CodeIgniter, and you can develop small applications quickly. But even better than all that, when your enterprise wants to go PrimeTime, you've got the entire Java ecosystem to work with, and much work has gone into performance (in fact, IBM's alpha Java compiler achieves the same performance as FORTRAN http://www2.informatik.uni-erlangen.de/publication/download/javaCS.pdf), scalability, extensibility, etc etc etc.
That said, as Peter Delahunty said "Grails is the Iron Man Suit for the Java developer" (http://blog.peterdelahunty.com/2009/10/grails-iron-man-suit-for-tony-stark.html). If you don't know Java and you don't want to learn it, the framework is probably not for you. It's an enabling tool that builds upon previous successes (which means that yes, you should read some and know about other Java initiatives Hibernate, Spring's Dependency Injection, etc) and "super charges them" to eliminate unnecessary cruft (XML configuration) and keep you on "just the stuff", while giving you the option to "get your hands dirty when necessary."
Other languages are evolving, and quickly (.NET basically copied Java but got lambdas into the framework a lot faster than Java 7), and many things they do make Java look quaint. I got a rude shock as to just how sparse JUnit is recently, as I was writing a Grails Unit test case and assuming the same conventions available in NUnit were available to me, only to discover that although both are part of the "xUnit" family there's little unity within the family, and NUnit "felt more powerful." But even Pythoners and Rubyists are running into "enterprise level issues" that were solved in the community ten years ago, and IIS is considered by many I've talked to as a "not fun" deployment and maintenance experience.
Should you use Grails? It seems to me better than other Java offerings (JSF, hand rolling Spring MVC) because Groovy takes all the fun of dynamic languages and makes it Java (Groovy is essentially a superset of Java, aside from esoteric things like nested classes), though that "fun" can sometimes lead to unexpected results for the static time developer.
How does it compare to other web frameworks? Depends on your familiarity with the language and ecosystem.
I'm not personally familiar with developing on the Rails ecosystem so I can't make that comparison, but I know many of the most prominent SW Engineering minds (Fowler, Hunt & Thomas, dhh) love Rails and migrated to it from Java, seemingly pre-Groovy. Rails really established the "best of breed" for convention over configuration, the use of design patterns (ActiveRecord, etc), TDD/BDD, and in many ways is the most "disruptive and innovative" web framework, from the outside looking in. The Sharp Architecture was the most evolved form of architecture I've seen from the .NET community, which often panders to lowest common denominator programming and is still wrestling with concepts like MVC and Services. Version 1.0 was nascent and a "good attempt", but I often found myself coming back to my Grails knowledge (I learned Grails first) and trying to make Sharp more like Grails. Django's MVT seemed really cool when I was really into Python in 2005-2007, but I've gotten away from it in the past few years and now I hear horror stories. The most evolved thing I've seen in PHP is CodeIgniter, though I hear tales of CakePHP and other frameworks that are trying to "formalize PHP architectures", but I find that a laughable idea. I'm heavily biased against PHP though, as I have strong opinions on the immaturity of its language design versus other paradigms.
I'd say Rails and Grails are leading the pack. But familiarity and paying attention to your professional context tend to bias you. Your results may vary. On Mon, Aug 8, 2011 at 4:34 AM, Ronny Løvtangen <[hidden email]> wrote:
|
|
I thought Rails has performance issues comparing to java for example. Perhaps things has changed since last time I checked...
On Mon, Aug 8, 2011 at 5:36 PM, Nick Vaidyanathan <[hidden email]> wrote: tldr: Java ecosystem good. Should you? Definitely Maybe. I've liked it. Give it a try and see what happens. You can always tweak the generated bits of architecture yourself and remove Grails from the equation later. |
|
Major downside: To many gotchas which is the most time costing aspect of Grails. Especially when you start fiddling with GORM and domains.
Anyone tried the Play! framework? It's starting to look more and more interesting because of it's static nature. I think I might give it a try in the coming project.
On Wed, Aug 10, 2011 at 11:38 PM, Octavian Covalschi <[hidden email]> wrote: I thought Rails has performance issues comparing to java for example. Perhaps things has changed since last time I checked... |
|
In reply to this post by Octavian Covalschi
On 10 August 2011 23:38, Octavian Covalschi
<[hidden email]> wrote: > I thought Rails has performance issues comparing to java for example. > Perhaps things has changed since last time I checked... No, it hasn't. Never had. -- Best regards, Björn Wilmsmann --------------------------------------------------------------------- To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email |
|
Wow ... Do you think use of such absolutes is justified ? I think one should be careful to assess such statements. Everything has performance issues when the scale gets going.
Sent from my iPhone On Aug 11, 2011, at 9:32 AM, Björn Wilmsmann <[hidden email]> wrote: > On 10 August 2011 23:38, Octavian Covalschi > <[hidden email]> wrote: >> I thought Rails has performance issues comparing to java for example. >> Perhaps things has changed since last time I checked... > > No, it hasn't. Never had. > > -- > Best regards, > Björn Wilmsmann > > --------------------------------------------------------------------- > To unsubscribe from this list, please visit: > > http://xircles.codehaus.org/manage_email > > --------------------------------------------------------------------- To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email |
|
You should use Grails. I've found it to be a very productive and rewarding framework.
On Thu, Aug 11, 2011 at 5:47 PM, Arun Ramakrishnan <[hidden email]> wrote: Wow ... Do you think use of such absolutes is justified ? I think one should be careful to assess such statements. Everything has performance issues when the scale gets going. |
|
In reply to this post by Octavian Covalschi
Em 10-08-2011 18:38, Octavian Covalschi escreveu:
> I thought Rails has performance issues comparing to java for example. > Perhaps things has changed since last time I checked... I never understood this. I've never seen a real-case application benchmark with the most common features included in the application, including security restrictions, etc. Micro-benchmarks is all that I see, but are completely useless. Also people are concerning too much about framework or language performance when most performance issues are solved with the correct architecture rather than the correct language or framework. Also, the ability to scale is much more important than the raw performance itself. And infra-structure configuration is usually as important as well. Also, most people are concerned about performance much before it gets to be really an issue. Also, it's common to see too much pre-optimization. It's much more important for most projects that the code should be clean and well tested (read automate tests) and that stories should be completed as fast as possible. Believe-me: it is always possible to optimize for performance later when it starts becoming an issue. And you shouldn't do that before a real profiling to see what exactly could be improved. Regarding Rails vs Java, it will depend. Of course, Java being a compiled language, and Ruby being one of the slowest interpreted languages out there, the same for/while algorithm will performs much better in Java. But if you find yourself writing everything from scratch on Java, and it happens to exists some gem for Ruby to do the same amount of work, chances are that the gem will be optimized and maybe your Ruby application will outperform your custom Java code. This is just an example. If we just had a real application to compare instead of micro-benchmarks... In the other side, when I say that performance depends much more on the architecture, if you compare Redmine, which was written in Ruby using the Rails framework and compare it to Jira, Redmine feels much faster and user-friendly for the end user. This has nothing to do with raw performance but to several kinds of optimizations, like user-interface, and overall architecture (use of AJAX, and other Javascript optimization techniques, small HTML, etc). Usually, when working in a higher-level language, it is easier to write a better architecture and compensate the raw performance lost. --------------------------------------------------------------------- To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email |
|
In reply to this post by Arun Ramakrishnan
Yes, absolutely.
I agree, every language or framework has perform issues. However, Rails has no performance issues when compared with Java (aside from the fact that a comparison between a framework with a language / runtime environment is somewhat skewed). There simply is no easy way to tell because what are you going to compare? Low-level benchmarks don't matter in terms of web application development. Unless there's a fundamental flaw in how the language was designed you simply can't make statements like that. I know Java people sometimes love to gloat about Twitter having changed their Rails app to use a Scala / Java / Solr backend because they had massive performance problems. There are two things to note about this, though: 1. Their original architecture was flawed anyway. Building a massive n:m messaging system using ORM would have also failed with Java / GORM. 2. Had they tried to build Twitter with the tools available for Java at that time (Grails didn't even exist at that time.), I'm pretty sure none of us would've heard of Twitter because it would've taken them exponentially more time to get their web app done. On 12 August 2011 00:47, Arun Ramakrishnan <[hidden email]> wrote: > Wow ... Do you think use of such absolutes is justified ? I think one should be careful to assess such statements. Everything has performance issues when the scale gets going. > > Sent from my iPhone > > On Aug 11, 2011, at 9:32 AM, Björn Wilmsmann <[hidden email]> wrote: > >> On 10 August 2011 23:38, Octavian Covalschi >> <[hidden email]> wrote: >>> I thought Rails has performance issues comparing to java for example. >>> Perhaps things has changed since last time I checked... >> >> No, it hasn't. Never had. -- Best regards, Björn Wilmsmann --------------------------------------------------------------------- To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email |
|
In reply to this post by Arun Ramakrishnan
On Fri, Aug 12, 2011 at 12:47 AM, Arun Ramakrishnan <[hidden email]> wrote: Wow ... Do you think use of such absolutes is justified ? I think one should be careful to assess such statements. Everything has performance issues when the scale gets going. Good said. I believe Rails had concurrency issues because it wasn't designed to handle big traffics. Something about improper use of shared global variables. Sent from my iPhone |
It's very interesting how people like FUD. If they can't argue technically they appeal to FUD. And the reason to that is that FUD works unfortunately because people are too lazy to do their own benchmarks. They start statements with "I believe...", "I've read that...", "It's well known that...". People should really take some time for demonstrating what they're saying. There are great tools out there like ab (Apache Benchmark) that will easily allow one to make their point. Also they should provide the source code so that real developers of those languages and frameworks will be able to tell you how you can improve your code for giving better throughput, faster responses and increase the traffic it can handle. Statements like "Rails wasn't designed to handle big traffics" is pure non-sense. Or could you prove me wrong? Where did you take this information from? "Something about improper use of shared global variables": can you give me a single example for that? I guess not. So, please don't spread FUD. Let's discuss concrete examples, like I've done here: http://rosenfeld.heroku.com/en/articles/programming/2011-08-07-why-i-prefer-rails-over-grails |
|
The bottom line is: Write the system using whatever you want. It
doesn't really matter. Most of the time we're writing Information Systems to *support* a business. The business is much more important than the system per se. You can rewrite/readapt the system later, when the business become profitable. IMHO, there are points that seem immature in Groovy and Grails. Sometimes I do spend time with gotchas (I'm not criticizing the teams, I think they are doing a very good job). Despite the problems, for me as a Java/J(2)EE developer, Groovy/Grails seems to be the best available option right now. Simple as that. My 2 cents. Best regards, Daniel. Rodrigo Rosenfeld Rosas wrote: > Em 12-08-2011 06:33, Mohamed Seifeddine escreveu: >> On Fri, Aug 12, 2011 at 12:47 AM, Arun Ramakrishnan >> <[hidden email] <mailto:[hidden email]>> wrote: >> >> Wow ... Do you think use of such absolutes is justified ? I think >> one should be careful to assess such statements. Everything has >> performance issues when the scale gets going. >> >> >> Good said. I believe Rails had concurrency issues because it wasn't >> designed to handle big traffics. Something about improper use of >> shared global variables. > > It's very interesting how people like FUD. If they can't argue > technically they appeal to FUD. And the reason to that is that FUD > works unfortunately because people are too lazy to do their own > benchmarks. > > They start statements with "I believe...", "I've read that...", "It's > well known that...". People should really take some time for > demonstrating what they're saying. There are great tools out there > like ab (Apache Benchmark) that will easily allow one to make their point. > > Also they should provide the source code so that real developers of > those languages and frameworks will be able to tell you how you can > improve your code for giving better throughput, faster responses and > increase the traffic it can handle. > > Statements like "Rails wasn't designed to handle big traffics" is pure > non-sense. Or could you prove me wrong? Where did you take this > information from? "Something about improper use of shared global > variables": can you give me a single example for that? I guess not. > So, please don't spread FUD. Let's discuss concrete examples, like > I've done here: > > http://rosenfeld.heroku.com/en/articles/programming/2011-08-07-why-i-prefer-rails-over-grails > --------------------------------------------------------------------- To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email |
| Powered by Nabble | Edit this page |
