最近我聽到了很多關於Scala和Lift Web框架的好消息，特別是Foursquare's guys，因此我可能會在我的下一個項目中使用這種技術。您在Scala/Lift中發展的經驗是什麼？
值得嗎？分享您在Scala/Lift平臺上的體驗。
我目前正在斯卡拉做我的大部分工作。 （我應該提到，我認爲斯卡拉是自從前一輪發明以來最好的事情：-D）
在我的愚見中，它是唯一真正允許人們選擇最好的方法（更多）面向對象和（更多）功能方法之間沒有不必要的分歧。
看着這之前聲稱像這樣的語言，我基本上可以看到兩個相互競爭的語言設計陣營：
其中看到了函數式編程獲得了一些牽引力近來，從面向對象的側一和「好吧，我們並不真正瞭解這個功能性的東西，但是讓我們在我們的語言中添加一些花哨的語法糖，那麼我們可以聲稱它也是功能性的！」 （例如：使用Java，Python）
然後從功能側面的，誰想到「好了，我們的功能的方法是遠遠優於其他任何東西和麪向對象的廢話是討厭，但讓我們把一些額外的關鍵字加入我們的語言，這將使我們的語言無法逃避學術界！「 （例如：F＃，OCaml的）
Scala的設計師統一許多方法從雙方未來和創造了一些精心設計的語言，這是 - 在我的愚見 - 最大的不同其他語言，這就決定採用「弗蘭肯斯坦」方法編程語言設計。
在使用Lift完成較小的事情之後，只有Rails和Django的表面經驗，我不得不承認，大多數時候我想知道爲什麼Lift中的某些工作與我預期的工作方式不同，這是由於事實是我的期望有缺陷，Lift的方法更勝一籌。
電梯當然不是「簡單介紹斯卡拉」，但學習電梯如何工作幾乎像在之前學習Scala一樣有益。
在沒有任何邏輯的情況下擁有「乾淨」視圖的能力對其他聲稱相同但沒有達到它的框架有很大的改進。Scala的XML文字支持可以驗證響應的格式良好：編譯器會在編譯時證明您只向客戶端發送格式良好的XML。
電梯是可行的技術，目前唯一的真正的方法，如果你想構建Web應用程序的外觀，感覺和行爲像「真實」的桌面應用程序，而無需自己編寫瘋狂的代碼量。
我在開發企業財務應用程序超過6個月，我是JAVA程序員前。我已經注意到了幾個點，這可以幫助你：
我寫碼（great example）的顯着更少的線
電梯周圍有強個很慈祥community。他們總是試圖提供實質性答案。我沒有任何不愉快的經歷。即使他們願意提供有關Lift新功能的新建議。他們批准了我的兩條建議！
Lift的新穩定小版本每6到8周宣佈一次。新的里程碑每兩週定期舉行。
Lift是Web應用程序的絕佳框架。你可以閱讀關於Lift的七個main features。
提升默認的ORM模塊 - Mapper不適用於大量和高級數據庫模型，這些模型有很多外鍵和約束。我們必須使用Squeryl。
我無法想象我現在必須返回到JAVA代碼。但我的小建議是嘗試編寫一些簡單的應用程序，你會看到。
我正在研究我的第二個Lift應用程序 - 它在Lift的最佳位置非常強大 - 非常實時，併發性很強。
第一個我們在與數據庫層面搏鬥了幾天後（現在比較好，我被引導相信），然後去了Play/Scala。這最大限度地提高了我們團隊的現有知識，並能夠限定期限。但是，一旦我們的項目變得很大（一直持續用完PermGen - 幾乎任何地方都是Scala編譯的持續問題），並且在不同的地方手動處理諸如方法調用參數和位置安全性之類的問題，熱代碼重新加載幾乎停止在網站上相當麻煩。我們很高興它完成後 - 就像我傾向於找到Rails 1一樣，隨着項目規模的增加，速度增加會縮小，並且最終它在工作在速度/ Spring/XML ++）。
這一次，我們一直致力於研究Lift如何完成它所做的事情以及正確的做事方式。這意味着通過郵件列表進行大量的隨意瀏覽（幾個版本的討論往往仍然相關），最重要的是爲團隊提供了一種新的氛圍。有必要非常強烈地堅持格言：
「這是感覺艱難和重複，我敢打賭，他們做了一個更簡單的方法來做到這一點。」
到目前爲止，Lift從未讓我們失望。順便說一句，我不是在談論像Sitemap和列表連接語法這樣的東西 - 你必須在功能性的Scala上有一個相當不錯的句柄，否則你將無法讀取源代碼甚至不能配置你的應用程序。
說這不是瘋狂的IO monads或任何東西，只是一些常見的習慣用法，無論如何你會在幾周的Scala中找到它。
對我們來說最大的問題是編譯週期很慢。碼頭需要大約20秒的時間：運行我們的項目，這與Play的感覺不一樣（當它工作時）熱點編譯所有的東西。另一方面，我們實際上是在我們的一位開發者抱怨這一點的時候計算的，結果發現儘管Play技術上熱門編譯它，但頁面仍然需要12秒才能加載Dev模式。所以不會有巨大的損失，只是感覺有點慢，不得不跳出命令行。
Lift可以讓你做很多事情，而且在我們的應用程序中有很多地方（因爲它可用），我們說過「是的，我們真的希望立即更新到該頁面的所有觀衆，而不是他們後來發現他們已經過時了（想想你曾經同時發佈給SO上的某個人，同樣的答案）COMET無處不在，事實證明 - 這不是專家用例，
我們也喜歡強大的，可編程配置的安全模型 - 一旦我們將我們的心態轉換爲「我們必須將每個位置列入白名單，並指定必要的入口條件「，我們從來沒有看到過另一個會話問題 - 你知道，那些你在哪裏認爲用戶會遍歷某條路徑，從而知道一大堆參數？就像一個有效的用戶名和一個感興趣的領域或其他什麼？ （我故意模糊）。這可能是有狀態框架的一個尷尬之處，那就是當用戶點擊一個頁面時你想要有可用狀態，而不是（例如）只是要求每個請求都攜帶所有狀態。
我從這一新的鏡頭外賣在電梯：
這是值得的。不僅要構建您正在嘗試構建的應用程序，還要構建您不知道需要的應用程序。
有很多頭部劃痕，但不是很多的代碼。當它工作時，它確實有效。它快速，乾淨，並且對於瀏覽器和服務器之間的所有奇蹟，我從來沒有看到它會感到困惑。
有趣的問題。就我個人而言，我有興趣聽聽過去曾與Rails/Django合作並且正在與Lift合作的開發人員。 （我的意思是，來自實際有資格進行比較的人） – jvdneste 2010-09-05 07:10:07
@jvdneste：Lift自己的作者David Pollak是一位Rails開發人員，並且專門創建了Lift作爲對Rails的反應。 – 2010-09-05 11:07:15