榆树路线图

永久链接如果您喜欢现在所看到的，那几乎就是Elm一段时间后的样子。

我目前正在对编译器技术和目标进行一些探索性工作，但要断言其中哪些部分可能会解决还为时过早。我知道许多读者会采用“探索X＆＃34;作为X一定会发生的承诺，所以我要谨慎地将期望值设置得较低，因为工作中仍然存在很多不确定性。因此，尽管目前没有真正的新闻要分享，但我可以对Elm的未来稳定性给出一些期望：

如果这项探索性工作进展顺利，即使取得了最疯狂的成功，我也不会期望语言或核心软件包会发生很大变化。可能会拖延两三年，它可能会揭示出一些可以解决的好方法，但是我现在真的没有预见到明显的变化。

如果这项探索性的工作没有完成，那么我会有一些比较保守的项目，这些好主意我想在某些时候谈谈。像：

添加一个受约束的类型变量eq来消除函数（==）的运行时错误

尝试使用最新的解析基础结构获取elm格式，因此它不再是开发过程中的性能瓶颈

再进行一次性能测试，因为我有最后一个想法可以提高速度

这些都是很好的生活质量，但是0.19.0和0.19.1花费了这么长时间，我渐渐厌倦了增量式改进，这是个好主意，但是花费很长时间并且不是。对于非Elm用户来说非常令人兴奋。＆＃34;不必太讲究细节，在返回这些特定想法之前，我确实需要进行修改。

如果某人在编译器或核心库中遇到安全问题，请在Elm Slack上与我联系。除安全性问题外，我认为，一旦从编译器探索中获得的教训变得更加明确，就可以进行更多自由更改的能力将会增强。希望这里的讨论可以澄清这些能力问题的思路。

退后一步，我发现以这种宽松的方式工作产生了很高的质量基准，我认为这是Elm的重要组成部分。例如，Elm中所有错误消息的工作都始于实现--report = json标志的项目。这项工作恰好揭示了一些改进错误消息的好主意，如果我一直使用严格的路线图，我可能会跳过这些主意，以在公开规定的任意截止日期前完成。我们的路线图更加清晰，但错误消息与其他类型推断的语言没有什么不同。

因此，我认为在某些方面，更大的规划灵活性是Elm的竞争优势，但这显然是一种权衡取舍，并不适合所有人。如果某人需要更多的确定性，我通常建议您研究其他语言，以了解他们是否有平衡的方式来更好地满足他们的需求。例如，大公司制作的语言通常风险较小。在诸如此类的事情上，但我认为您也会在设计决策中看到这种过程的成果。权衡取舍！

无论如何，就像我在开始时说的那样，如果您喜欢现在所看到的，那将是一段时间。即使以我目前的探索在最佳情况下！

我希望这是有用的信息，也希望您对Elm有良好的经验，即使您最终找到了对您更有效的另一种语言也是如此！