[jaxytee]

"Yes, Scala has Lift but it can’t match the maturity of Django. This overrode the benefits of some of the other libraries/tools that Scala/Java have on offer. Python gets ahead again: 2-1."

How does one come to the conclusion that the maturity of an 8 year old web framework, beats out the benefits of the almost 20 year old battle tested Java ecosystem. Not to mention the Scala Ecosystem is included as Icing on the JVM cake. OP also compared Lift to Django. How does OP not mention Play? Although an argument about the better of the two would be based strictly on opinion, from my view Play has more momentum in the race for the premier Scala Web Framework.

[omaranto]

Wait, are you comparing the ages of Django and Java? Wouldn't it be fairer to compare the ages of Python and Java? Python is about four years older than Java.

[jaxytee]

I'm referring to the comparison made by OP.

[ankitml]

"Scala has Lift but it can’t match the maturity of Django."

Clearly 'it' here refers to Lift and not Scala/Java. Comparisons are never made between apples and oranges.

[zubinmehta]

We were merely in search of a good web framework. Java has battletested libraries but so does python and a lot of other general programming languages. It still isn't answering our core question. A decision on what web framework to use has much more to do with the framework itself(its philosophy and community) than with the language it is built in.

Coming to django, I would argue that it is the best documented project on this planet! Django has a huge number of plugins, quickens the process, and is based on some amazing philosophies(DRY) and you happen to admire what a big deal it is when you go deep into design of your web app.

Also, I can even argue that I can get a programmer who doesn't know python to start on Django in 4 hours. Now, I wouldn't bank on this point as it is a language ecosystem point, but it is a true fact, happened to me some years ago.

Lift, is cherry picking features from django/rails, which is actually a good thing, but I see it being a lot less progressive as compared to Django even at the scale at which Django is right now.

Play, I haven't used, so cannot argue much on that. I think Play2 is less than a year old? Surely, I cannot let my startup developers write more bytes than necessary. Why code something which is already done and that is precisely what happened with us when we started working with Django. Well tested libraries can be pip installed.

[m501]

Play is definitely more akin to django than lift is. Lift, as I've read not experienced, has specific philosophy for how to build web apps that is slightly different than django or play.

I'm a long time django user. I love django. I've used it in production apps. I like to try out new languages as a hobby and so I got myself the programming in scala and the Play framework in action (manning). Just trying out Play however I can't seem to get this feeling that I could do it more easily and faster in django, though that may be because I'm comfortable with django and python. There are also a ton of django apps that I can leverage to build out parts of my app. I'm not sure about the play ecosystem in that respect.

I'm also specifically looking for advantages that the language itself can bring but since I haven't gotten very far I haven't discovered any yet but I'm hopeful that I will be pleasantly surprised.

Having said all that I just saw some play love coming from LinkedIn: http://engineering.linkedin.com/play/play-framework-linkedin

[mjt0229]

Er. If your startup developers can't write more bytes than necessary, why are you publicly doing a shoot-out? You clearly can't afford to explore all reasonable options. You're wasting everyone's time if by cherry picking outdated Scala frameworks to compare to the state-of-the-art Python frameworks.

[zubinmehta]

Firstly, this isn't a shoot-out. I apologize if the title feels that way. It's our account on why we chose one(language) over the other looking into various real-life variables, not just web frameworks.

>> You clearly can't afford to explore all reasonable options. How else would we know which one to go with and save extra bytes?

Lift/Play are surely not outdated. I am just stating objective facts that led us to one over the other.

Read both the articles we have posted to get a flavour :)

[mjt0229]

I was responding to your comment that you had not looked at Play 2.0. I would not argue that it's outdated, I am arguing that if you excluded it from consideration, you missed something.

[zubinmehta]

I agree. We skimmed through and figured it's very new, so didn't explore more.

[justinsteele]

Technically he missed lots of things - there are hundreds of frameworks.

[cover_drive]

The blog post is for startup founders who are making very early-stage decisions on technology, hiring, funding etc. If you are not one of those, it's probably not very useful to you. We did receive appreciatory comments from people. I'm not sure why you say "wasting everyone's time" ...

[lmm]

The Java ecosystem is not terribly usable from Scala - even if you can call all the methods, it's not idiomatic, it will expect Java collection types etc. And few of the worthwhile parts of Java's libraries are 20 years old.

You can build cool stuff in scala + e.g. wicket, I've done it, but there's an extra layer of awkwardness to deal with that doesn't exist with python/django.

[willismichael]

Could you further explain why calling Java methods from Scala is not idiomatic? I have virtually no real exposure to Scala, but a decent amount of Clojure experience. I've found in my pet Clojure project that it's not really painful to wrap up calls to Java libraries in idiomatic clojure (in fact I'm writing the graphics renderer in Java for performance). Does Scala really make it that much trouble to call Java methods?

[lmm]

Scala makes it as easy as it can, but it just feels awkward; collection types are the most obvious thing; method names don't follow the same conventions, different types are expected for callbacks (you can use implicit conversions to mitigate this, but it's still a bit cumbersome), Java libraries sometimes return null in a way that no Scala library would. Some libraries expect classes that follow the JavaBean conventions, which look hideous in Scala (there's an annotation to tell scalac to generate JavaBean methods but it won't count them for implementing interfaces, so it's not actually useful). There are no showstoppers and it would probably be hard to do better when the languages are so different, but there's just loads of little niggling irritations to slow you down.

[cover_drive]

Are you suggesting that we should go with Lift/Play instead of Django? If so, can you elaborate on your argument? As you can tell from the article, I'd love to see Scala beat Python, but I can't see Scala scoring over Python on the web framework front.

[jaxytee]

I'm not in a postion to suggest what web framework your team should go with. I think that depends on the development taste and needs of your team. My main purpose was to point out the oversite of the Play Framework in the orignal article. FYI the only interest I have in pushing Play is that of a Scala developer who has tried Play and Lift. I found Play to be more approachable and modern. Especially for developers with MVC framework experience.

[Avshalom]

Most of the Java ecosystem you'd be using is not 20 years old.

[jaxytee]

On that same note, most of the Django ecosystem isn't as mature as Django either. What point are your trying to make?

[mhaymo]

You can't claim that Scala is more mature than Python just because it's built on the (very mature) JVM. You have to look at the tools you will actually be using, and neither Play nor Lift are as mature as Django, nor is Scala the language as mature as Python.

[jaxytee]

I never claimed scala was more mature than Python. I'm referencing the argument OP made. You just created the illusion of me comparing Scala to Python. Read my comments if you don't believe so.

[mhaymo]

Well the OP is about Scala vs Python, so forgive us for assuming you were speaking on-topic.