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

Question

我听到了很多关于 Scala 和 最近提升了网络框架，尤其是来自Foursquare 的人员 因此，我可能会在下一个项目中使用这项技术。

• 你们中有人是 Scala/Lift 开发人员吗？
  
• 您在此平台上进行开发的经验是什么？它相对于 Ruby On Rails 或 Python/Django 有何优势？
  
• 您认为它是一项可行的技术并且是未来几年“值得关注的事情”吗？
  

值得吗？ 分享您在 Scala/Lift 上的经验平台。

Answer 1

我在 Lift 开发企业财务应用程序超过 6 个月，我以前是 JAVA 程序员。我注意到了几点，这可以帮助你：

1. 我写的代码行明显减少了（很好的例子）

2. Lift 周围有一个非常友善的人 社区。他们总是试图提供实质性的答案。我没有任何不好的经历。甚至他们也愿意接受有关 Lift 新功能的新建议。他们批准了我的两条建议！

3. Lift 的新稳定次要版本大约每 6 - 8 周发布一次。新的里程碑定期每两周发布一次。

4. Lift 是一个很棒的 Web 应用程序框架。您可以了解 Lift 的七个主要功能。

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

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

Answer 2

我目前正在开发我的第二个 Lift 应用程序 - 它非常符合 Lift 的最佳点 - 非常实时，具有大量并发性。

第一个我们在与数据库层搏斗了几天后失败了（我相信现在更好了），然后转而使用 Play/Scala。这最大限度地利用了我们团队的现有知识，并使得按时完成任务成为可能。但是，一旦我们的项目变得相当大（持续耗尽 PermGen - 这几乎在任何地方都是 Scala 编译的一个持续问题），热代码重新加载就几乎不再发生，并且手动处理不同地方的方法调用参数和位置安全等问题在网站上变得相当麻烦。当它完成时我们很高兴 - 就像我倾向于发现 Rails 1 一样，随着项目规模的增加，速度的增加会缩小，到最后它就像在 Velocity/ 中工作一样乏味且容易出错。 Spring/XML++ 等等）。

这一次，我们致力于研究 Lift 如何做它所做的事情，以及做事的正确方法。这意味着要经常浏览邮件列表（几个版本的旧讨论通常仍然相关），最重要的是团队的新精神。有必要非常强烈地内化这句座右铭：

“这感觉很难而且重复。我敢打赌他们做了一个更简单的方法来做到这一点。”

到目前为止，Lift从未让我们失望过。顺便说一句，我不是在谈论像 Sitemap 和列表串联语法这样的东西 - 您必须对功能性 Scala 有很好的掌握，否则您将无法阅读源代码，甚至无法配置您的应用程序。

也就是说，这不是疯狂的 IO monad 或其他什么东西，只是一些你在 Scala 几周内就能学到的常见习惯用法。

对我们来说最大的问题是编译周期缓慢。 jetty:run 我们的项目大约需要 20 秒，这与 Play 不同，Play 会（当它工作时）热编译你的所有东西。另一方面，我们实际上计时了有一天，当我们的一位开发人员抱怨这个问题时，结果发现，尽管 Play 在技术上热编译了它，但该页面在开发模式下加载仍然需要 12 秒。所以并没有太大的损失，只是感觉跳到命令行有点慢。

Lift 可以让您做很多事情，并且在我们的应用程序中有很多地方（因为它可用），我们说过“是的，我们真的希望立即向该页面的所有查看者而不是他们实时更新后来发现它们已经过时了（想想你在 SO 上同时向某人发布的所有时间，到处都是相同的答案，事实证明 - 这不是一个专业的用例，这就是事情的方式）。 Lift 让它变得非常简单，

我们也喜欢强大的、可编程配置的安全模型 - 一旦我们将思维方式转变为“我们必须将每个位置列入白名单，并指定必要的入口条件”，我们就再也没有遇到过另一个会话问题。 - 你知道，那些你假设用户会遍历某个路径，因此会知道一大堆参数？比如，有效的用户名和感兴趣的区域或其他什么（我故意含糊不清？ ）这可能是有状态框架的尴尬之一，当用户点击页面时，您将希望拥有可用的状态，而不是（例如）仅仅要求每个页面都保留所有状态。要求。

我从 Lift 的这次更新中得到的收获是：

这是值得的。不仅构建您正在尝试构建的应用程序，而且构建您不知道自己需要的应用程序。

有很多令人头疼的地方，但代码并不多。当它起作用时，它确实起作用了。它快速、干净，尽管它在浏览器和服务器之间工作的所有奇迹，我从未见过它感到困惑。

Answer 3

1. 我目前的大部分工作都是在 Scala 中完成的。 （我应该提一下，我认为 Scala 是自不久前发明轮子以来最好的东西。:-D ）

   以我的拙见，它是唯一真正允许人们选择最佳任务方法的语言，而不会在（更多）面向对象和（更多）函数式方法之间产生不必要的分歧。

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

   • 来自面向对象方面的人看到函数式编程最近获得了一些关注，并认为“好吧，我们并不真正理解函数式的东西，但让我们在我们的语言中添加一些奇特的语法糖，所以我们可以说它也有功能！” （示例：Java、Python）

   • 然后是来自功能方面的人，他们认为“好吧，我们的功能方法远远优于其他任何方法，面向对象的废话很烦人，但是让我们在我们的语言中添加一些额外的关键字，这将使我们的语言肯定逃离了学术界！” （示例：F#、OCaml）

   Scala 的设计者统一了双方的许多方法，并创建了一些设计良好的语言，以我的愚见，这是与其他语言最大的区别，它决定采用“弗兰肯斯坦”的方法来进行编程语言设计。< /p>

2. 我只用 Lift 做过一些较小的事情，对 Rails 和 Django 也只有肤浅的经验，我不得不承认，大多数时候，当我想知道为什么 Lift 中的某些内容与我的预期不同时，这是因为以下事实：我的期望是有缺陷的，而 Lift 的方法更优越。

   Lift 当然不是“简单的 Scala 入门”，但学习 Lift 的工作原理几乎与学习之前的 Scala 一样有价值。

   拥有一个没有任何逻辑的“干净”视图的能力对于其他声称具有相同功能但未能实现的框架来说是一个巨大的改进。 Scala 的 XML 文字支持可以验证您的响应的格式正确性：编译器将在编译时证明您只向客户端发出格式正确的 XML。

3. Lift 是可行的技术，如果您想构建外观、感觉和行为都像“真正的”桌面应用程序的 Web 应用程序，而无需自己编写大量代码，Lift 是目前唯一真正的方法。