Re:This just seems like nonsense.
on
Rails May Not Suck
·
· Score: 2, Interesting
Has it really? I don't think that Java has survived the lack of mod_java.
Quite. Apart from the lack of Java in the hosting space, let's be honest, the whole Apache->Tomcat connector story has been a sorry one indeed. mod_jk, mod_jk2 etc has been a real mess over the years.
Where does this stem from? I think it is a case of the wrong tool for the job again in a way, this time by Sun.
Originally Oak (Java) was designed to run on set-top boxes, where it made sense to have a long-running virtual machine. The web took off just as Java 1.0.2 was launched with a whole 6 packages. Not long after, Apache was the prevalent web server, and worked well for static content. Dynamic content was served by CGI, and that didn't work too well because every request required launching a separate process.
So PHP comes along and quite nicely solves this problem by running in an Apache module, with the requests handled in forked Apache child processes (pre-fork MPM).
This model doesn't fit with the virtual machine architecture of Java - you can't have multiple copies of the VM in each of Apache's children. So we end up with the mod_jk architecture.
I used to think that the PHP MPM Apache children approach was a bad thing, compared to the ability to create threads, caches of shared data, database connection pools etc in Java. But the PHP shared-nothing architecture has definite benefits.
For one thing, it gives you isolation. If one child fails, other children are unaffected. In my experience, the PHP architecture is more robust, for example, in the case of recovery from database failure. I've seen Java web apps where if the database is restarted, invalid connections stay in the connection pool and you have to restart Tomcat.
Also, horizontal scalability is so much easier. Java has solutions to this, but it's a bit of a mess in some ways. Of course I don't think PHP is a better *language*, but the reason HTTP itself has been successful is because of its statelessness. The PHP shared-nothing architecture respects that, Java goes against it.
That, in my opinion, is why PHP rules the roost on the public internet.
And ActiveRecord does not mandate your primary key. If you don't like the default, you can easily change it.
By change it, I assume you mean use another field.
Perhaps I should have been clearer about what I meant.
What if I want a compound primary key? Rails doesn't support that out of the box, although there is http://compositekeys.rubyforge.org/, so perhaps Rails is flexible after all.
Similar comments apply to surrogate keys of course.
I think there is a tension between what can be done with the framework, and the way DHH thinks you should use it.
Of course that's right, but it doesn't mean a given language/platform shouldn't learn lessons from others.
In my opinion, PHP has been successful because of the ease of integration with Apache. If the same was true for Rails, it would become the right tool for a lot more jobs, I think.
That may or may not be true, what I do know though is that Rails does like to impose its way of doing things on you.
Isn't one of their mantras, configuration by exception, or words to that effect? Comparing ActiveRecord to Hibernate, for example: ActiveRecord effectively mandates your primary keys, Hibernate is surely more flexible, albeit with a lot more XML/annotations...
Slashdot Mirror
Quite. Apart from the lack of Java in the hosting space, let's be honest, the whole Apache->Tomcat connector story has been a sorry one indeed. mod_jk, mod_jk2 etc has been a real mess over the years.
Where does this stem from? I think it is a case of the wrong tool for the job again in a way, this time by Sun.
Originally Oak (Java) was designed to run on set-top boxes, where it made sense to have a long-running virtual machine. The web took off just as Java 1.0.2 was launched with a whole 6 packages. Not long after, Apache was the prevalent web server, and worked well for static content. Dynamic content was served by CGI, and that didn't work too well because every request required launching a separate process.
So PHP comes along and quite nicely solves this problem by running in an Apache module, with the requests handled in forked Apache child processes (pre-fork MPM).
This model doesn't fit with the virtual machine architecture of Java - you can't have multiple copies of the VM in each of Apache's children. So we end up with the mod_jk architecture.
I used to think that the PHP MPM Apache children approach was a bad thing, compared to the ability to create threads, caches of shared data, database connection pools etc in Java. But the PHP shared-nothing architecture has definite benefits.
For one thing, it gives you isolation. If one child fails, other children are unaffected. In my experience, the PHP architecture is more robust, for example, in the case of recovery from database failure. I've seen Java web apps where if the database is restarted, invalid connections stay in the connection pool and you have to restart Tomcat.
Also, horizontal scalability is so much easier. Java has solutions to this, but it's a bit of a mess in some ways. Of course I don't think PHP is a better *language*, but the reason HTTP itself has been successful is because of its statelessness. The PHP shared-nothing architecture respects that, Java goes against it.
That, in my opinion, is why PHP rules the roost on the public internet.
By change it, I assume you mean use another field.
Perhaps I should have been clearer about what I meant.
What if I want a compound primary key? Rails doesn't support that out of the box, although there is http://compositekeys.rubyforge.org/, so perhaps Rails is flexible after all.
Similar comments apply to surrogate keys of course.
I think there is a tension between what can be done with the framework, and the way DHH thinks you should use it.