您在Scala/Lift中开发的经验是什么？

Question

我最近听到了很多关于Scala和Lift Web框架的好东西,尤其是来自Foursquare的人,因此我可能会在我的下一个项目中使用这项技术.

• 你们中的任何人都是Scala/Lift Developers吗？
  
• 您在此平台上开发的经验是什么？与Ruby On Rails或Python/Django相比,它有哪些优势？
  
• 您是否认为它是一种可行的技术,并且在未来几年内"值得关注"？
  

这值得么？在Scala/Lift平台上分享您的经验.

Answer 1

1. 我现在正在Scala做我的大部分事情.(我应该提一下,我认为Scala是不久前发明轮子以来最好的东西.:-D)

   在我看来,它是唯一真正允许人们选择最佳方法来完成任务的唯一语言,而不会在(更多)面向对象和(更多)功能方法之间产生不必要的分歧.

   看看之前声称类似的语言,我基本上可以看到两个相互竞争的语言设计阵营:

   • 从面向对象的那一方看到函数式编程最近获得了一些牵引力并且认为"好吧,我们并不真正理解那个功能性的东西,但是让我们为我们的语言添加一些花哨的语法糖,所以我们可以声称它是功能性的太!" (例子:Java,Python)

   • 那些来自功能方面的人,他们认为"嗯,我们的功能方法远远优于其他任何东西,而且面向对象的废话很烦人,但我们在我们的语言中添加了一些额外的关键词,这将使我们的语言在学术界得到肯定!" (例子:F#,OCaml)

   Scala的设计师统一了来自双方的许多方法,并创造了一些精心设计的语言 - 这是我认为 - 与其他语言的最大区别,后者决定采用"弗兰肯斯坦"方法进行编程语言设计.

2. 我只使用Lift完成了较小的事情,只使用Rails和Django的表面经验,我不得不承认,大部分时间我都想知道为什么Lift中的某些东西与我的预期有所不同,这是因为我的期望是有缺陷和Lift的方法优越.

   Lift当然不是"Scala的简单介绍",但了解Lift的工作原理几乎和学习Scala一样有价值.

   能够拥有一个没有任何逻辑的"干净"视图的能力对于声称相同的其他框架是一个很大的改进,但没有达到它.Scala的XML文字支持使得验证响应的良好性能成为可能:编译器将在编译时证明您只向客户端发出格式良好的XML.

3. Lift是一种可行的技术,目前是唯一真正的方法,如果您想构建外观,感觉和行为类似于"真实"桌面应用程序的Web应用程序,而无需自己编写疯狂的代码.

Answer 2

我正在研究我的第二个Lift应用程序 - 它在Lift的最佳位置非常强烈 - 非常实时,很多并发性.

第一个我们在与DB层摔跤几天之后就畏缩了(现在它变得更好了,我被引导相信),然后去了Play/Scala.这最大化了我们团队的现有知识,并使截止日期成为可能.但是,一旦我们的项目变得适度大(PermGen不断运行 - 这是Scala编译几乎无处不在的问题),并且在不同的地方手动处理方法调用参数和位置安全等问题,热代码重新加载几乎停止了.在网站上相当繁琐.当它完成时我们很高兴 - 就像我倾向于找到Rails 1一样,随着项目规模的增加,速度增加了,并且到最后它在Velocity中工作时变得乏味且容易出错. Spring/XML ++等等.

这次我们一直致力于研究Lift如何做它所做的事情以及正确的做事方式.这意味着要通过邮件列表进行大量的随意浏览(多个版本的讨论通常仍然相关),最重要的是团队的新精神.有必要非常强烈地内化这个座右铭:

"这种感觉很难反复.我敢打赌,他们做了一个更简单的方法."

到目前为止,Lift从未让我们失望过.顺便说一下,我不是在谈论Sitemap和列表连接语法之类的东西 - 你必须对功能Scala有一个很好的处理,否则你将无法阅读源代码甚至配置你的应用程序.

那说它不是疯狂的IO monads或者其他任何东西,只是你在Scala的几周内会发现的一些常见的习语.

对我们来说最大的问题是编译周期缓慢.跳船需要大约20秒钟:运行我们的项目,这是一种与Play不同的感觉(当它正在工作时)热编译你所有的东西.另一方面,我们实际上是在我们的一个开发者抱怨它的那一天,并且它确定尽管Play技术热门编译它,但页面仍然需要12秒才能在开发模式下加载.所以没有巨大的损失,只是感觉有点慢到必须跳到命令行.

Lift让你做了很多事情,我们的应用程序中有很多地方(因为它可用),我们已经说过"是的,我们真的希望将该实时更新直接更新到该页面的所有观看者,而不是它们后来发现它们已经过时了(想想你曾经在SO上同时发布的所有时间,同样的答案).COMET无处不在,事实证明 - 它不是专业用例,它是事物的方式应该工作.而Lift让它变得非常简单.

我们也喜欢强大的,可编程配置的安全模型 - 一旦我们将思维模式转换为"我们必须将每个位置列入白名单,并指定必要的入口条件",我们从未见过另一个会话问题 - 您知道,那些您认为用户会遍历某条路径,从而知道一大堆参数？比如,有效的用户名,感兴趣的区域或其他什么？(我故意模糊).这可能是关于有状态框架的尴尬事情之一,当用户点击页面时,您将希望具有可用状态,而不是(例如)要求所有状态在每个请求中被携带.

我从Lift的重新拍摄中得到的结论:

这很值得.不只是构建您正在尝试构建的应用程序,而是构建您不需要的应用程序.

有很多头疼,但不是很多代码.当它工作时,它确实有效.它快速,干净,而且对于它在浏览器和服务器之间工作的所有奇迹,我从来没有看到它变得困惑.

Answer 3

我在Lift开发企业财务应用超过6个月,我是JAVA程序员前者.我注意到几点,可以帮助你:

1. 我写了明显更少的代码行(很好的例子)

2. 在Lift附近,有一个非常友善的社区.他们总是试图提供实质性的答案.我没有任何糟糕的经历.即使他们愿意为Lift中的新功能提供新建议.他们批准了我的两条建议!

3. 每隔6到8周就会公布新的稳定次要版本的Lift.每两周定期举办一次新的里程碑.

4. Lift是Web应用程序的绝佳框架.您可以阅读有关Lift的七个主要功能.

5. 提升默认ORM模块 - Mapper不适用于具有大量外键和约束的大型和高级数据库模型.我们不得不使用Squeryl.

我无法想象我现在必须返回JAVA代码.但我的小建议是尝试编写一些简单的应用程序,你会看到.