It's interesting that Foursquare sees Scala and Lift as a critical technical advantage but Gowalla seems to be competing just fine with their Rails stack.
Both are still pretty small (I haven't even heard of Gowalla), so it seems too early to make any judgments yet. The critical technical advantage, if it exists, will probably make itself really known once they grow a couple of orders of magnitude.
You might want to back up "competing just fine" with something.
Numbers on Compete (http://siteanalytics.compete.com/foursquare.com+gowalla.com/) suggest that Foursquare is pushing quite a bit more traffic than Gowalla, at least on the web. Most reports suggest that Foursquare is also beating out Gowalla in terms of users.
(Full disclosure: I have friends at Foursquare, Gowalla, and on the Lift project. I don't really care about any one of them "winning", I just like facts.)
I guess I was speaking more anecdotally, in terms of both sites providing roughly equivalent functionality and supporting non-trivial load. Thanks for the analytics link though. I didn't realize the traffic disparity was that high.
Glad to see they are now supporting Scala 2.8 but...
what happened to their website? I seem to recall a vastly different appearance before. If the look of the Lift website is an indicator to first time visitors of the quality of the framework, I wonder how many visitors don't get beyond the initial landing page.
Here's what I noticed immediately in about a minute:
-Not a lot of contrast for colors to help material stand out
-Lack of contrast leads to difficult reading on tired eyes and I'm only 30 something
-Page balance - Small main content area compared to long running side panel
-The quote box just looks ... meh
-No favicon
-The icons of the groups/companies using the framekwork appear to have a lot of artifacts in them
I really like Scala but this site redesign is probably not helping win new users to the framework.
I've been working with Lift a bit. It is very different from any other web framework I've ever used. That said, there's some real brilliance in it, especially how Comet and Ajax work. Lately, it's gotten a lot easier to work with, as the IDE has gotten into a usable state.
The learning curve is pretty steep though. You have to learn Scala, The Java APIs and the non-traditional approach to web development that Lift takes. That, and it's a young ecosystem. There aren't 101 e-commerce shopping cart systems written in it yet.
I use Eclipse. For a while, during the Scala 2.7 to 2.8 transition, the Scala support was so bad I actually switched back to Emacs. Now it's fairly usable, though not as full featured as the Eclipse's Java support. I would also highly recommend you setup JRebel with Lift. It makes the development cycle go much faster.
Thing that bugs me about Lift (last time I looked) is that it only supports sticky sessions. If the server your session is on goes down, you lose your session.
Not to my knowledge. The problem isnt just data that could be serialized between app servers-Its the closures associated with the sessions (eg for submitting forms).
Not directly, but it shouldn't be that difficult to just write what data you want to make permanent to some database and then give the user a cookie (outside the session) to use if you lose the session.
David Pollack, Lift founder, has this to say about sticky sessions and scaling (paragraphs added):
"In practice, scaling a Lift site is much much easier than scaling a LAMP site. Why? Well, state exists someplace. If it exists in the JVM, you get a lot of performance benefits and stability as well as, in Lift's case, lots of security.
Contrast that with sessions in memcached. "Whoop, memcached went down, there go a pile of sessions." "Whoops, we've got a new memcached hashing algorithm, there go all the session." "Whoops, Google just crawled us creating 200,000 new sessions pushing all the but the active sessions out of cache." "Whoops, the Ruby runtime just went wild, ate all the VM on one of our boxes, memcached went down..."
So, you try storing sessions in some wacky shared version of MySQL. This solution requires tons of hardware and a team of make sure that the sharing code is correct, etc. Contrast that to using Nginx, Jetty and session affinity. It's about 4 hours of setup time and it just works. See http://blog.harryh.org/post/7550...
So, talk to a Facebook engineer about the challenges they go through to manage state between the front end, memcached, MySQL, etc. Compare that to Twitter with the famous fail whale. Compare that to Apple's store and the iTunes store which are written on WebObject (which is highly stateful.)
Lift apps running at scale typically require 7% of the front end resources of LAMP app. The Lift apps that are running at scale (Foursquare and Novell pulse are two) do not have the kind of scaling issues associated with LAMP sites that have similar traffic patterns. Scaling with Lift is neither tricky, nor risky. It's simple. It's known. It's proven. Scaling with LAMP is playing whack-a-mole with state and that only becomes a problem at scale."
See his comment under Jackson Davis's answer to this question:
Lift has the most natural comet abstraction I've used, but using lift's 1.0 ORM felt a little raw and the API has a steep learning curve. The sheer amount imports at the top of a class can get ugly, especially when working w/ heavy javascript. While waiting for 2.0 to have some more documentation and Record to replace Mapper, I've looked at some of the Play! Framework which seems to very straightforward scala support. Abandoning HttpServlet makes me nervous and response streaming isn't supported (no real comet), but Play! is a really refreshing web framework w/ scala support. Don't expect all forms of scalate to work though despite having a module for it.
I don't have any issues w/ the new liftweb site look and feel. That shouldn't be a deal breaker for a quality web framework. For example, HN seems to have a large hadron collider over clojure -- anyone remember what the non-github compojure website looks like?
Anyone have any success w/ the tar/zip link on the liftweb download page? Broken links for me; sad panda. :(
Lift and Play! embody very different philosophies of web development, but if you want something closer to the common MVC frameworks Play! is very nicely done.
Well if you mean Model/Controller/Route first vs View first, yes they are philosophically different. But I meant more along the lines of how friendly the API is. An additional example would also include the fact that although Lift has come a long way in providing meaningful error information, by contrast Play!'s take on it is just a breath of fresh air. This isn't to say that Lift is doing it wrong; it's error messaging is less arcane than some other web frameworks.
I agree that Play shows a lot of polish and attention to detail. I haven't done anything significant with it but it was very pleasant for the few simple things I tried.
38 comments
[ 3.9 ms ] story [ 73.0 ms ] threadEdit: Nevermind, found the answer on Quora - http://www.quora.com/Why-did-Foursquare-choose-Lift?q=foursq...
These slides go into a little more detail on Foursquare's switch to Lift: https://docs.google.com/present/view?id=0ATHAG0M-0vxXZGNicHo...
http://siteanalytics.compete.com/foursquare.com+gowalla.com/...
Numbers on Compete (http://siteanalytics.compete.com/foursquare.com+gowalla.com/) suggest that Foursquare is pushing quite a bit more traffic than Gowalla, at least on the web. Most reports suggest that Foursquare is also beating out Gowalla in terms of users.
(Full disclosure: I have friends at Foursquare, Gowalla, and on the Lift project. I don't really care about any one of them "winning", I just like facts.)
Did anyone do a req/second analysis between scala and rails?
what happened to their website? I seem to recall a vastly different appearance before. If the look of the Lift website is an indicator to first time visitors of the quality of the framework, I wonder how many visitors don't get beyond the initial landing page.
Here's what I noticed immediately in about a minute: -Not a lot of contrast for colors to help material stand out -Lack of contrast leads to difficult reading on tired eyes and I'm only 30 something -Page balance - Small main content area compared to long running side panel -The quote box just looks ... meh -No favicon -The icons of the groups/companies using the framekwork appear to have a lot of artifacts in them
I really like Scala but this site redesign is probably not helping win new users to the framework.
Seems like it could be valuable competition for http://scalaquery.org/
The learning curve is pretty steep though. You have to learn Scala, The Java APIs and the non-traditional approach to web development that Lift takes. That, and it's a young ecosystem. There aren't 101 e-commerce shopping cart systems written in it yet.
Is there a way around this in Lift yet?
"In practice, scaling a Lift site is much much easier than scaling a LAMP site. Why? Well, state exists someplace. If it exists in the JVM, you get a lot of performance benefits and stability as well as, in Lift's case, lots of security.
Contrast that with sessions in memcached. "Whoop, memcached went down, there go a pile of sessions." "Whoops, we've got a new memcached hashing algorithm, there go all the session." "Whoops, Google just crawled us creating 200,000 new sessions pushing all the but the active sessions out of cache." "Whoops, the Ruby runtime just went wild, ate all the VM on one of our boxes, memcached went down..."
So, you try storing sessions in some wacky shared version of MySQL. This solution requires tons of hardware and a team of make sure that the sharing code is correct, etc. Contrast that to using Nginx, Jetty and session affinity. It's about 4 hours of setup time and it just works. See http://blog.harryh.org/post/7550...
So, talk to a Facebook engineer about the challenges they go through to manage state between the front end, memcached, MySQL, etc. Compare that to Twitter with the famous fail whale. Compare that to Apple's store and the iTunes store which are written on WebObject (which is highly stateful.)
Lift apps running at scale typically require 7% of the front end resources of LAMP app. The Lift apps that are running at scale (Foursquare and Novell pulse are two) do not have the kind of scaling issues associated with LAMP sites that have similar traffic patterns. Scaling with Lift is neither tricky, nor risky. It's simple. It's known. It's proven. Scaling with LAMP is playing whack-a-mole with state and that only becomes a problem at scale."
See his comment under Jackson Davis's answer to this question:
http://www.quora.com/What-are-the-advantages-and-disadvantag...
(I've never use Lift or Scala.)
I don't have any issues w/ the new liftweb site look and feel. That shouldn't be a deal breaker for a quality web framework. For example, HN seems to have a large hadron collider over clojure -- anyone remember what the non-github compojure website looks like?
Anyone have any success w/ the tar/zip link on the liftweb download page? Broken links for me; sad panda. :(
It sucked ;)
However, Lift is several years older than Compojure, and is now in its second stable release, whilst Compojure has yet to reach 1.0.
Sinatra would be even easier if you're doing something simple.
Edit: very curious as to the reason for downvotes on this. If you have a better answer, give it.
http://docs.djangoproject.com/en/dev/howto/jython/