编程与软件工程evanmiller.org
为什么我用 Erlang 编程
Why I program in Erlang (2012)
2012 — 2022，它一次次回到首页
黑点是上首页（≥ 50 分）的那次投稿，空心点是没冲上去的投稿，点越大分数越高。
导读
Evan Miller 2012 年的一篇语言辩护文，讲述他为何选择用 Erlang 编程：轻量进程与并发模型、容错与热更新的运行时、模式匹配带来的简洁，同时也坦率列出生态库少、字符串实现、运行时性能等短板。文章语气平和克制，被读者称为少见的"讲清缺点"的语言倡导文。
为什么经久不衰：它既讲优点也不回避缺点，十几年来一直是理解 Erlang/BEAM 设计取舍的入门文本，也是关于"该用什么语言、为什么"这类讨论的范本。
HN 评论精选
用 Erlang 三个月两人重写并救活一个 PHP 烂摊子，从此认定 BEAM 生产力最高，唯一短板是业务类库生态。
我大约在 2009/2010 年开始用 Erlang 时发现了 Evan Miller，并在他写的 Erlang 框架 Chicago Boss 上做了三个项目。第三个项目是把一个用 PHP 写的、糟糕透顶的约会网站彻底重写——那套东西由 5 个人做了一整年，几乎每天崩一次，慢得无法忍受。我们用两名开发者、三个月重写了全部，还加上了原本根本做不到的功能。一个灵光一现的时刻是：我们意识到可以用 ejabberd 和 XMPP 协议来做消息和聊天之外的事，比如承载新闻流。上线后网站变得极快且稳定。从那以后 BEAM 一直是我的首选平台，虽然现在我用 Elixir。没有别的平台/语言让我觉得自己更高效、对写的代码更有信心：可以内省代码（那个 REPL 远不止是 REPL）、运行时的稳定性惊人、语言本身又简单。LiveView 是游戏规则改变者，我们整个电商栈都建在上面，运行得毫无瑕疵。我唯一的不满是以色列 Elixir/Erlang 生态缺乏面向业务的库和方案：支付网关集成不多、没有 CMS/电商平台、几乎没有开箱即用的开源应用。是的，纯性能上它不如很多语言，但得益于并发，实际用起来快得惊人。
julienmarie查看英文原文
I discovered Evan Miller at the same time I started using Erlang, around 2009/2010. I used Chicago boss, his Erlang framework, in three projects. The third project was a complete rewrite of a really badly created dating website written in PHP that would crash at least once a day and would be unbereablly slow, built by 5 people for a full year. We rewrote everything in 3 months, with two developers, while adding features that were impossible to do otherwise. One lighting bulb moment is when we realize we could use ejabberd and the xmpp protocol for way more than messages and chats, but also to handle our news feed. Once we launched the rewrite, the website became extremely fast and stable. Since then, the BEAM has always been my go-to platform, even if now I use elixir. There is no platform/language that makes me feel more productive and confident about the code I write. The fact I can introspect the code (the repl is way more than a repl), the crazy stability of the runtime, and the simplicity of the language makes it a no brainer. LiveView is a game changer. We built our entire e-commerce stack on it, it runs flawlessly. My only issue with the Elixir/Erlang ecosystem is its lack of business oriented libraries and solutions: - not many payment gateway integrations - no CMS / E-commerce platforms - quite no ready to use open source apps Yes it's not as fast in pure performance as many other programming languages, but in practice, it's fast as hell due to concurrency and performance doesn't degrade with load. And so many exciting things are being developed, from LiveView based native apps to ML and IOTs.
文章关于"Erlang 很少需要重构"的结论来自业余项目经验，在有交付压力的真实团队里并不成立。
作者认为 Erlang 代码很少需要像面向对象代码那样重构——这要看情况。如果你只和那些始终想做正确事情的高度自律的人共事，我同意。但如果同事有截止日期、需要马上把东西做出来，你就会看到多余参数的函数、过大的 record，这些东西很难维护。我认为作者是位出色的工程师，热爱编程且非常擅长，但他没有以专业身份用过 Erlang——"我花了大量业余时间用 Erlang 编程"，这就说明问题了。
distortedsignal查看英文原文
> ... [I]n my experience it is rarely necessary to refactor Erlang code in the same way the object-oriented code needs refactoring from time to time. That... depends. If you work with only highly disciplined people who want to do the right thing always, then yeah, I agree. But if you work with people who have deadlines or need to get stuff done _now_, you could see functions that take unnecessary arguments, or excessively large records, and those sorts of things are hard to work with. I think this person is an excellent engineer who loves to code and is really good at it, but hasn't worked with Erlang in a professional capacity. Which... > I have spent a large chunk of my free time programming in Erlang ding ding ding
补充实际使用中的痛点：SASL 二进制日志、Rebar 难用、record 语法糟糕，但模式匹配等仍很出色。
过去几年我在多个大项目里用过 Erlang，总体上同意作者对优缺点的大部分判断（别人问我时我总说：Erlang 非常适合那种有很多活动部件、但不要求代码好看或易读的场景）。我想补充几个缺点：日志很怪异，官方推荐 SASL，它把日志写成只有另一个 Erlang 库才能正确读取的二进制格式；它有自动轮转等好特性，但我更愿意输出纯文本再用 logrotate。有天我要写个正经的 Erlang 日志库。Rebar 也很怪，它是 Erlang 的部署工具，类似 leiningen 但远不直观；我试着习惯它，结果只让测试更难、配置更麻烦，最后我干脆抄了 mochiweb 的 makefile 了事。Record 的语法是我用过最烦人的语言构造，嵌套 record 更是灾难。当然也不是全无优点：多态匿名函数、模式匹配非常棒……
mediocregopher查看英文原文
I have used erlang in a number of large projects over the last couple years and for the most part I'm in agreement with the author about both the benefits and drawbacks of erlang (when people ask me about erlang I always say "erlang is great for anything that requires a lot of moving pieces and doesn't require the code to actually look nice or be readable"). I have a couple of other drawbacks I think should probably get mentioned: Logging is..... strange. The recommendation is to use SASL, which writes your logs in a binary format that only another erlang library can properly read. SASL has some nice features, like auto-rotation and such, but I'd much rather have my logs get spit out in plaintext and just logrotate like I do with everything else. One of these days I'm going to write a proper erlang logger. Rebar is strange. It's erlang's deployment tool thing, kind of like leinengen but much less intuitive. I tried getting used to it but found it just made testing more difficult and made setup a chore. I opted instead to just steal the makefiles from the mochiweb project and call it a day. Records have easily the most annoying syntax of any language construct I've ever used. And god forbid you want nested records, have fun with your full solid line of selection syntax. Bleh. Which isn't to say it's all bad, here's some other awesome things about erlang that I don't see pointed out often: Polymorphic anonymous functions The pattern matching is amazing. When I go back to other languages that claim to support pattern matching it feels like I've lost both your feet and replaced them with suction cups. There's no pattern matching like erlang pattern matching. Hot-swapping of code. Somewhat unintuitive, and has weird behavior in certain cases, but still definitely better then restarting the server that thousands of clients have long-running connections on Records. Their syntax is horrible, but their usefulness is infinite. They're basically just syntactic sugar on top of tuples that make them easier to manage and extend. There's more for both sides, but I'll leave it at that. It's a great language, I highly recommend everyone take a stab at it. Even if you hate the syntax it's good exposure to thinking about how to code concurrently.
深度批评：OTP 样板会侵蚀业务逻辑、Dialyzer 错误信息难懂、发布管理充满黑魔法。
我个人已经明显不再偏爱 Erlang 了。有很多场景我会毫不犹豫地用它——软实时是关键的——但它实在难伺候。Erlang 把"生成进程"当作核心抽象，导致大量 OTP 样板与业务逻辑混杂：你最终在应用层搞出面向服务的架构，人们很少写纯库，而是写可启动的应用再异步通信。而且启动进程并不像入门教程讲得那么简单，你会被大量理由推动去套 OTP 样板，从而拆成多个文件和多个应用。Dialyzer/Typer 一团糟：我相信它们是成功使用 Erlang 的关键工具，却与语言只有松散的集成，错误信息古怪难懂（不过它们在发现你传元组时犯的种种错误上确实很强）。rel 的创建与管理还有大量黑魔法；靠 Rebar 和逆向 Riak 我才弄明白大半。正如作者所说，这是个非常聪明的系统，但要让所有部件协同工作非常困难。今天我会用 Erlang 构建简单、刀枪不入的服务端架构，处理大量独立……
tel查看英文原文
I personally have fallen quite significantly out of favor with Erlang. There are many reasons for which I would absolutely use it---soft realtime being key---but it is an absolute bear to work with. Erlang's reliance on spawning processes as a central abstraction conceit leads to conflating a lot of best practice OTP ceremony with your domain logic. You end up with a Service Oriented Architecture at the application level---people rarely write pure libraries, but instead bootable applications that you communicate to handle needs asynchronously. Additionally, launching processes is not as simple an interaction as beginner Erlang tutorials have you believe. Instead, there's a lot of reason to wrap in the OTP boilerplate leading you to split out things into multiple files and applications. Dialyzer/Typer is a mess. They're crucial tools for using Erlang successfully, I believe, but they're also only mildly tied into the language and have weird, difficult to understand error messages. That said, they're really good at discovering the myriad errors you'll make passing tuples around. There's also an enormous amount of black magic surrounding rel creation and management. Using Rebar and reverse engineering Riak I was able to figure (most of) it out. It is, as the author states, a very smart system, but it's also very difficult to get all the pieces firing together. I would today use Erlang for creating simple, bombproof server architecture. It's a joy for doing lots of independent, network things in parallel. Mochi Media seems to be an obvious example, and I remember reading that [forgotten game name that isn't ROTMG, thanks!] is an MMO game which models every interacting player as an independent Erlang process. Those examples are both beautiful, as an infrastructure language I think it's unparalleled and begets great technology like Riak---I'm seriously itching to use Riak Core sometime. I just wouldn't want to be the guy who wrote the player logic to run one of those processes. (Edit: to qualify, a lot of these flaws are more my own than Erlang's, but despite spending 3-4 months with it I put it in the box with C as a Right Knife for the Job kind of language)
历次讨论
同类还值得读
开源应用架构
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编辑精选