I don't know that it's faster, I just meant that it's fast enough given the other advantages I mentioned. People seem to like in-process solutions, and I guess they would probably even use Webrick in production if its performance allowed it.
Note that even though I wrote fastthread, it was not aimed specifically at Mongrel/Rails. I've never been particularly personally involved with the Rails world, so take my comments as an outsider's observation rather than a recommendation.
I think the main reasons are performance and Mongrel offering a self-contained solution since it is implemented in Ruby (mostly) and runs the hosted application(s) in-process.
I think the rant is the product of such a realization. Although I would have said it differently, I think part of what Zed is getting at is that he pigeonholed himself by devoting all his energies to Mongrel when the web/Rails market wasn't a good place for him to be.
While I think Rails has some problems, it's important to draw a distinction between bugs in the Ruby standard library/interpreter and bugs in Rails. If it was just a Rails issue the hotfix for Ruby 1.8 (fastthread) wouldn't have resolved things. Note that other Ruby implementations (e.g. 1.9, JRuby) don't manifest the same issue and a fastthread equivalent is not required.
I think it's better if I don't comment on the rant itself. I think I can offer a little bit of general background information, though.
It's important to note that there is a distinction between the "classic" Ruby community (led by Matz), and the Rails community (led by DHH). Since Rails is built atop Ruby, Rails jobs are also Ruby jobs, but the two communities still have very different cultures.
Mongrel is a Ruby web application container mostly written in Ruby, except for the HTTP parser is written in C/Ragel. It has very good performance, and the Ragel state machine definition was derived directly from the BNF in the HTTP specification, so it also has extremely strict standards compliance. It became the most popular web application container for Rails. Since most of Mongrel is written in Ruby and most of the rest is in Ragel, we eventually got a JRuby/Java version of it too. These days Glassfish is becoming an increasingly popular substitute for Mongrel on JRuby, however.
fastthread is a Ruby library which "hot-fixes" the Ruby standard library to provide optimized versions of its thread synchronization primitives. It was mainly intended to improve performance, but as a side-effect it also worked around some long-standing bugs in the core Ruby classes which resulted in memory leaks and interpreter crashes under high load. Mongrel ended up requiring fastthread as a dependency because it was the only way to stably run a high-throughput application using the synchronization primitives on the 1.8 interpreter. fastthread is unnecessary on other Ruby implementations like Ruby 1.9 and JRuby.
Unless you're suggesting that developers make house calls, collecting that information still requires substantial (from a user's perspective) help from the user.
I think a lot of these discussions fail to clearly distinguish the map from the territory: scientific theories are approximate and merely descriptive (otherwise there would be no reason for science to continue to refine them), but when we talk about the "Laws of Nature", we are properly referring to the physical principles which those theories are intended to model, and against which our theories can be tested experimentally. It's pretty clear that these laws really exist, or else the results of experiments intended to explore them wouldn't converge.
The disputes that the articles have stirred up are mostly between three camps: those who think that the laws of nature can be accounted for by an infinite regression of physical laws, those who think the question of their source is unapproachable or meaningless, and those who think the existence of the laws can be accounted for in metaphysical terms.
I'd submit that creative freedom is more important to talented people, however. Speaking anecdotally, although all levels of talent are represented, I've encountered a much higher proportion of very talented programmers in Open Source than I have at work in the commercial/proprietary world. One of the reasons I'm as active in Open Source as I am is that I've found it's the best place to find talented programmers who I can learn from.
I also don't mean to exclude the necessity of cooperation, but frankly in my experience most people in Open Source do what they do because it's what they want to do (which is very often stuff they don't have the opportunity to do at work). Speaking as a (multiple) project maintainer, this can make things a bit like herding cats at times, but as long as everyone on the project has shared goals, and as long as people are capable of making the minimal compromises necessary for cooperation, it works out okay. That the association is voluntary helps a lot: the group tends to self-select for people who share common goals to begin with.
Of course, that best describes all-volunteer Open Source projects. Projects sponsored/funded by specific organizations tend to be more structured, although even then paid developers are still given more latitude than is usual in the normal commercial world.
What the GP is suggesting is that if scientists went on strike, weather satellites (for example) wouldn't immediately disappear. There would be a long-term impact, but it would take a long time to be felt.
Absolutely. But Open Source gives you the freedom to do things the way you want to, and it's a good way to interact with a population of other talented coders, both of which are generally hard to get consistently in the commercial world. Both are things that talented coders care about a lot more than the folks who are just in it for the money, clocking in the hours and punching in the first code that dribbles out of their brain.
It's more a question of having the spare time for it.
EULAs aren't the right comparison. This is nearly exactly like licensing proprietary code from a vendor for internal use and then "appropriating" that code for use in a shipping product without an explicit license to do so. Which also happens quite a lot in the commercial world. The main difference is that you're less likely to get caught when stealing proprietary code.
Actually, until recently C-Ruby didn't even have a VM; Ruby 1.8 and before used an interpreter that simply walked the AST. Ruby 1.8 is the current stable version, so it might be more accurate to say that Ruby folks are largely motivated by the poor performance of not having a VM at all.
On the other hand, the experimental Ruby 1.9 did finally introduce a Ruby-specific VM (YARV) implemented in C, and 1.9 on YARV is actually what Charlie was comparing JRuby's performance to in his post.
The guy ("these people") was already JRL licensees, so he did the initial work under the JRL. But he couldn't have released it publicly that way. The difference now is that he's able to port the work to OpenJDK and actually release it for total public consumption. I think that's an important detail.
One more thing: if your code has to deal with a wide variety of workloads, it may be impossible to statically optimize it for all of them. However, a JIT can optimize the code for the particular workload it is given.
Yes -- I've seen enough anime at this point to come to the conclusion that 95% of it is utter crap. But from what I've seen the best 5% is also significantly better than the best 5% of US animation.
AT&T could also charge iTunes, Amazon, or other content providers to have their services exempted from the filtering, which may be less likely to raise consumer protest.
Slashdot Mirror
I don't know that it's faster, I just meant that it's fast enough given the other advantages I mentioned. People seem to like in-process solutions, and I guess they would probably even use Webrick in production if its performance allowed it.
Note that even though I wrote fastthread, it was not aimed specifically at Mongrel/Rails. I've never been particularly personally involved with the Rails world, so take my comments as an outsider's observation rather than a recommendation.
It's not fair to blame DHH or Rails for technical problems on the Ruby side, though.
I think the main reasons are performance and Mongrel offering a self-contained solution since it is implemented in Ruby (mostly) and runs the hosted application(s) in-process.
I think the rant is the product of such a realization. Although I would have said it differently, I think part of what Zed is getting at is that he pigeonholed himself by devoting all his energies to Mongrel when the web/Rails market wasn't a good place for him to be.
FWIW, Zed wrote Mongrel, I wrote fastthread.
While I think Rails has some problems, it's important to draw a distinction between bugs in the Ruby standard library/interpreter and bugs in Rails. If it was just a Rails issue the hotfix for Ruby 1.8 (fastthread) wouldn't have resolved things. Note that other Ruby implementations (e.g. 1.9, JRuby) don't manifest the same issue and a fastthread equivalent is not required.
I think it's better if I don't comment on the rant itself. I think I can offer a little bit of general background information, though.
It's important to note that there is a distinction between the "classic" Ruby community (led by Matz), and the Rails community (led by DHH). Since Rails is built atop Ruby, Rails jobs are also Ruby jobs, but the two communities still have very different cultures.
Mongrel is a Ruby web application container mostly written in Ruby, except for the HTTP parser is written in C/Ragel. It has very good performance, and the Ragel state machine definition was derived directly from the BNF in the HTTP specification, so it also has extremely strict standards compliance. It became the most popular web application container for Rails. Since most of Mongrel is written in Ruby and most of the rest is in Ragel, we eventually got a JRuby/Java version of it too. These days Glassfish is becoming an increasingly popular substitute for Mongrel on JRuby, however.
fastthread is a Ruby library which "hot-fixes" the Ruby standard library to provide optimized versions of its thread synchronization primitives. It was mainly intended to improve performance, but as a side-effect it also worked around some long-standing bugs in the core Ruby classes which resulted in memory leaks and interpreter crashes under high load. Mongrel ended up requiring fastthread as a dependency because it was the only way to stably run a high-throughput application using the synchronization primitives on the 1.8 interpreter. fastthread is unnecessary on other Ruby implementations like Ruby 1.9 and JRuby.
Unless you're suggesting that developers make house calls, collecting that information still requires substantial (from a user's perspective) help from the user.
I think a lot of these discussions fail to clearly distinguish the map from the territory: scientific theories are approximate and merely descriptive (otherwise there would be no reason for science to continue to refine them), but when we talk about the "Laws of Nature", we are properly referring to the physical principles which those theories are intended to model, and against which our theories can be tested experimentally. It's pretty clear that these laws really exist, or else the results of experiments intended to explore them wouldn't converge.
The disputes that the articles have stirred up are mostly between three camps: those who think that the laws of nature can be accounted for by an infinite regression of physical laws, those who think the question of their source is unapproachable or meaningless, and those who think the existence of the laws can be accounted for in metaphysical terms.
Those are scalpers, dude.
Well there you go then.
Actually, it's not necessarily that much of a lull.
I'd submit that creative freedom is more important to talented people, however. Speaking anecdotally, although all levels of talent are represented, I've encountered a much higher proportion of very talented programmers in Open Source than I have at work in the commercial/proprietary world. One of the reasons I'm as active in Open Source as I am is that I've found it's the best place to find talented programmers who I can learn from.
I also don't mean to exclude the necessity of cooperation, but frankly in my experience most people in Open Source do what they do because it's what they want to do (which is very often stuff they don't have the opportunity to do at work). Speaking as a (multiple) project maintainer, this can make things a bit like herding cats at times, but as long as everyone on the project has shared goals, and as long as people are capable of making the minimal compromises necessary for cooperation, it works out okay. That the association is voluntary helps a lot: the group tends to self-select for people who share common goals to begin with.
Of course, that best describes all-volunteer Open Source projects. Projects sponsored/funded by specific organizations tend to be more structured, although even then paid developers are still given more latitude than is usual in the normal commercial world.
That's a good point. Not all scientists are "research scientists" in the usual sense.
You don't believe that talented people gravitate towards environments which offer them creative freedom?
Whether Open Source is more or less productive is a separate issue (I don't believe it is more productive in the short-term).
What the GP is suggesting is that if scientists went on strike, weather satellites (for example) wouldn't immediately disappear. There would be a long-term impact, but it would take a long time to be felt.
What I've heard from other sources is that there isn't a decrease, either. It may be that spammers are avoiding gmail specifically.
Absolutely. But Open Source gives you the freedom to do things the way you want to, and it's a good way to interact with a population of other talented coders, both of which are generally hard to get consistently in the commercial world. Both are things that talented coders care about a lot more than the folks who are just in it for the money, clocking in the hours and punching in the first code that dribbles out of their brain.
It's more a question of having the spare time for it.
EULAs aren't the right comparison. This is nearly exactly like licensing proprietary code from a vendor for internal use and then "appropriating" that code for use in a shipping product without an explicit license to do so. Which also happens quite a lot in the commercial world. The main difference is that you're less likely to get caught when stealing proprietary code.
Actually, until recently C-Ruby didn't even have a VM; Ruby 1.8 and before used an interpreter that simply walked the AST. Ruby 1.8 is the current stable version, so it might be more accurate to say that Ruby folks are largely motivated by the poor performance of not having a VM at all.
On the other hand, the experimental Ruby 1.9 did finally introduce a Ruby-specific VM (YARV) implemented in C, and 1.9 on YARV is actually what Charlie was comparing JRuby's performance to in his post.
The guy ("these people") was already JRL licensees, so he did the initial work under the JRL. But he couldn't have released it publicly that way. The difference now is that he's able to port the work to OpenJDK and actually release it for total public consumption. I think that's an important detail.
One more thing: if your code has to deal with a wide variety of workloads, it may be impossible to statically optimize it for all of them. However, a JIT can optimize the code for the particular workload it is given.
Yes -- I've seen enough anime at this point to come to the conclusion that 95% of it is utter crap. But from what I've seen the best 5% is also significantly better than the best 5% of US animation.
AT&T could also charge iTunes, Amazon, or other content providers to have their services exempted from the filtering, which may be less likely to raise consumer protest.
I stand corrected.