Django was open sourced in 2005 while Rails was open sourced in 2004, and yet Django still isn't at Rails's popularity of 1 year ago.
"It also has a more muted philosophy of hype"
Sure, but is that a good thing? Marketing is important. Programmers too often underestimate the value of marketing. If Microsoft never marketed then it wouldn't have 95% market share on the desktop. If Apple never marketed then there would be a lot less OS X/Ipod/Iphone users.
But more importantly: marketing/hype creates the opportunity for you to convince your boss or client that your choice of framework is justified. I like Ruby on Rails. You like Django. If your boss or client has never heard of RoR/Django then he's going to be reluctant about letting you do the job. After all, if a framework is not well-known then he'll have a hard time finding new and cheap system administrators or developers to maintain the website after you've left. Then you're either forced to use Java 2 Enterprise Edition or forced to seek a new job.
The content is generated from text that's formatted in a special language, and the text may or may not include code that needs to be syntax highlighted. The parsing and generation is pretty heavyweight.
I'm writing a Rails application right now. It ran at 0.8 requests/sec in production mode. Then I spent 15 minutes on implementing fragment caching in my app, and my performance jumped to 40 requests/sec. And I'm not even done optimizing yet. Using Phusion Passenger and Ruby Enterprise Edition gives you additional performance boosts and memory reductions.
I don't know how much you know about Ruby on Rails, but it can do all those things you mentioned by default, exception auto admin interface and i18n. For auto admin interface there's ActiveScaffold, and for i18n there are a number of third party plugins.
Then where are the Django killer apps? No seriously, where are they? I can't find more than a hand full of Django apps. And when I asked this question on #django and #python, multiple times, nobody - not even a single person - could tell me even one killer app written in Django. If Django is so great then where are the apps?
Bah, of all the things that one can complain about, you complain about the version number? I thought version numbers in open source projects don't matter?
"Your "provocative" posts are probably counterproductive if your intent is to get X.org some more community contribution. Legitimate complaints met with 'fix it yourself' are what push people to OSX."
Then how else do you want to solve the problem? *Someone* has to do the work.
"I don't understand how the maturity level of the user base has anything to do with how a company reacts."
Because you can't trust the user base to handle appropriately even when you do the right thing. In other words: *not* banning those people makes the situation even worse.
"I wonder if any large MMO company will ever be brave enough to calmly address an issue rather than wielding the ban-hammer."
I doubt it. But this is not without a good reason.
Many, many MMORPG players are 13 year old kids. Immature kids. These people are not adults. They do not behave like adults. If the company "calmly addresses the issues", then they'll be flooded by complainers, cheaters and opportunists within no time.
I've been involved in MMORPG for several years. The immaturity in MMORPG communities in general is just sad. There doesn't seem to be any good way to handle issues other than ruling with iron fist.
Relax man, you sound like we're some kind of zombies that you're obligated to kill.
Did you miss my sentence in which I said JRuby has great threading support? You had a legit complaint about threads, and it's been solved in one of the Ruby implementations. What is the problem? You suddenly started calling us "shit" and "stink"?
Not so with the new Rails deployment solution that will soon be released. Tests so far has shown that it reduce memory usage in your Rails apps by 33% on average. It also makes Rails deployment easy as cake - only uploading files is required. No manual port management, no manual cluster management, no manual Rails-specific configuration. Resource usage is automatically adjusted to traffic.
If you're interested, I can provide you with more information.
"dhh confirmed the 400 restarts as they were running out of memory."
Yes I read that. Someone commented that the quote was taken out of context, and that there was some system problem involved.
We can argue about what *really* happened all day long, but let's take a look at the facts: Rubyonrails.org is online. The 37signals website is online. Basecamp is online. All *my* Rails apps are online. None of them are showing symptoms of 400 restarts per day, or even multiple restarts per day. 37signals is still in business. Empirical evidence clearly shows that, whatever problem it was, it's either been solved, or it isn't as bad as Zed claims it to be. If all Rails app need multiple restarts per day, why do you think so many people are still eager to learn Rails?
"btw. Rails is not thread safe."
Correct. Though so far I haven't felt the need for it to be.
"Nor does ruby have native threads."
Correct. It implements green threads aka userspace threads.
"That is *very* different than other languages/frameworks."
Not so. PHP has no threads *at all*, but I don't see anybody complaining that PHP doesn't scale because it has no threads. I have no idea why people don't complain about that, and asking them why yields no useful answers, but my guess is that because mod_php hides concurrent request handling from the administrators, they've never felt the need to spread FUD.
Perl has native threads, but it's quite laughable. Thread creation takes 15 seconds (!) on a moderately large Perl app, and it crashes straight after. Python has native threads, but it uses a Giant Interpreter Lock, so only 1 Python thread can be run concurrently. Ruby 1.9 also supports native threads, and like Python it has a Giant Interpreter Lock. Are Perl and Python useless because they don't support truly concurrent native threads? Many people would say no, and evidence can be found in the fact that those two languages are widely used.
So let's see: Rails naysayers claim that native threading support in Ruby is what prevents Rails from scaling. Nobody complains that Django doesn't scale, yet Python has a Global Interpreter Lock. Coincidence? I don't think so. To me, this proves that a lot of people are blindly buying negative information, and once they have, they refuse to change their mind even when presented with new information.
Java has great threading support, I'll give you that. If you really need native threads, you can use JRuby. It's built on Java and provides the same great support for threads. JRuby can even run Ruby on Rails.
Rubinius is already copy-on-write friendly. Yukihiro Matsumoto has shown interest in my patch, and I'm currently trying to get it merged back to upstream.
Zed Shaw did say that, but we don't know whether that claim was taken out of context. Maybe 37signals had a hardware problem. Or maybe an OS update b0rked their kernel. Or whatever. I've been running a business Rails app for 1.5 years now, and it's been stable ever since. I've never had to restart it. I've studied the internals of Rails and I don't see any fundamental flaws which prevents it from being stable.
Your claims are similar to that of a lot of other naysayers. There's obviously a lot of misinformation around. But come on, 400 restarts day: that's ridiculously unacceptable for even the biggest Rails zealot, isn't it? Think about it for a moment: if it was true then 37signals would be out of business now. The fact that they aren't, proves that something about that claim isn't entirely right. I'm not asking you to believe the hype, but the least you should do is to be critical to all Rails information, whether positive or negative. It seems that, right now, you're accepting all negative information without thinking about whether they're really true or whether they're relevant to you.
Is (the absense of) fastthread related to the 400 restarts a day? Maybe, maybe not. I doubt it, because Rails has never used threads.
That said: nothing prevents one from running threads in a Rails application server. You just have to be careful about what you do in your threads and make sure you don't run into racing conditions. And this is - guess what - no different than any language/framework! The developers must know what they're doing.
You do have one legitimate complaint: administration. There are too many steps involved right now. Although I don't think deployment and administration is too hard (I learned it in a week), it seems that people have the perception that it is hard and don't want to/can't learn how to do it properly. An upcoming Rails deployment/administration system will solve just that. It'll turn Rails deployment and administration into a nearly zero-maintenance effort.
The timeout() implementation is a problem, but it's the only reasonable way to implement it, in ANY language. Using it means that the programmer has to be aware of potential issues, like any other use threading. That said, the places in which I use timeout() have been carefully reviewed that no racing conditions can occur. Boring isn't it, to know that all languages have the same issues?
As for processes vs threads: where did you get the idea that a process is more heavyweight than a thread? Modern Unix operating systems allow different processes to share memory, and this has been the case for several decades. Please, go read a good book on operating systems design, in particular about the topics "memory paging" and "copy on write".
For example: suppose your application uses 500 MB memory. If you fork() a new process, then the total memory usage is not 1 GB, but something like 500.01 MB. When used correctly (which isn't a hard things to do), processes can be as lightweight as threads, with the added benefits that they can't crash each other. In fact, an upcoming Ruby on Rails deployment solution will make use of this fact, resulting in dramatically lower memory usage.
Re:Chapter 10 - Large Projects
on
Advanced Rails
·
· Score: 1
"Brutally honest" huh? Neither articles give a lot of details. Based on the given information in the articles, they might just as well have failed because their developers are incompetent. Oh, and you're posting as AC. That says a lot.
Indeed, it doesn't have to. Yet practice shows that many, if not most, open source developers these days are interested in using open standards, more so than closed source software developers. It is no guarantee, but on average, it is the case. That is the whole point.
That's why you're supposed to use multiple Rails processes. Multiprocessing is functionally no different from multithreading, except for the fact that processes don't share memory with each other, so if 1 Rails instance crashes the others are still alive.
FYI, an Apache worker process can also handle 1 request at the same time. And Apache solves that by... spawning multiple Apache worker processes!
Wait a minute, first you people boast about being able to run Windows on a Mac, which is *unsupported*, and now you mod down OSX86 on the PC because it is unsupported? Talk about being hypocritical.
Re:So when do we get its successor?
on
X Power Tools
·
· Score: 1
Have you ever actually read the "criticisms"? If you did, then you'd notice that almost each and every time, people only say "fix it yourself" if the criticism isn't constructive.
99.9% of the X "criticisms" are some form of "X is old and sucks and must die". They add no value whatsoever other than potentially making people angry. What part of their "criticisms" is constructive? I'm a programmer, I have the ability to improve X, and I might even do it for free. But every time I read "criticisms" like this I fail to understand what exactly it is that they're criticizing. As a programmer, not only do I have no idea what I can do after reading their comments, their comments generate some kind of anger and frustration because of the way they're written.
So what can I do? I suppose I can spend 3000 hours into studying X, only to find out that the "criticizers" are wrong. I would have wasted 3000 hours of my life for the sake of some anonymous Slashdotter that I don't even know!
You say the "fix it yourself" responses are boorish and irritating. That is a very selfish thing to say. Do you think the "X sucks and must die" comments, which contain absolutely no constructive information, aren't equally, if not more, boorish and irritating? So for some reason you are allowed to bore and irritate the programmers - who give you their work for free -, but not vice versa?
Re:My only suggestion for motorists.
on
X Power Tools
·
· Score: 1
Re:Entitlement Complex in Open Source Software
on
X Power Tools
·
· Score: 1
Sure you can discuss it. But he wasn't discussing - he was whining. It was mindless complaints with absolutely no constructive criticism whatsoever. It serves no purpose other than to potentially discourage the people who actually want to improve it.
Slashdot Mirror
Django was open sourced in 2005 while Rails was open sourced in 2004, and yet Django still isn't at Rails's popularity of 1 year ago.
"It also has a more muted philosophy of hype"
Sure, but is that a good thing? Marketing is important. Programmers too often underestimate the value of marketing. If Microsoft never marketed then it wouldn't have 95% market share on the desktop. If Apple never marketed then there would be a lot less OS X/Ipod/Iphone users.
But more importantly: marketing/hype creates the opportunity for you to convince your boss or client that your choice of framework is justified. I like Ruby on Rails. You like Django. If your boss or client has never heard of RoR/Django then he's going to be reluctant about letting you do the job. After all, if a framework is not well-known then he'll have a hard time finding new and cheap system administrators or developers to maintain the website after you've left. Then you're either forced to use Java 2 Enterprise Edition or forced to seek a new job.
The content is generated from text that's formatted in a special language, and the text may or may not include code that needs to be syntax highlighted. The parsing and generation is pretty heavyweight.
I'm writing a Rails application right now. It ran at 0.8 requests/sec in production mode. Then I spent 15 minutes on implementing fragment caching in my app, and my performance jumped to 40 requests/sec. And I'm not even done optimizing yet. Using Phusion Passenger and Ruby Enterprise Edition gives you additional performance boosts and memory reductions.
I don't know how much you know about Ruby on Rails, but it can do all those things you mentioned by default, exception auto admin interface and i18n. For auto admin interface there's ActiveScaffold, and for i18n there are a number of third party plugins.
"And it's better than Rails."
Then where are the Django killer apps? No seriously, where are they? I can't find more than a hand full of Django apps. And when I asked this question on #django and #python, multiple times, nobody - not even a single person - could tell me even one killer app written in Django. If Django is so great then where are the apps?
Bah, of all the things that one can complain about, you complain about the version number? I thought version numbers in open source projects don't matter?
Oh yes it is.
"Your "provocative" posts are probably counterproductive if your intent is to get X.org some more community contribution. Legitimate complaints met with 'fix it yourself' are what push people to OSX."
Then how else do you want to solve the problem? *Someone* has to do the work.
By your definition, Ruby is most definitely *not* weakly typed:
a = 1 # an Integer object
b = "2" # a String object
a + b # *boom*, *crash*, can't add a string to an integer
JavaScript on the other hand is weakly typed:
a = 1
b = "2"
a + b // 3
Just resize your browser window?
"I don't understand how the maturity level of the user base has anything to do with how a company reacts."
Because you can't trust the user base to handle appropriately even when you do the right thing. In other words: *not* banning those people makes the situation even worse.
"I wonder if any large MMO company will ever be brave enough to calmly address an issue rather than wielding the ban-hammer."
I doubt it. But this is not without a good reason.
Many, many MMORPG players are 13 year old kids. Immature kids. These people are not adults. They do not behave like adults. If the company "calmly addresses the issues", then they'll be flooded by complainers, cheaters and opportunists within no time.
I've been involved in MMORPG for several years. The immaturity in MMORPG communities in general is just sad. There doesn't seem to be any good way to handle issues other than ruling with iron fist.
Relax man, you sound like we're some kind of zombies that you're obligated to kill.
Did you miss my sentence in which I said JRuby has great threading support? You had a legit complaint about threads, and it's been solved in one of the Ruby implementations. What is the problem? You suddenly started calling us "shit" and "stink"?
Correct. *Mongrel* uses 20 MB per process. ;)
Not so with the new Rails deployment solution that will soon be released. Tests so far has shown that it reduce memory usage in your Rails apps by 33% on average. It also makes Rails deployment easy as cake - only uploading files is required. No manual port management, no manual cluster management, no manual Rails-specific configuration. Resource usage is automatically adjusted to traffic.
If you're interested, I can provide you with more information.
"dhh confirmed the 400 restarts as they were running out of memory."
Yes I read that. Someone commented that the quote was taken out of context, and that there was some system problem involved.
We can argue about what *really* happened all day long, but let's take a look at the facts: Rubyonrails.org is online. The 37signals website is online. Basecamp is online. All *my* Rails apps are online. None of them are showing symptoms of 400 restarts per day, or even multiple restarts per day. 37signals is still in business. Empirical evidence clearly shows that, whatever problem it was, it's either been solved, or it isn't as bad as Zed claims it to be. If all Rails app need multiple restarts per day, why do you think so many people are still eager to learn Rails?
"btw. Rails is not thread safe."
Correct. Though so far I haven't felt the need for it to be.
"Nor does ruby have native threads."
Correct. It implements green threads aka userspace threads.
"That is *very* different than other languages/frameworks."
Not so. PHP has no threads *at all*, but I don't see anybody complaining that PHP doesn't scale because it has no threads. I have no idea why people don't complain about that, and asking them why yields no useful answers, but my guess is that because mod_php hides concurrent request handling from the administrators, they've never felt the need to spread FUD.
Perl has native threads, but it's quite laughable. Thread creation takes 15 seconds (!) on a moderately large Perl app, and it crashes straight after. Python has native threads, but it uses a Giant Interpreter Lock, so only 1 Python thread can be run concurrently. Ruby 1.9 also supports native threads, and like Python it has a Giant Interpreter Lock. Are Perl and Python useless because they don't support truly concurrent native threads? Many people would say no, and evidence can be found in the fact that those two languages are widely used.
So let's see: Rails naysayers claim that native threading support in Ruby is what prevents Rails from scaling. Nobody complains that Django doesn't scale, yet Python has a Global Interpreter Lock. Coincidence? I don't think so. To me, this proves that a lot of people are blindly buying negative information, and once they have, they refuse to change their mind even when presented with new information.
Java has great threading support, I'll give you that. If you really need native threads, you can use JRuby. It's built on Java and provides the same great support for threads. JRuby can even run Ruby on Rails.
That's me. You linked to my own blog. :)
Rubinius is already copy-on-write friendly. Yukihiro Matsumoto has shown interest in my patch, and I'm currently trying to get it merged back to upstream.
Zed Shaw did say that, but we don't know whether that claim was taken out of context. Maybe 37signals had a hardware problem. Or maybe an OS update b0rked their kernel. Or whatever. I've been running a business Rails app for 1.5 years now, and it's been stable ever since. I've never had to restart it. I've studied the internals of Rails and I don't see any fundamental flaws which prevents it from being stable.
Your claims are similar to that of a lot of other naysayers. There's obviously a lot of misinformation around. But come on, 400 restarts day: that's ridiculously unacceptable for even the biggest Rails zealot, isn't it? Think about it for a moment: if it was true then 37signals would be out of business now. The fact that they aren't, proves that something about that claim isn't entirely right. I'm not asking you to believe the hype, but the least you should do is to be critical to all Rails information, whether positive or negative. It seems that, right now, you're accepting all negative information without thinking about whether they're really true or whether they're relevant to you.
Is (the absense of) fastthread related to the 400 restarts a day? Maybe, maybe not. I doubt it, because Rails has never used threads.
That said: nothing prevents one from running threads in a Rails application server. You just have to be careful about what you do in your threads and make sure you don't run into racing conditions. And this is - guess what - no different than any language/framework! The developers must know what they're doing.
You do have one legitimate complaint: administration. There are too many steps involved right now. Although I don't think deployment and administration is too hard (I learned it in a week), it seems that people have the perception that it is hard and don't want to/can't learn how to do it properly. An upcoming Rails deployment/administration system will solve just that. It'll turn Rails deployment and administration into a nearly zero-maintenance effort.
The timeout() implementation is a problem, but it's the only reasonable way to implement it, in ANY language. Using it means that the programmer has to be aware of potential issues, like any other use threading. That said, the places in which I use timeout() have been carefully reviewed that no racing conditions can occur. Boring isn't it, to know that all languages have the same issues?
As for processes vs threads: where did you get the idea that a process is more heavyweight than a thread? Modern Unix operating systems allow different processes to share memory, and this has been the case for several decades. Please, go read a good book on operating systems design, in particular about the topics "memory paging" and "copy on write".
For example: suppose your application uses 500 MB memory. If you fork() a new process, then the total memory usage is not 1 GB, but something like 500.01 MB. When used correctly (which isn't a hard things to do), processes can be as lightweight as threads, with the added benefits that they can't crash each other. In fact, an upcoming Ruby on Rails deployment solution will make use of this fact, resulting in dramatically lower memory usage.
"Brutally honest" huh? Neither articles give a lot of details. Based on the given information in the articles, they might just as well have failed because their developers are incompetent. Oh, and you're posting as AC. That says a lot.
Indeed, it doesn't have to. Yet practice shows that many, if not most, open source developers these days are interested in using open standards, more so than closed source software developers. It is no guarantee, but on average, it is the case. That is the whole point.
That's why you're supposed to use multiple Rails processes. Multiprocessing is functionally no different from multithreading, except for the fact that processes don't share memory with each other, so if 1 Rails instance crashes the others are still alive.
FYI, an Apache worker process can also handle 1 request at the same time. And Apache solves that by... spawning multiple Apache worker processes!
Wait a minute, first you people boast about being able to run Windows on a Mac, which is *unsupported*, and now you mod down OSX86 on the PC because it is unsupported? Talk about being hypocritical.
Have you ever actually read the "criticisms"? If you did, then you'd notice that almost each and every time, people only say "fix it yourself" if the criticism isn't constructive.
99.9% of the X "criticisms" are some form of "X is old and sucks and must die". They add no value whatsoever other than potentially making people angry. What part of their "criticisms" is constructive? I'm a programmer, I have the ability to improve X, and I might even do it for free. But every time I read "criticisms" like this I fail to understand what exactly it is that they're criticizing. As a programmer, not only do I have no idea what I can do after reading their comments, their comments generate some kind of anger and frustration because of the way they're written.
So what can I do? I suppose I can spend 3000 hours into studying X, only to find out that the "criticizers" are wrong. I would have wasted 3000 hours of my life for the sake of some anonymous Slashdotter that I don't even know!
You say the "fix it yourself" responses are boorish and irritating. That is a very selfish thing to say. Do you think the "X sucks and must die" comments, which contain absolutely no constructive information, aren't equally, if not more, boorish and irritating? So for some reason you are allowed to bore and irritate the programmers - who give you their work for free -, but not vice versa?
Don't know, don't care. It worked, and that's all that matters.
Sure you can discuss it. But he wasn't discussing - he was whining. It was mindless complaints with absolutely no constructive criticism whatsoever. It serves no purpose other than to potentially discourage the people who actually want to improve it.