Actually really excited about this. My big problem with most frameworks is that any moderately sized application becomes excruciatingly monolithic. With Rails,

Actually really excited about this. My big problem with most frameworks is that any moderately sized application becomes excruciatingly monolithic. With Rails, the idea is that you have more code reuse, but then this becomes booting the whole of the universe to do something simple. Most of the time, your feature only needs a model, or a tiny part, of the application to do it's thing. With Tir, you have a bunch of small parts working together. You can reuse the code, but the process only needs to load the parts it needs to work with. The implicit nature of rails really hurts it's ability to scale a particular part of the application without having to install the entire application. An example, you scrape twitter for mentions of your app and shove them on your homepage. Twitter rate limits, so you background job this and run it in an interval. In the rails world, this means a resque / utility server, running the same code, each working booting up the full app, same deps, same model. In Tir, there's no reason to do that. Create workers, have them load only the needed bits to access twitter and your model, make updates. Very light weight. However: PUB/SUB for workers? Really? Can't we get mongrel2 style work N:M (PUSH <- PULL, PUB <- SUB) distribution? This way we at least have an assurance that only one worker will get the job.