编程与软件工程lukeplant.me.uk
我为什么离开 Elm
Why I’m Leaving Elm
2020 — 2025，它一次次回到首页
黑点是上首页（≥ 50 分）的那次投稿，空心点是没冲上去的投稿，点越大分数越高。
导读
作者 Luke Plant 是 Django 核心开发者，长期使用 Elm 后决定放弃它。文章批评 Elm 语言演进缓慢、社区沟通封闭、编译器与包生态高度中心化等问题，认为这些使其不适合长期维护的生产项目。
为什么经久不衰：Elm 的架构思想依然值得学习，但文章揭示的治理与生态风险在多年后仍被反复验证，对选型前端技术有持久参考价值。
HN 评论精选
Elm 设计优秀但更新停滞、领导者对批评态度傲慢，注定难以走向主流
我认为 Elm 走了一些重大弯路。尽管它在最初设计上做对了很多事（至今仍是设计最好的前端体验之一），但它始终没能走出早期采用者圈子，基本停留在一种有趣的业余语言。我曾在 r/elm 批评它缺乏沟通、更新频率太低，担心这会扼杀 Elm 的势头、让语言显得停滞。发帖后立刻发现这也是许多人的共同担忧。而 Evan 面对这些批评做了什么？他在欧洲演讲的开场部分拿这些批评来嘲讽。我倒不觉得被冒犯，但这说明了 Evan 的心态。一个好的领导者会去追问为什么大家有这种感受，并建立更频繁的更新机制。显然，除了在设计 Elm 上才华出众，他不是能把 Elm 推向更广泛采用的人。如果采用度不够，即使它做对了很多事，也不值得推荐用于生产项目。在我看来，遗憾的是 Elm 终将只是一个业余项目。
salimmadjd查看英文原文
I believe Elm took some major missteps. Despite doing so many things right with the initial designs (and still one of the best designed front-end experiences) it never grew much beyond the early adopters and it basically remained a fun hobby language. I criticized the basic lack of communication and the infrequent updates in r/elm (I believed these infrequent updates were going to kill the momentum of Elm). I was concerned that it made the language seem stagnant. Immediately, after posting it was clear it was a major concern by others as well. So what did Evan do with that criticism? He spent the opening part of his European talk mocking it [0]. I didn’t take it personally, but it illustrated the kind of mindset Evan has. A good leader would have asked questions about why many feel that way and would have instituted a process for more frequent updates. It became clear to me, outside of being brilliant at designing Elm he is not the person to take it to the next level of adoption. If it’s not moderately adopted it won’t make sense recommending it for any production project, even if it does many things right. To me it feels like (sadly) Elm will just be a hobby project despite what it could have been. [0] https://youtu.be/uGlzRt-FYto
Elm 编译器和包生态高度中心化，长期维护风险太大
这些批评非常到位，正是我在 2018 年底、2019 年初观察到的情况。这是一门很棒的语言，但存在严重的“供应商锁定”问题：某些编译器特性只有维护者能用，也没有使用替代包站点的途径。我不敢想象如果 Elm 开发者把 package.elm-lang.org 下线会发生什么——大量项目将无法构建。即使你保存了核心包的源码压缩包，也没法自己接入构建流程，Elm 编译器必须从官方包站点加载。因此我强烈建议不要用 Elm 构建任何需要长期维护的软件，风险太大。
EdSchouten查看英文原文
This criticism is spot on; it is exactly what I observed in late 2018, early 2019 as well. It's an awesome language, but there is basically a big case of 'vendor lock-in'. Certain compiler features are only available to the maintainers, nor is there any way to use alternative package sites. I don't want to know what would ever happen if the Elm developers decide to take https://package.elm-lang.org offline. That will leave so many projects out there in an unbuildable state. Even if you saved source tarballs of the core packages, there is no way to tie it into the build yourself. The Elm compiler must load it through the official package site. I would thus personally strongly advise against using something like Elm to build any piece of software that needs to be maintained over time. It's too much of a risk.
用过的人认同结论：Elm 的破坏性变更使其不适合长期生产维护
读了很多回复后我注意到一个模式，评论分两类：1）用过这门语言、认同文章结论（即使不认同每个细节）；2）没用过、但认为开源项目维护者有权按自己的意愿维护。这两种观点我其实都同意。我曾用 Elm 做过业余项目并考虑用于生产，但现在不会再用。我喜欢它最初的承诺，Evan 关于 Elm 架构的想法值得任何人去阅读学习。但正如许多人指出的，如果要多年维护一个项目，语言中的破坏性变更会让人痛苦不堪。我不喜欢 Java，但这些年我已习惯每个大版本只需少量工作就能保证生产代码继续运行，并按自己的节奏引入新特性。而 Elm 每次发布都逼我花几个小时让旧代码重新跑起来。
bwanab查看英文原文
After reading a large number of the responses here, I feel like I've noticed a pattern - two types of comments: 1) I've used the language and agree with the conclusions of the post even if I don't necessarily agree with every point. 2) I haven't used the language, but I believe open source projects must be maintained by their maintainers as they see fit. I actually agree with both of these positions, but, having used Elm in the past for a hobby project with an eye towards using it in production, I probably won't ever use it. I loved the original promise. Evan's ideas about the Elm Architecture are worth reading and learning for anyone. But, as many others have pointed out, if one has to maintain a project over the years, the breaking changes in the language would have caused great bouts of teeth gnashing. I don't love Java, but over the years I've come to expect that with each new major version of the language, that a small amount of work needs to be done to guarantee my production code will keep working and I can integrate new features as I have time. With Elm, every release forced me to spent hours figuring out how to make my old code work again.
开源不等于参与决策，不满的用户应该 fork 而非抱怨
我不完全同意这篇文章。开源的真正含义就是在合适的许可证下你拥有全部代码、可以从头重建，而不包括参与设计决策的权利。互动风格和个性也不属于开源的定义范畴。Elm 的不满用户应该 fork 代码——包括整个生态对 Elm 官方域名的依赖——做出完全自包含的东西。依赖“回连服务器”的软件本身就是风险，无论托管在哪里、维护者态度好坏。如果 Elm 核心开发者因此把人踢出项目，那也只能咬牙接受。
kazinator查看英文原文
I don't agree with everything here. Open source really does mean that you just have all the code to rebuild the thing from scratch under the right sort of license. Open source doesn't mean anything else, like having access to design decisions. Interaction style and personalities are also not part of the definition of open source; open source doesn't mean nobody is brusque or abrasive. Some communities have additional codes of conduct and social contracts and what not for that sort of thing. Here is a balanced viewpoint from the GNU Awk and Bash maintainers: http://www.skeeve.com/fork-my-code.html Elm users who are not happy should fork the code --- everything, including the ecosystem's dependencies on an ELM internet domain --- and maybe produce something that is completely self-contained. Software that relies on "phoning home" is a risk regardless of where that is hosted and whether the people are nasty or nice. If the Elm core developers don't like it and kick people out of their project for forking, you just have to bite the bullet on that. (From the description of what that project is like, why would you care about being kicked out. Kicked out or not, your 20 line bugfix still isn't getting looked at for another two years.)
历次讨论
同类还值得读
开源应用架构
The Architecture of Open Source Applications
《开源软件架构》（AOSA）是一本在线免费书，邀请知名开源项目的作者亲自剖析其内部设计，涵盖 SQLAlchemy、LLVM、Audacity、Apache、Bash 等系统。
编程与软件工程上首页 9 次 · 2011–2024aosabook.org编辑精选编程语言简史：简短、不完整且多半错误
A Brief, Incomplete, and Mostly Wrong History of Programming Languages
一篇以戏谑、故意不准确的方式回顾编程语言史的博客文章，用夸张轶事和讽刺定义串起 Lisp、C、C++、Java、JavaScript、PHP 等语言。
编程与软件工程上首页 8 次 · 2009–2021james-iry.blogspot.comSQLite 是如何测试的
How SQLite is tested
SQLite 官方文档页，系统介绍 SQLite 的测试体系：多种测试方法（TCL 测试、模糊测试、回归测试、静态分析等）和海量测试用例，展示了这个小型开源项目如何靠极致测试获得…
编程与软件工程上首页 8 次 · 2009–2025sqlite.org编辑精选高级编程语言（2009）
Advanced programming languages (2009)
Matt Might 的经典文章，按用途推荐“高级编程语言”：如果追求就业就选主流语言，如果追求表达力、学术研究或创业，则推荐 Haskell、OCaml、Scala 等函数式语…
编程与软件工程上首页 8 次 · 2009–2022matt.might.net我的 Forth 与栈机器经历
Yosefk - My history with Forth & stack machines
作者以亲身经历回顾了使用 Forth 语言和栈式机器的历程：既赞叹其简洁优雅、代码量小、可自举的优点，也坦率指出栈操作在实际编程中的痛苦，以及 Forth 社区文化中的问题。
编程与软件工程上首页 8 次 · 2010–2024yosefk.com编辑精选