And based on the author's previous Django and ORM posts, I look forward to the next post in a few months when the black magic stops working and they begin to hate on Rails as a framework.
Yeah, there is a non-zero chance of that happening. However, I keep discovering more and more Rails design choices that either match or closely align with my preferences.
The three biggies comparing to Django are:
1) Powerful templates (including the convenience of "Helpers")
2) Non-declarative schema ORM with full migration support
3) Form validation and generation with Rails doesn't suck
Lastly, Rails feels battle tested and production ready. Everything from the Rake tasks, to the framework surface area, to the plugins available seems tuned for real applications. Python stacks I have tried often require a lot of hackery to handle server configurations, deployment, content builds, template helpers, ... the list goes on and on.
I think you and I both know - once you've run with something long enough, you hit a wall. Everything - every language, framework or tool hits a wall. You hit yours with Django because you fundamentally disagreed with some of the design decisions. I personally have not hit my wall (with django) but I see plenty of room for improvement.
It's awesome you built something so quickly with Rails - I have a similar experience with Django (a tiny amount of time to build a really deep application).
I personally found it amusing/bothersome that you were lauding a fairly magical and opinionated framework when you had old posts deriding Django (and it's ORM) in the past.
I like opinionated software. Especially when it matches my opinions. And if it doesn't match my opinions, it is easy to dismiss it.
It isn't the magic about Django (and it's ORM) that I didn't like. It was the design decisions that didn't match how I think (and approach of declaring the DB schema in code).
We (mostly) agree then. The non-opinionated stuff makes me 1000x more angry then something silly like lack of class-based views, or the inclusion of GIS in contrib (for Django).
I was probably overly sarcastic in my original comment, so for that I'm sorry.
Nice try; but having more flexibility can be just as damning as not enough. Me, and plenty of others, have found that we know where, say, Python's wall is and accept it or we go around it. The wall I'm talking about is the mental barrier where you either no longer want the tradeoffs involved, or find you disagree with a fundamental axiom of the thing under inspection. Drilling through it is impossible without discarding it entirely.
Having flexibility to drill through that wall just puts a bigger, harder wall someplace else. And other people find Emacs/VIM ideas perfectly workable IDEs, and find the flexibility of Emacs and VIM horribly confusing.
You have to know, and accept the wall and limitations - it's a series of tradeoffs, and you just need to know what you're getting in the trade.
In the case of frameworks, it's just a bigger set of tradeoffs as they tend to be a lot more opinionated, which means you're trading more for comfort.
Emacs is use optimized, not learning optimized. It takes lots of time -- if you don't use it for hours a day, it is probably not worth it.
Org mode in Emacs is a good example. It took embarrassing long to learn for me -- while the GUI variants (e.g. gjots2) are trivial.
But now, I can take notes and doodle with Org mode that I could only do on paper before. It is built into my fingers in a way which IDEs/GUIs failed for lots of years.
I'd argue that Emacs is without a wall for programmers. (-: As long as you don't want to do word processing with WYSIWYG. :-)
The problems will be new areas, like how will text understanding libraries (theoretical concept, not in that area) integrate with Emacs compared to others.
You could probably do the same arguments for Perl and Lisp. But I don't know any framework I'd say the same about.
Edit: Thinking back on my life, I'll yield the point re frameworks. Not libraries, for a not too large problem (a pack of collected libraries would have a wall in a bad Big-O for complexity/time).
Edit 2: You could put my argument to be that the last decades of history shows Emacs to be, for all practical [programmer] purposes, infinitely flexible -- as long as new functionality can be integrated to the normal Emacs usage. Which is a big caveat, yes. Org isn't the first generation of that kind of note taking modes in Emacs, the evolution was afaik in much how Org was used.
Emacs might be insanely flexible, sure, but at what cost? Bloat? Infinite complexity? Heck, I get frustrated with my VIM configuration sometimes because I forget the less used keybindings when I really need them, and need to go spelunking.
So sure; if you're willing to trade the up-front investment of time (not insubstantial) Emacs will go far - and the wall is way off on the horizon and someone scribbled "complexity" on it.
Up-front investment can't be underestimated; there's a reason why things like Textmate (which starts simple, and grows out well) are so popular. Low initial investment, and plenty of ramp, and it works out well until it simply doesn't.
That low initial barrier is easier to climb, and while emacs (or even VIM) might have a wall that, when compared to Textmate's, is infinitely far away, textmate will still have fantastic adoption. The wall textmate has is further off then most people are willing to worry about.
For most people, a framework, like, say, Django or even Rails offers a wall far enough out that most people don't need to worry about it, but when they hit that wall, they're going to hit it hard, and kinda be mad.
You're mostly rewriting my points. Let's leave this for half a year and discuss it again. It seems we both need to let it fes.. think about it. :-) Or at least I know I do.
What I'm trying to say, I think, is that there is a tension between flexible/pluggable frameworks and integrated ones, like with e.g. Emacs and simple IDEs. (Yeah, there are IDEs on top of Emacs; those doesn't remove complexity.)
(The main complexity problem with Emacs isn't the code which is neat with the lisp layer (imho, I'm very far from being a real Emacs hacker). The complexity is use complexity -- lots of modes, etc. More broad than deep.)
But unless some totally new idea comes along, people will use Emacs when we both have forgotten the present frameworks...
>>I get frustrated with my VIM configuration sometimes because I forget the less used keybindings
I haven't used vi for quite a few years. There is still no good search/browsing/M-x? Never mind, some really good people use vim, so I assume there is something there.
I worked with both Rails and Django and I like Django's approach better ... simply because the fields declaration is higher-level.
I.e. you don't have a "filepath varchar" field, but a "photo=ImageField(thumbnail_size=[320,200])".
I've had a good experience with South for database migrations, used it in every Django project I tried ... the only things bothering me is that the generated files are too verbose (not much of a problem, since you don't need to modify the auto-generated code), plus a migration-based system doesn't really blend if you've got multiple apps in the same project (refactoring becomes painful).
Other than that, Rails is pretty good because of its declarative APIs. Django has too much boilerplate for my taste ... but I like that for complex projects where I need to tweak things.
I can't disagree on ORM and templates (I disagree with the lack of proper method invocation in Django templates, it annoys me having to create tags for trivial things). I kind of disagree on the form validation though. Having used a number of frameworks prior to Django (including Rails for about a year), I love the way forms are handled in it - it just seems to make sense to me.
3) I don't understand how anyone can prefer another framework's form tools after using django.
Like others have said, considering your past posts, it's just a matter of time before you starting hating Rails. To each their own, but I don't see any of your points as being a valid reason to like Rails over django.
I don't want to get into a framework war or anything -- in fact, I'm a Django developer currently after several years working with Rails, and relatively happy with the switch.
That being said, both #1 and #2 above are plain wrong.
Django template tags are a PITA to write, have weird inconsistencies (largely due to the first issue causing them to be implemented in a very hack-ish way) and don't have access to any request or application state that isn't explicitly added to the template context. Rails template helpers are powerful, easy to write, and ubiquitous. Those properties also make them easy to abuse for functionality that should absolutely be in a model or view function.
South, on the other hand, is powerful, complex, and not part of the Django core. That simple fact immediately makes is less useful. Any Rails developer (and by extension, any Rails codebase) will be familiar with AR migrations. No extra dependencies, training, or versioning issues to worry about.
I mostly agree with #3, though I definitely still find some funky edge cases with Django form validation. They aren't a terribly gently introduction to the "Right Way" of doing form handling for someone more comfortable with HTML than Python, either.
You make some good points. I've always felt that if your template tags are doing too much, your front-end is getting too bloated. That kind of logic should be left to your models/views. I know there's a lot of disagreement in the community over the lack of real Python code in your templates, but it just encourages sloppy spaghetti. Forcing you to not rely on advanced logic in your templates makes you a better developer.
I do agree that migrations should be a part of core/contrib, given how common of a use case they are. I don't agree that it makes it less useful. You need plenty of gems to get Rails to satisfy many common use cases. No framework plugs all the holes, you always have to extend. Both django and Rails make getting and using those extensions hilariously easy, so there's really no barrier to entry for any developer.
> I know there's a lot of disagreement in the community over the lack of real Python code in your templates, but it would just encourages sloppy spaghetti.
You'll see a lot of this in the Rails community too; lots of people use haml over erb for exactly this reason.
Can you elaborate on the non-declarative schema point? With something like Django's South handling migrations, what problems does the declarative schema introduce that Rails side-steps?
It is a subtle, but fundamental distinction: Django expects me to declare my schema in Python. Rails (and optionally SqlAlchemy, which I like) operate via schema reflection. The declarative approach is redundant, error prone, and resistent to migrations, even with South. The reflection approach matches what you'd do with a bag of Bash scripts in the absence of any framework; as such, it works better in a real world deployment.
Having used both (though Django much more heavily) I don't see any practical differences between migrations in a non-declarative system (Rails) and a declarative one (Django). Migrations are always a bit of a pain, but database changes (at least to any field managed by a framework) will almost always require code changes -- so what are you gaining by leaving the field declaration out of the model?
I'd say that the declarative syntax is actually a bonus. It makes the code much more discoverable, and I haven't seen a real downside.
The declarative approach is only redundant if you're inheriting a project, and even then it's only redundant that first time you mirror the existing db schema in Python. How can you call a declarative method redundant and not schema reflection? They're reverse processes of the exact same thing.
The only "errors" I can think of that can arise from declarative over reflection is when someone decides to manually fuck with your database while ignoring your framework's tools. And even then, South basically handles every use case. How exactly do you think South is resistant to migrations? Updating your models.py and running two manage.py commands seems pretty damn straightforward to me.
"The reflection approach matches what you'd do with a bag of Bash scripts in the absence of any framework; as such, it works better in a real world deployment."
So, you're saying that because one way looks like what you were doing before a framework, it's somehow "better?" What kind of backwards logic is that? It's basically the definition of abstraction.
I understand the need to have the schema where it's being used but if you ever need to make modifications like custom fields (say an email field) then your schema isn't just stored in the DB any more. With Django your custom field declarations live in the same place as more mundane fields. If you port that models file to another machine and run syncdb you are going to be left with the same schema with the same restrictions.
This reply could be to the majority of comments on this post, I just chose yours because it's the first one.
I'm pretty disappointed with HN being party to the same smug, knowing, tongue-in-cheek Rails (and to a lesser extent, Ruby) hating that you constantly see on Slashdot and elsewhere. There are merits to Rails, and also drawbacks, as there are with every tool. It isn't magic, or anything close - the code is all there for you to read, and it is just Ruby, no pixie dust anywhere.
He's not 'hating' on rails, he's just indicating that there is a period when you use something new that you think 'wow, this is great' when after the shiny newness wears off you realize that there is plenty to be improved.
Calling it a honeymoon period is not too far from the truth, everything seems rosy and pretty.
Yup, also "If you cannot name at least 5 things you dislike about the tools and languages you use you're either in the honeymoon period, or irrational".
As I commented elsewhere in this thread; god knows Python/Django/Zope/Etc have plenty of things to improve and get better at.
> I'm pretty disappointed with HN being party to the same smug, knowing, tongue-in-cheek Rails (and to a lesser extent, Ruby) hating that you constantly see on Slashdot and elsewhere.
I don't code Ruby, so maybe I'm not as sensitive to these things, but I haven't noticed this here at all.
RoR allows lots of HN-types (hackers, people prototyping web business, etc.) to build products quickly. In fact, that's exactly what TFA is an example of.
I'm actually constantly surprised at the number of HN readers who seem to hate on RoR out of general principal.
A lot of the HN crowd dislikes PHP, and can point to dozens of reasons why: no consistency in the standard library re: naming conventions, order of arguments, etc; poor abstractions; up until recent versions, a lack of namespaces or late static binding, and so forth.
A lot of the HN crowd seems to dislike Rails, but I've never once seen someone post a objective reason why. Philosophical differences I can see -- maybe Rails isn't for everyone. But the majority of the anti-Rails posts are FUD at worst, and misinformed at best.
I had really quite a good one with Django, which clicked to me in a way that Rails never did.
I miss scaffolding though, as I think that was the 'killer app' to RAD, but I'm to the point where I feel like even my simpler apps feel constrained by either Rails or Django at this point (though I'm probably just not knowledgeable enough), and have started doing everything with Tornado and SQLAlchemy, which, while they're currently kicking my ass, doesn't give me any sense of constraint whatsoever.
Of course, upper bounds have always been something that bothered me, even when they were realistically well about my own limits. When I was learning to play guitar, I went out and bought a Les Paul, for the comfort of knowing that whatever else goes wrong, I can't blame the tool. In reality I know that only poor craftsmen do that, but every time I get stuck trying to remember the 'Django' way to do something, I feel like I'm in a box I want to climb out of.
This kind of attitude makes me keep looking for ways to move away from Python-land. The new "we're better than everyone else" attitude is seriously grating. I like writing Python, but it sucks seeing this kind of crap every time I go into a mailing list or just about every other public programming forum around.
What feels like aeons ago, python-land created the huge monolithic monster, the Zope framework, which was absolutely great at the time. Then people were bitten by writing classes that would unexpectedly manifest some behaviour "as if by magic." The problems became (1) determining whether you would one day out of the blue have code "act weird", (2) figuring out where this behaviour was coming from.
Save to say, many people got bit/burned/scarred. Lessons were learned. There is a fair bit of cross-polination going on; I can't think of any python framework that has not tried to learn from this, and also from the successes/challenges of others (and that includes those of Rails btw).
So when a "battle scarred veteran" makes a terse statement such as this, I don't think by any means it expresses a "better-than-thou" attitude. But you can understand why there might be (rightly or wrongly) an anticipation of pain to come.
When pythonistas look as Rails (for example) and say "hmmn, this pattern looks sort of familiar, wonder how they're going to avoid that type of pain we had", surely this is neither unfair nor over critical, it's just part of the technical dialogue that ultimately advances everyone's "state of the art."
And I don't think anybody in the python world really claims to have the "one true answer." Rather it's more the case of "there is no one true answer, only many flawed attempts; so if you think you've found nirvana, be prepared for some disappointment down the road."
Generally people acknowledge that it's a difficult problem and that we're all dealing with variations of the same issues, irrespective of language or framework. A bit like a balloon; you can squeeze it in one place to make it "thinner" there, but likely it will pop out some place else.
I probably wouldn't have had such a strong reaction if the comment hadn't started with "And based on the author's previous Django and ORM posts" as though the author is incapable of making technical decisions because he didn't like some aspect of Django previously.
Between that, and the regular stream of ridicule about Rails , Node or just about anything else not Python it just seriously rubs me the wrong way. I don't see anyone changing my opinion of that; nor am I asking them to.
I have seen (for virtually every type of interesting technology ever) two classes of people (at least):
1. People who've somewhat recently discovered it, and realized how powerful it is. Not really surprising to see that people in this category would argue their tech of choice over next to anything out there; both because they're enamoured with what they've discovered, and also because it helps validate their choice.
2. People who've gotten past stage 1 and realized that everything has limitations. These people are far more pragmatic and will tend to seek the best tool for the job. Sometimes what they say may appear to be acerbic, often this is because it attempts to express the "there is no magic bullet"-conclusion that they've reached.
Can guarantee you that Jesse does not fall into group 1.
Also, I think in the above if you substitute "tech" for "community" the same will hold true.
Ultimately these are all just tools in the toolbox and people in group 2 acknowledge this irrespective language/framework/community.
I was being sarcastic; and if you cannot name at least 5 things you dislike about the tools and languages you use you're either in the honeymoon period, or irrational.
This includes fellow python-oriented people. Myself included.
"... if you cannot name at least 5 things you dislike about the tools and languages you use you're either in the honeymoon period, or irrational."
This is one of those things that sounds true, but falls apart on further inspection. Aren't you allowed to genuinely like your language or tools?
Obviously there are tradeoffs with using any implementation of anything, but people can be completely satisfied and happy with their tools without being starry-eyed morons ...
This is one of those things that sounds true, but falls apart on further inspection. Aren't you allowed to genuinely like your language or tools?
Yes, plenty of people genuinely like their languages and tools. However every language and tool has warts. You simply cannot build something that complex without either making mistakes that you can't reverse, or else making trade-offs that aren't going to fit someone else's use case. Plus no language or tool can fit every good idea, so it is in the nature of the beast that there are good ideas that simply didn't make it in.
If you have not found those things yet, then you don't know your language and tools that well. Or else you don't know what is possible with other languages and tools. (That is the essence of the blub paradox - see http://www.paulgraham.com/avg.html for a detailed explanation.) Either way your opinion on how your language and tools compare with others is useless to more experienced people.
Heh, I understand the Blub paradox quite well. And, as I acknowledged, everything has design tradeoffs or even mistakes. Just because there are design tradeoffs or warts, doesn't mean they rise to the level of active dislike.
For instance, most implementations of Ruby are relatively slow. Do I care? Generally, no ... certainly not enough to say it's something I "dislike." It's entirely possible to build tons of web apps (for example) and never bump against any language "mistakes" or "tradeoffs" that are relevant.
"Dislikes" may be stronger than you want, but would you agree if it were changed to "recognized shortcomings"?
Let's use Ruby for an example. You discounted performance because it never matters in web development. Fine. Here are 5 more issues that do come up in web development. Not using native threads makes it easy for a poorly coded C extension (for instance a database driver) to block all threads. Common classes of errors (eg typos in variable names) can only be caught at run-time. Some widely used libraries use monkey patching, and with dependencies it is very easy to pull one in without realizing it, only to get burned later in what should be an unrelated library. By default gem does not run unit tests at installation, which makes it less likely that developers will get prompt feedback about issues like platform-specific code or unspecified dependencies. While mix-ins are convenient, they provide opportunities for conflicts and make it harder to track down the source of a method when you're trying to debug something.
I don't even use Ruby very much. If I did, I could easily come up with a much larger list. (My primary language is Perl. You should see the list of complaints I have about it! Yet I still like it. And for the record I like Ruby as well.)
Edit: I only included 4 issues initially, so I just added another.
Maybe dislike is too strong in your vocabulary - but in mine it's "things I don't like; and would not cry if they got better/changed tomorrow". I'm not talking about hate here - sure, people are able to uncompromisingly happy (as I am, when I'm working on python) but the poster above pointed it out - If you have not found those things yet, then you don't know your language and tools that well. Or else you don't know what is possible with other languages and tools.
So, attribute any emotional level you want - in my book, dislike is far from hate, and means you would actively work to change the item if question, if given the power.
I love working with Python, with Django, with Linux/OSX, VIM, Textmate, etc, etc. I love working with them, but each has it's failings, and it's important I know them. Sometimes knowing your own limitations, and those of your tools, and thinking critically about both is the most important skill a person can have.
Probably, it's really as simple as challenging your assumptions, and striving to be better, or make better things. Hell - it's what drives most entrepreneurs.
By "something" do you mean Ruby itself, or the fact that most Ruby implemenations are slow? If it was the former, then I think you're responding to the wrong statement. The statement was about "5 things you dislike about the tools and languages you use". So it wasn't about disliking Ruby itself, but rather things about Ruby.
If you were indeed saying that you don't care enough about the fact that "most implementations of Ruby are relatively slow." to raise that fact to the level of "dislike", well, I guess I find that hard to believe. I mean, sure, it generally won't matter. But even if it only matters a small portion of the time, what is there to "like" about implementations of a language being slow? Wouldn't you always dislike that fact, even when it didn't particularly matter in most cases?
Aren't you allowed to genuinely like your language or tools?
Not of that means being blind to its shortcomings. I love my girlfriend, but that doesn't mean I can't name 5 things that sometimes annoy me about her.
but people can be completely satisfied and happy with their tools
You can be satisfied and happy while still sometimes cursing at shortcomings. I love coding in Ruby, but the state of affairs concerning documentation and where to find gems is appalling.
(BTW: upvoted for having a valid opinion. People, please don't downvote below +1 just to disagree.)
If you're not saying he said that, why leave the comment in reply to him? Either you think he said that (or conveys that attitude), or your comment is blatantly off-topic.
> This kind of attitude makes me keep looking for ways to move away from Python-land. The new "we're better than everyone else" attitude is seriously grating.
Wow. That sounds exactly like you're talking about Ruby/Rails.
Wow. Very disappointing comments on this post. I was looking forward to a healthy debate with some interesting arguments. but with a couple of exceptions this is silly bickering.
This may be because nearly everything that has to be said about Django VS Rails, or Rails VS any framework has already been said twice. Not to say there isn't room for new/interesting discussion, but it's certainly a tougher subject than others.
After having worked with rails for coming on two years now, it's been a love-hate relationship. The short version: your first few apps will be pretty horrible but the more you know about the framework, the better they get. Admittedly, the same could be said about any framework.
Also, don't be afraid of the black magic, read the source, its just plain old ruby down there.
Agreed. "Magic" is just another word for "I don't understand how they did this". Whenever you meet "magic", you should dig into the code until you do understand "how they did this".
In particular, there is a comment[0] that I think is particularly worth reading:
There are two different definitions of magic in play here.
1. The use of advanced language features in a manner that might be confusing to a novice programmer.
2. The use of ANY language feature to automate some process that a programmer would not expect to be automated.
I am of the belief that the second is the proper definition, which is something that is not usually solved by reading sourcecode, as the question is "Why?", rather than "What?" or "How?".
It's like the reason I advocate comments though I know a few people who believe the code's behavior should be self-evident.
The real question for any interesting application is not the how or the what, but the why. You can't answer the why just by reading the code. You need to understand the problem and the trade-offs, and for that you need comments and documentation.
I think why magic looks like magic is because there is no obvious explanation for what it's doing, e.g. something in rails somewhere is using reflection to pick up something based only on a naming convention. You have to more or less know about the naming convention in advance in order to know where to look up more about what it's doing.
I think some people feel like rails went a little overboard on things like this.
Although true in this case, that was not my intended meaning.
A few of the "magic" things I've encountered thus far in Rails can be easily demystified by looking at the code. However, like magic shows, knowing how the trick is done doesn't mean that I can't enjoy the spectacle of it. The execution of the trick is every bit as important as the mystery.
I'd put forth this definition, which applies to both magical performances and magical code:
Magic is taking something which is traditionally considered impossible and making it look effortless.
Some magic tricks really are effortless. Others require painstaking setup and flawless execution. Same thing with code, but only the former is really valuable in production systems.
Sometimes the black magic is great, especially if you're trying to rig a prototype together. Also the configuration is almost always really easy so it's not difficult to start burning through a project.
Other times it's like "too much framework". I've never really been a fan of the all the javascript hocus pocus that occurs and prefer just writing it out on my own.
I also started to get frustrated with the active record query interface and started writing my own queries out because it was faster (for me).
The Javascript hocus pocus is the one key thing I haven't really figured out yet. Rails 3 seems to have made a move to unobtrusive Javascript, but it appears half-baked compared to the RJS stuff I keep stumbling across on the web. If you ignore the `:remote => true` business, it is as if there was no special support for js at all. As a solid jQuery developer, that's probably a good thing.
Visual object-relational mappers allow you to integrate different DB schema and classes/objects, instead of deriving one from the other. What do people think of them? They aren't appealing to me, because they aren't very code-like... however, some relationships between disparate type-systems are much easier to express graphically than in code.
I really prefer Sinatra's way of doing this; and it's probably even more appropriate for prototyping (but not for big projects, where separate directories help handle complexity.) It's just amazingly simple and intuitive: http://www.sinatrarb.com/intro.html
get '/hello/:name' do
# matches "GET /hello/foo" and "GET /hello/bar"
# params[:name] is 'foo' or 'bar'
"Hello #{params[:name]}!"
end
this is pretty much similar to how I fell in love with Rails... I came from a strictly front-end html/css background.. not too much real programming experience. Ruby just felt so natural and Rails made the hard parts easier and the community was so helpful.
Well, I respect your choice. I've been playing with Django for some time. There are things that I don't like and there are things that I like. However, I'm little surprised as to why didn't you try anything beyond Django in Python world, please enlighten me--I'm curious?
I have gone beyond Django in the Python world. I tried Pylons, web.py, TurboGears, and a few others. I've built apps on Google App Engine and Paste with my custom "framework" as well as prototyped some stuff with Tornado.
My favorites in the Python world are Google App Engine and Tornado (both with my bag of helpers). I like both of them because they are both very practical and embody best practices that I can understand and agree with. Of interesting note, both of them are fairly minimalistic relative to Rails. I thought it was the minimalism that I enjoyed (and to some extent, it is), but in reality it's just that they fit my mental model.
Rails fits my mental model and provides loads of convenience. I'm not saying that it is a panacea. I'm saying that I was pleasantly surprised by how much, and in what ways, it differentiated from the Python world.
If you want a Python-based web framework that's super minimalistic and gives you maximum freedom I recommend (re) trying web.py. Just use it for that topmost routing, for example, and the dev web server. You don't necessarily have to use any other aspect of it. I love Django but whenever I have something that I think may cause me non-conformity grief with Django (or any other "big" framework), or, if I just don't have a really solid vision for how the web app will ultimately look feature-wise, I always start with web.py. Then sculpt and pivot to taste, only as needed. It's much easier switching frameworks than languages, in my experience. And being strong in Python buys you leverage in several other areas that Ruby and the Ruby ecosystem is just not as strong in (native lib integration, graphical games, scientific computing, CGI rendering, etc.).
IIRC GAE's Python SDK is web.py-inspired. (And Django.)
"Pythonistas"? It sounds like female, plural. In case of 2 males shouldn't it be "Pythonistos"? (anybody with Spanish around?)
I mean, i clicked on the link intrigued by promise of [rare] occurrence of female programmers expressing their views on Python vs. Ruby, and read the article somewhat surprised and confused by its tone, style and thought flow - as it was dude's thinking, not gal's :) It is a misleading and deceptive advertising practice :)
AFAIK, you can not apply that in Spanish, You should use the masculine plural gender to refer to both genders, or when the gender of the people is unknown.
There are exceptions to the rule, like the one above (Zapatistas) or some professions like "doctores" or "jueces", but they are exception not the rule. There are also many words that dont have a feminine plural, i.e "las soldados", "las jueces", etc
In Italian it is true that the last letter is not a perfect indication of gender... even for people's names (e.g. Andrea should be a male name). But it works pretty well. Not sure if Spanish is similar (i.e. there are exceptions) or not.
yes, "-a" would lead to "-as".
The "barista" has different origins.
The Python case is similar to the widely used "fashionista" for females and "fashionisto" for males in the fasion. Thus it is expected to be "pythonisto" and "pythonistos" for male(s) until there is some gender confusion :)
Don't. Give them a month or so to start hating Rails. As soon as you attempt to step outside of what Rails is built for or need some new piece of functionality it starts falling apart, not only that but Rails is painful to scale.
As soon as you attempt to step outside of what Rails is built for
Rails is a tool for building database-driven websites. It does this well, and I'm confused as to how you can "step outside of" this. Admittedly Rails probably doesn't help you built a GUI application well.
or need some new piece of functionality
Wait, what?
How did you arrive at this conclusion? Rails doesn't ship with authentication, but there's no less than two (authlogic, restful_authentication) major frameworks for authentication, and countless smaller libraries or self-written tools. The same goes for uploading files (attachment_fu, paperclip), testing (rspec, cucumber, steak, shoulda, ...). The list goes on. Rails' active community is one of the main benefits of using Rails in the first place!
Rails is painful to scale
Rails is no more painful to scale than any other web framework. The bottlenecks for scaling usually come down to application design, not your ORM.
Have you ever even used Rails, or have you prejudged it based on posts by people who also have never used it?
Really? I've been working with it for nearly 4 years now, and I haven't had any problems getting it to what I needed it to do. I wonder what problems that it wasn't "built for" have you had problems implementing?
Also, while scaling may be a non-trivial challenge, going to over ~100,000 page views a day (95% are between 8am - 6pm) was pretty easy, and very little fuss.
While 100k views/day is good traffic it's generally not at the level where I'd consider it 'scaling". Unless you app is very complex or CPU intensive 100k/day should be achievable by out of the box settings on a single server. I've done this with a few different JBoss based applications with zero performance tuning tweaks or issues.
To me real scaling is where you're having to run a cluster since a single server is inadequate to handle the traffic, where you're having to implement or leverage various application caching schemes, etc...
Rails has been dealing with the 'can't scale' accusations forever, even though it has been scaling fine for a lot of people for at least 4 years, if not longer.
But remember that a lot of people who start with Rails are not sysadmins, and may have absolutely no idea how to scale anything. I'd bet they'd probably hit the same scaling trouble if they used anything.
If you listen to folks that have had to scale out to meet demand, you hear the same thing repeated: once you get beyond a certain number of connections, things like choice of language level out and you have other things to worry about. Default installs of WordPress don't scale either, because of database load. That doesn't necessarily mean that WordPress can't scale.
Like anything else, Rails can scale, but often times those deploying it just don't know how. I know I sure didn't when I started out. And every web project I've been on has had different scaling needs. Rails has, in my experience, been easier to scale out than the ASP or PHP apps I used to maintain.
The vast majority of startups don't have to worry about "real" scaling. You don't need to be Twitter or Facebook to make money; in fact, it might help to not be. Especially, if you are actually, you know, charging for a product.
This fascination with scaling is hazardous to the health of both the startup and engineering communities.
100k views/day, while not huge is certainly way more than what the usual application you'd build nowadays is hit with.
To recommend against rails based on the assumption that it'll scale badly in cases where it has to handle more than 100k views per day isn't really helpful.
Once you reach these values, chances are, you'll have team, budget and need for a custom solution anyways.
Now, I'm no rails developer and I never got to really like the framework. So if you ask me, I would find other issues that prevent me myself from using rails (many personal soft-facts - a matter of preference). The (supposed) inability to scale beyond 100k views/day isn't one I'd consider first
To me real scaling is where you're having to run a cluster since a single server is inadequate to handle the traffic, where you're having to implement or leverage various application caching schemes, etc...
Can you explain how Rails doesn't handle this? Because all of my (admittedly limited) experience says it handles it just fine.
I'm not saying Rails does or doesn't handle this at all. I don't use Rails. I was just commenting that the parent response regarding 100k pages/day doesn't really mean that much either way imho.
You don't sound like someone who has had experience with the framework, but is merely regurgitating what other blogs say. You should spend some non-trivial time working with the framework and yes it's not perfect, but it'll probably serve your needs. I too used to criticize Ruby and Rails until I started using them. I think it's too bad how Rails may be over-hyped as an easy-to-use, does-all framework because it sets up high expectations for the beginning developer. It does reward the developer who has put in the time to learn it.
Plenty of experience with the framework. Plenty of experience with Ruby. The scalability issues I was talking about were seen at a fortune 500 company where a Rails app was used for an internal only application.
The major issues with scaling was that Ruby in general is absolutely horrible in managing memory, and was constantly having to be restarted. We ended up replacing the app with one built on top of Java which instead of requiring 6 servers with load balancer in front of it, to just 2 servers, one for the front-end and one for the backend. Java served the needs much better, faster, and didn't require the same amount of administration to constantly make sure that everything is still running properly.
Could the same have been done with Rails? Maybe. Are we happier with the Java based solution, its stability and speed? Yes absolutely.
Java's certainly a more efficient language than Ruby, so it makes sense that you can use fewer machines to do the same thing. The question is always: what's that cost in developer time? Rails is very quick to develop with.
What Java framework did you use, out of curiosity?
Incidentally, I'd be curious to hear about anyone's experience with Scala/Lift - if it's actually as efficient as straight-up Java, and how quick it is to develop stuff with.
I am not at liberty to disclose the technology used unfortunately, otherwise I would have given more information in my previous post.
While rails may be quick to develop with and may be great for prototypes it is not something that is ready for the prime time. The cost to get up to speed in Java was negligible compared to the end result, in that we are now able to have less time spent trying to debug problems because of Ruby not functioning correctly or having to be restarted (we had several tasks that took some database crunching in which ruby would sometimes fall over, or just take up all of the available memory thereby starving other processes and eventually being killed by the oom killer leaving parts of our database in an inconsistent state).
"it is not something that is ready for the prime time."
Thats why millions of users are using hundreds of large scale web apps right now built on Rails and/or Ruby (ie: Github, Slideshare, Hulu, Justin.tv, Basecamp, Alice.com ...the list goes on and on http://rails100.pbworks.com/Alexa+Rankings).
Right...
Might want to do some homework before making such a statement. True Ruby has memory issues. Running Ruby enterprise edition by passenger helped us a ton. Typically memory issues have to do with poorly written ruby more than anything...which rails makes it easy to do....like Product.all.each type stuff ... stupid example
Which is of course, to use the technical term, "bullshit" :-)
There are a lot of statements that you could make that would be fair, like "Java is more mature", or "we have a lot of Java expertise, so it was much easier for us to debug it" or "for our particular needs, Rails simply wasn't suitable", but to say it's "not ready for prime time" is to deny the reality that it is used extensively in "prime time".
There's a middle ground of knowledge where this is true... but once you power through to the other side, and understand how Rails works, you can pretty much make it do anything.
You understand that Twitter's issues weren't due to Ruby on Rails, but due to application architecture, right? If Twitter had implemented the same architecture on top of a Python web library, they'd have had the exact same issues.
Really, in startup-land it doesn't make much difference in the greater scheme of things. If you have the right idea at the right time, and can execute well, the framework (or lack thereof) is irrelevant. Use what makes you productive - even if it's just PHP. At the end of the day it comes down to experience and personal preference, unless the project has very specific requirements (needs libary x for example).
The only legitimate beef we have as developers is when the choice of tools is not our own. If that bugs you, go and do your own thing.
At the end of the of the day everybody has their own style and a framework to go with it. Some people leave Rails to do Django and vice versa. One of them just feels natural as compared to the other. Enjoy your preference!
<for-everybody-commenting-here>
Internals of Rails 3 are much much more simpler and well organized compared to Rails 2.x -- I would seriously recommend getting rid of your fears of "black magic" by diving into the source. :)
</for-everybody-commenting-here>
Great developers can get good results with any language and any framework - some tools are just more effective than others for specific tasks. Rails (and specifically Rails 3) is a great DSL/framework for writing web apps and is actually not too difficult to follow if you want to browse the source code.
Ruby is great, but I don't expect to find myself falling in love with Rails say... hmm, 'ever' sounds good. It's about as likely as getting a Windows 7 tattoo on my forehead.
Hmmm, I am some how scared of things that dont reveal their inner working and still let you build on top.
Infact a major reason i feel people seem to love NoSQL is not because they have application specific needs which nosql solutions can cater well, but rather they are too bored to actually learn a useful language/system.
They just want all the "just works" stuff.
This is another reason why ruby seems to be popular with HTML/CSS crowd.
