D2语言准备好投入生产了吗？

如何解决D2语言准备好投入生产了吗？

|                                                                                                                       

解决方法

我还不认为D2可以投入生产，但是已经接近了。语言定义相当稳定。此时几乎不会发生重大变化（尽管可能会发生一些旨在消除语言中关键问题的附加变化）。编译器的开发进展非常迅速，许多错误已得到修复。但是在这一点上，如果大量使用D2，则会遇到编译器错误，尤其是在使用较新的语言功能时。而且尚未完全实现所有这些功能（例如

alias this

和

inout

），因此尽管TDPL大部分是正确的，但dmd仍然落后于它。 同样，虽然标准库Phobos总体上非常好，并且大部分稳定，但仍在进行中。我们试图通过将要删除的内容按照正确的弃用路径放置（通常计划在弃用前6个月，在完全删除之前弃用6个月）来避免造成重大更改，但有时确实会发生重大更改（有时，编译器会因为工作而导致重大更改）。在某些情况下，将对整个模块进行大修（例如std.xml和std.stream）。在这方面，最大的烦恼可能是std.container，它是一个相当新的容器，目前还没有很多东西，并且可能会进行重大的重新设计，因为Andrei Alexandrescu会弄清楚我们将如何处理内存。管理中。因此，容器的支持正在改善，但普遍缺乏。总而言之，许多火卫一都是相当稳定的，但绝对不是一成不变的。 dmd和Phobos绝对都支持，因为如果您将内容发布到bugzilla或在新闻组上进行讨论，人们通常会非常有帮助，并且开发人员会及时尝试修复错误，但是大多数从事此工作的人在闲暇时间这样做，因此有时可能需要一段时间。切换到github确实改善了问题。我知道Digital Mars会为您提供dmc的其他支持（如果您为此付费的话），但我不知道他们是否会为dmd做同样的事情。我希望他们有很大的机会（当然，如果他们现在不这样做，我希望他们将来会这样做）。 至于编译器的质量，dmd使用Digital Mars的dmc作为其后端，而dmc是第一个C ++编译器的最新版本，可以本地编译代码（而不是先将其翻译为C），而Walter Bright D的创造者自创建以来就一直在努力。他是目前最好的编译器作家之一，并创建了许多优化方法，这些优化方法已成为C ++编译器的标准功能（例如Return Value Optimization），但是dmc并没有很多人在为此工作。在某些方面，它已经落后了（例如浮点优化），而D足够新，以至于在优化它方面还有很多工作要做。由于这些错误已修复，因此我确定最终会把更多的精力转向优化语言，并且在大多数情况下（甚至在某些情况下会更好），最终它将与C ++并驾齐驱，但现在它确实取决于您的代码。有时D是同等的；有时候不是。 有些人的确在生产代码中使用了D2（特别是，我知道Adam D. Ruppe在与其合作的公司中将其用于Web开发-他在D新闻组中是经常发帖的人），但我没有认为它们很多，并且通常会避免使用该语言的更新，更高级的功能（通常是最严重的错误所在）。它的稳定程度实际上取决于您对语言的处理方式。 Wiki上有一些尚待完成的工作的好信息，而新闻组上的这个最新主题也有一些好信息。 D肯定已经接近我认为已经可以生产的点，但是在这一点上肯定存在一些风险。它非常适合业余爱好，但是如果您的生计依赖​​它，我不知道这种风险是否值得。它越来越近了。可能值得您花一些时间研究，尝试，试验等等。但是我不只是深入研究您的生产代码并将其全部转换为D。这也许效果很好，但是可能不会。我希望从现在起一年后，我可以说D2已准备好投入生产，但是我不知道比这样早得多。     ,有没有这种迁移的例子   或现有的大型商业软件   产品从头写在D上？ 我不相信会有大量的商业迁移到D，尽管有一些公司使用D1。我还不知道有任何使用D2的公司。   在此进行投资如何安全？   现在的语言？      我们有生产质量的编译器吗   和调试器？ DMD编译器非常强大并且正在不断改进，但是在某些关键领域仍然缺乏。例如，它非常缺乏用于浮点运算的代码生成，并且对64位的支持很不稳定（尽管有所改进）。还有一个我没用过的GDC，但我觉得它比DMD弱。   我们可以假设他们会   支持和发展？ 我认为假设将支持和开发编译器是非常安全的。只需查看D的github页面即可。错误修复的数量正在迅速增加，我看不出有任何放缓的迹象。     ,        好吧，任何语言的一般建议是不要重写现有的代码库。编写新代码或转换需要修复错误的部分可能是一个不错的策略。 快速而又肮脏的重放：如果需要询问，您不应该在生产中使用D。 有些人不认为D是一种改进，而另一些人则认为它会保留在“无关紧要的领域”。纵观其历史，它可以生存。 就我个人而言，如果要提出使用D生产产品的想法，我可能会考虑： 团队规模。在完成D的早期阶段，需要多少教育开发人员。 需要什么图书馆，我们是否有时间和人力来建立或包装图书馆。 我们是否能够处理所用库中的补丁错误。 是否需要DMD不支持的架构 这些问题将成为所有讨论的一部分，尤其是对于像D这样的年轻语言而言，该语言甚至与现有库的兼容性都受到破坏，从而使它仅存在大约4年之久（并且仍然存在）。我不使用其他编译器，所以没有DMD的支持会令人担忧，其他编译器的历史也不算太好，并且知道有可能要使用其他编译器是一件很不错的事情。当然，如果您有可以维护编译器的工作人员... 我认为D可以用于生产中，但应该对其进行严格控制。您希望现在有一个熟悉D的团队来用它来生产产品。