“I try to get out and they keep dragging me back in!”

I was primarily thinking about intramodular references when I wrote about not-as-late-binding in Erlang (cf Ruby), so at least one gets some help at compile-time Yes, you are of course right, and that should be stated explicitly for people seeking the Holy Grail of problem solving: binding is deferred between modules in Erlang!

And, if one wants really late binding, one can use reflection, where even signature is decided after process startup…

Regarding mulitple Mongrel instances on one box, I promise you to use that as one of the framework environments in next revision of this test.

Ok, one discussion I will not have (here and now) is that of implicit type conversion, user-defined or not, and arithmetic propagation constituting a weaker type system

Also, since the arguments are untyped, just checking arity and existance is pretty weak compile time checking. There is, however, a tool called the dialyzer that does static analysis getting much of the error detection benefit of a language that actually is statically typed.

Rails deployments do typically use mongrel these days, but you do have to be running a bunch of them as separate processes for the reasons previously discussed. I just think it’s important from looking at the relative advantages of the systems to realize that even though you have all these heavy mongrels running around doing serial processing of the dynamic requests, they aren’t going to be interfering with the serving of your static content.

Also, this is a big deal when thinking about caching. By having parameters in the path, as opposed to the query string, you can cache the page to disk and hand it off to the static web server. In which case, it doesn’t even go near the mongrel until you invalidate the cache. It is important to realize that for many common caching situations, mongrel will be out of the loop entirely.

I actually agree on the static/dynamic naming issue confusing the hell out of people. There is also a strong tendency to confuse dynamic and weak typing. Ruby, for instance, is strongly typed in a way that C/C++/Java are not, since there is no such thing as casting. I don’t really have a preference. My last professional incarnation was doing console game development in C++ which obviously places a radically different priority on questions of brute efficiency. I will say that I find myself very productive in Ruby and Erlang but do not attribute that much to the type system.

I really dislike the classification dynamic for dynamically typed languages. It feels like they are, well, more dynamic which is simply not true, in general. For instance, the generic programming notions of templates in C++ and classes in Haskell make for quite dynamic programming and solutions. If you add the meta facilities induced by those C++ templates (and advanced use thereof) or the true compilation-phase execution model of Template Haskell, you get highly dynamic languages.

Ok, I admit to enjoy the lenient nature of dynamic(ally typed) languages at times, so take my criticism above with a grain of salt.

I will try httperf out. Thanks for the pointer!

Tom:

Never say “the last comment.” You know there will be more Regarding using Mongrel for static content – yep, that is a bit crazy, and I would *not* do it myself – *but* I wanted to see how these frameworks served static pages as well. I welcome any suggestion of a complete and realistic combination. Thanks for the Nginx pointer!

But, the fact still holds that most Rails apps *do* use Mongrel for dynamic stuff, right? If so, that bar is still valid. And, honestly, most Rails apps do serve static stuff only in the beginning of sessions (images…) right, so that bar is not that important anyway, or?

Regarding the late binding. Well, the fact is that – in Erlang – the binding is not that late at all. It is all bound up with – a static check – at compile time. It is just that the “static types” available during compilation are more like “kinds” in Haskell, i.e., they represent meta types when viewed from a meta interpretation point of view. What I meant with those convoluted words was that “no, you are not right, Erlang *does* indeed check for existence of functions, arities and stuff” before runtime whereas Ruby does not.

I skipped using dynamic pages with lightttpd since I only threw it in there to compare the delivery of static content from these web frameworks to what I assumed – and rightly so – to be the fastest such server.

I could – and will for my next version, where I *will* include .NET and Tomcat and/or JBoss and/or something Springish – include FastCGI to PHP from lighttpd, since I know that is a reasonably common web server environment.

One interesting note, when we talk about static content, is that both ErlyWeb and HAppS is quite considerably faster in generating dynamic content than static one. If that comes as a surprise, it should not, since the static content means reading a text file from disk.

The discrepency between your R/sec numbers and theirs are quite large. Also note the big changes in numbers depending on whether session are being used and what the session store is. Do you have sessions turned off?

My final beef with this entire analysis, is that using mongrel to serve static pages is bizarre. It is great when you are in development because you don’t have to set anything else up, but in any real world situation, only your dynamic requests will go through mongrel. No attempt has been made to optimize it as a dynamic web server.

I take the same approach when building erlang web apps. Nginx is vastly faster than Yaws for static content, so I’m not really interested in using it as a general purpose web server. Just serve static content from Nginx and proxy dynamic content to the erlang app, problem solved. This is also how our Rails apps are configured.

That is the point of the process oriented approach. Since each Rails process has no expectation of being able to communicate with each other except via connection to the db, it doesn’t matter what machine you run those processes on.

I think ErlyWeb being more amenable to casual web development than HAppS says more about HAppS than about RoR. I really respect Yariv’s work. Though I don’t actively use ErlyWeb, I have found his blog and code immensely helpful, but I do not find ErlyWeb even remotely comparable to what Rails makes available. It is awesome that it makes things easier, but it’s not the same, sorry. Erlang has other strengths.

Also, if you dislike dynamic/late binding, why are you giving Erlang a pass? Seeing as it is in the same position? I personally like it, if you are getting good code coverage out of of your tests (and you are writing tests aren’t you?), you shouldn’t run into problems.

I should just be making my own blog post for as long these comments are