Scala准备好迎接黄金时间了吗？[关闭]

现在，我已经用Scala做了一些琐碎的事情（我喜欢“ hello world”和人为设计的应用程序！），我不禁要问：。一部分关于支持开发的工具的成熟度，一部分关于通用性。工具集准备好了吗？Scala是否适合在企业/业务应用程序上使用？“您”会在非平凡的项目上使用它吗？

我的一些担忧（可能没有根据）是：

• IDE和工具集是否像我们开发.net和Java应用程序所需要的那样丰富（与Java的eclipse相比，Scala的eclipse似乎有限）？
• / CI /测试工具集能够有效处理Scala吗？
• 如何维护是简洁的代码可以被（鼓励？）写的语言？
• 是否可以找到具有Scala经验的开发人员？
• 是否有足够的临界质量来通过在线参考书和比该语言“入门”更多的书来获得帮助？

因此，底线是生态系统是否已经足够成熟，可以立即使用，还是更好地等待它的发展？

编辑：让我们说“非同寻常的”是一个多年，多次发布的10-20个开发人员项目。

虽然确实在监护人和Twitter上广泛使用了Scala，但存在一个基本问题。

Java的普及很大程度上是因为它相对易于阅读和维护。Scala在这里有一个问题，因为它可以用许多不同的样式编写。OO样式与功能样式是这里的明显区别，但是当您谈论Scala的3个级别时，它变得更加复杂。

您需要确保您的团队和任何潜在的新员工都可以遵循相同的风格，并且该风格足够简单，以使您实际上能够聘请有效的开发人员（并非每个人都可以聘用前2％的人才） 。

虽然我希望这个差距会很快消除，但工具支持还不存在。您还可以从TypeSafe人群中获得对完整Scala堆栈的支持。我认为Scala将开拓自己的利基市场，但是直到真正将语言构建到语言/编译器/任何语言中为止，在最初1-2年的激动人心的生产力之后，我看到团队的维护工作变得头疼。

有关更多详细信息，请参见此相关答案。

Twitter和The Gaurdian目前都使用Scala，因此它肯定适用于非平凡的应用程序。

Scala程序员会很有动力，而且可能会非常好。选择一种新的语言是吸引人才的好方法。

当然，Scala程序员通常没有专业的Scala经验，他们使用的习惯用法可能有所不同。有些人可能会争取类似Haskell的纯净性，而另一些人可能会将其视为带有闭包的Java。因此，开发一致的编码标准和约定可能会花费一些时间。

尽管IntelliJ Idea可能值得在Eclipse上进行投资，但许多Java工具都可以很好地运行。

总体而言，如果您可以控制项目，那么这将是一个不错的选择。如果这是一家大型保险公司的一部分，那么如果存在诸如以下的体系结构准则，则可能会遇到问题：“所有项目都将由Maven构建并部署在WebSphere中。” （我没有理由认为此特定规则会成为问题，但是此类规则的泛滥可能会在某个时候使您绊倒。）

我的印象是，“常规”语言（如Java）附带的许多生态系统都旨在弥补它们的笨拙性。

问题不是给定语言（Scala）有多少个工具，而是该语言的现有工具是否比参考语言（Java）的现有工具更好。因为100种平庸的工具不会给您，所以哪一种好的工具可以给您。而且您不应该忘记的是，语言本身就是这些工具的一部分。

语言的说明性

• 与使用它产生的错误的数量和严重程度成反比，这就是Java非常擅长产生错误的原因，并且您需要很多工具来避免和跟踪它们
• 与您的生产率成正比，这就是Java非常冗长且您需要大量代码生成器和类似工具的原因

例如，我曾经读过一个Ruby家伙的可怕博客帖子，他认为静态类型化是没有意义的，因为您的测试将涵盖类型安全性。显然这是由尚未使用表达静态类型系统的人提供的。假设我可以用一种语言语义表示所有类型关系，并且要做的工作不多（而且由于大多数现代语言都支持类型推断，所以不是），我可以免费获得所有这些。

进一步思考：单元测试可确保单元按照指定的方式运行，或者换句话说，单元测试是可运行的规范。但是，通过声明式编程，单元本身就是可运行的规范。同样，您可以免费获得一些东西。

我要说的是，您不应低估语言功能可以为您做的事情。而且，除非您真的在野外尝试过它们，否则您将永远无法理解。

回到原始问题：现有的Scala工具是否比Java更好？很难说。取决于您要做什么。我认为我们都同意该语言要好得多，现在的问题是，您将在业务领域中找到一个良好的生态系统。
对于网络，Lift确实是一个不错的选择。不了解台式机或移动设备。

假设“不平凡的”是一个多年，多次发布的10-20个开发人员项目。

那有很多风险。奖励必须是值得的。在企业业务应用程序和中大型项目的世界中，冒险通常受到限制。或者更确切地说，已经有足够的风险要应对……可预测性更为重要。

我怀疑收养会那样工作。

首先是由少数人从事包含风险的部分（如POC，非关键组件，测试）或Scala似乎可以比其他方法更好地解决问题的部分（可能涉及某些部分）开始例如，演员）……然后，随着工具的成熟，社区不断壮大，公司的专门知识也在不断壮大，然后它就可以扩展。

通过利用Java运行时，Scala无疑已准备就绪。如果可以部署Scala应用程序，则在生成字节码后，它应始终与该特定版本的Java运行时一起使用。基于Scala的库将像您熟悉的任何其他Java第三方库一样工作。

就IDE，构建工具和其他所有方面而言，Scala的扩散程度与Java不同。因此，您没有很多基于Scala的框架或基于Scala的工具。与Java的普及相比，与Scala的日益普及相比，这要说的更多。Scala的功能性工具包括Scala IDE和sbt构建工具。但是它们不像其他一些纯Java帮助程序工具那样复杂。

@huynhjl和@FarmBoy的摘樱桃点：

• 寻找足够多有经验的Scala程序员可能很困难。

• Scala的“最佳实践”教条仍在发展（*）。

• 样式指南，约定等仍在不断发展（*）。

• 工具支持仍在不断发展（*）。

综合考虑，您可能会问（您自己/自己）一个更好的问题：您的组织是否准备在“非平凡”的项目上使用Scala？您是否有能够应付这么多“还在发展中”的事情的人？相反，最好先做一个较小的项目吗？

（*实际上，大多数语言仍在这些方面中的一个或多个方面发展。这里的问题是变化/变化的速度 ……以及您的团队是否可以应对。）

Good Stuff的David Pollak撰写了一篇很棒的博客文章，标题为“ 功能语言将统治（但今年不行）”，其中涉及到功能语言的细节，我强烈建议您阅读Scala，以更好地了解Scala是否已准备好黄金时间。

我从不了解enterprise和non enterprise程序之间的区别。

我在工作中使用的程序与在家中使用的程序相同。我不会在业余时间使用平庸的程序-为什么我应该这么做？

什么是非专业课程？我已经看到使用了糟糕的应用程序，因为用户不了解更好，或者由于兼容性问题，或者用户拒绝提供新的东西。

但这是一个过时的软件和一个目标的问题，开发人员已经想到了-而不是语言，程序是用这种语言编写的。如果您开始考虑，用哪种语言编写程序，那就已经结束了：失败。

Enterprise-应用程序是一个营销术语，对认真讨论没有用。

哪个客户知道您使用哪种语言完成工作？有时他们在乎，有时他们不在乎。

您可能会遇到与语言成熟度有关的问题-但是您无法针对所有类型的企业和所有应用程序回答该问题。