You can really make apps as fast as what Rails or Django offer
I find this quite hard to believe. I've been developing Ruby/Rails web applications for over 2 years, and while I like the idea of Arc and would love to be as productive in a Lisp as I am in Ruby/Rails, that is not reality yet because of the libraries.
The toy example pg put up way back when did show off Arc, but once you add real world requirements, Arc comes up a little lacking.
* scalability of not requiring session affinity
* database libraries
* regular expressions
* Rails *huge* library
It's trivial (takes one line) to have a class with a name different than the table:
class MyPet < ActiveRecord::Base
set_table_name 'pets'
...
end
You can turn off pluralization in one line.
I hardly consider those minor changes to be reconfiguring the whole thing. You may want to actually develop some non-trivial applications with Ruby/Rails before comparing to Arc.
> "I find this quite hard to believe. I've been developing Ruby/Rails web applications for over 2 years, and while I like the idea of Arc and would love to be as productive in a Lisp as I am in Ruby/Rails, that is not reality yet because of the libraries.
> The toy example pg put up way back when did show off Arc, but once you add real world requirements, Arc comes up a little lacking."
Oh, you are totally right about that. That's why I reimplemented the Arc web server in Lua. Now, I have libraries too (even if Lua isn't the richest language in this regard, at least communicating with the outside world is damn easy -- that's the language's goal). I think I'll try to write a small CRUD framework to see what can be done.
> "It's trivial (takes one line) to have a class with a name different than the table [...] You can turn off pluralization in one line.
> I hardly consider those minor changes to be reconfiguring the whole thing."
Ok, that was a little exageration. But to me it feels like bad design : why didn't they default to "the table has the same name as the class" ? That's simpler, easier to implement (no exceptions to take care of) and foreign-language friendly.
> "You may want to actually develop some non-trivial applications with Ruby/Rails before comparing to Arc."
I did it. It's especially when the application starts to be non-trivial that I hate having to fight with Rails designers' points of view to make my stuff work. On the opposite, with Arc/Luarc, the more my application grow, the better its design feels, because I have to make explicit things I considered implicit / subject to change in the previous versions.
That is probably only my own vision, but with the Arc model, I can see my applications becoming more mature and stable, while with the Rails model, I see them getting more and more patched, with more and more bureaucracy to make everything work.
Of course, it is still better than with, say, PHP, where it is bureaucracy and patches all the way down (that could be a motto : "PHP : patches all the way down").
