对《Ruby 不是一门严肃的编程语言》的回应
何必如此严肃？
Sheon Han 提出的问题—— “Ruby算是一门严肃的编程语言吗？” ——充分暴露了某些人对编程应有状态的认知。对某些人而言，如果工具用起来很舒服……那必然意味着它不够“严肃”。
Ruby从未认同这种定义。若真如此，那我怕是错过了备忘录。
若你来得稍晚，便错过了这门语言悄然叛逆的篇章。当时社群尚小，氛围充满玩味。Ruby轻拍你的肩膀，询问：若编程不必令人望而生畏会怎样？若允许清晰与快乐存在，又会开启怎样的可能？
早期的质疑者可想而知。Java架构师。企业传统主义者。所有将身份认同建立在编程必须严肃的人。他们说 Ruby 不严肃。而社区大多耸耸肩……因为我们正忙着创造事物。
Ruby 让编程变得亲近。不是简单化……而是亲近。这区别至关重要。它帮助初学者看清前路。它让小型团队在焦虑蔓延前积聚势能。它让资深开发者重拾工作中的轻盈感。
这就是编程训练营拥抱它的原因。微型初创企业借它获得发展动能。Ruby从不追求跑分胜利……它只专注于推动你前进。当创造新事物时，这远比类型系统的理论纯粹性重要得多。
当然……批评者总爱拿Twitter举例。但细看会发现：Ruby助他们走得比多数企业更远。他们只是成长得超出了框架限制。这并非失败……而是成功。
在我数十年的软件咨询生涯中，从未见过团队因选择Ruby而失败。我见过他们因选择复杂性而失败，因选择优柔寡断而失败，因选择“严肃性”而非前进动力而失败。Ruby只需退居幕后，让人们专注于真正的工作。
当人们仍在争论它的“可信度”时，事实已摆在眼前：Shopify通过Ruby处理数十亿交易。Doximity用Ruby支撑着美国多数医生的工作。GitHub多年来用Ruby维系着全球源代码体系。这不是情感宣泄，而是铁证如山。
外界常忽略的是文化内核。Ruby吸引着那些在乎代码书写与阅读体验的人。这并非怀旧情结……而是因为我们大半职业生涯都在他人决策的框架里挣扎。编程的愉悦感并非奢侈品，而是打造可持续软件的基石。
虽未与Sheon谋面，但我想我们在音乐品味上的分歧，恐怕不亚于对_why所著《Ruby的尖锐指南》是否具有启发性的看法。这无可厚非，恰恰印证了核心观点。
说到这里……有件事我真心赞同希昂的观点：Ruby似乎并非为他们而生。这并非语言的缺陷，纯粹是品味差异。有人钟情爵士，有人偏爱金属，有人追求仪式感带来的慰藉。Ruby从未试图改变任何人，它只是与共鸣者自然相吸。
既然谈及品味，容我补充个人见解。身为无神论者，在此提及自身信仰缺失颇为贴切——这恰如文章提及Matz宗教背景的荒谬性：既无助于理解上下文，亦未深化论点，只是……突兀存在。一个徒然追寻意义却与核心毫无关联的细节。
谢恩提到要以“不带怀旧情怀的宽容”看待Ruby。这无可厚非。但那份情感并非怀旧，而是感恩——感恩这门以人为本的语言，感恩这个相信编程能成为表达方式的社群，感恩这个让工作更轻松却不失严谨的工具。
但讨论始终忽略了关键点：这不仅关乎过去。
编程的未来对所有人而言都模糊不清。任何声称掌握未来发展终极方案的人都在胡扯。未来不会被单一范式、单一语言或单一理念所垄断。它将是各种思想的融合——新旧交织、借用与重构的混乱拼贴。
而在那个未来……Ruby的价值观并非陈腐遗物，而是坚实的锚点。当AI编写更多代码时，可读性将愈发重要；当产品生命周期延长时，可维护性将愈发重要；当倦怠成为常态时，编程的乐趣将愈发重要。
若你需要提醒——严肃认真的态度并非人们期待的可靠信号……
认真的候选人未必当选，
认真的音乐人未必签约，
认真的艺术家未必畅销。
严肃的男人未必能收获真挚的感情。
严肃的初创公司未必能找到产品市场契合点。
严肃的工程师未必能编写经得起时间考验的代码。
严肃的重构未必能解决根本问题。
文化不会可靠地奖赏严肃。商业亦然。
它奖赏的是共鸣。是清晰。是人性。是能建立联结的作品。
Ruby始终倾向于工艺的这一面。倾向于编程中记得人类参与的部分。倾向于主张代码或许该服务团队……而非反其道而行。
坦白说……我认为不严肃的人未来也将扮演重要角色。那些充满好奇的人。那些玩心未泯的人。那些选择敞开大门而非把守大门的人。他们将守护行业的真诚。他们将守护人性本真。
那么 Ruby 是否“严肃”？我依然认为这是错误的提问。
更好的问题是… Ruby 能否为软件发展的下一章贡献有意义的力量？
答案是肯定的。
若这被视为“不严肃”…或许正因如此，它才更值得被纳入讨论。
本文文字及图片出自 Why So Serious?
我不认同推特辩论的理由在于：即便Ruby是根本原因，选择Ruby仍推动了业务发展，并促成了他们首次成功的灾难。
我认为该论点更深层的缺陷在于——推特遭遇了其原生且全新的问题：海量扩散效应(名人推文→数百万粉丝)。这种现象绝非任何编程语言在响应网络请求时会遇到的典型问题。
最后——这里存在严重的幸存者偏差。那些采用Java或其他语言实现“从第一天起就具备可扩展性”却最终失败的初创公司，我们永远无从知晓。
看看https://www.wired.com/author/sheon-han/，这位作者的策略简直像在挑衅猛兽。文笔虽精湛，但至少在这篇Ruby文章里，明显是在刻意制造争议。看到《连线》刊登这种质量的内容，我有点难过。
总之，我退出讨论了。回归沉默的大多数——那些正愉快地用Ruby交付实用软件的人群！
> 我反对推特论点的原因在于：即便Ruby是根本原因，选择Ruby仍推动了业务启动，并促成了首次成功灾难。
这种说法成立的前提是当时没有更适合启动同类业务的语言，否则就能避免这场灾难。
当时真有这样的语言吗？我印象中那会儿要么是易于上手的语言/框架组合，要么是能解决所有技术难题的方案，但不可能两者兼备。
感谢补充背景信息
岁月流转，Ruby早已今非昔比。
原文作者从未真正阐述过讨厌 Ruby 开发体验的具体原因。他们列举的某些历史缺陷，我们只能推测是源于其当时所参与的代码库问题。我认为首篇文章最精辟的观点在于： 2025年切勿选择 Ruby 作为开发语言，任何你认为它能带来的优势都有更优选项替代 。
我认为这本应是文章的核心批判点。
而在本文中，作者却选择了诉诸情感，某种讽刺意义上反而印证了前文关于Ruby依赖情感驱动的观点。
许多推崇Elixir的人同样认为Ruby不可取，尽管后者曾对前者产生深远影响。反对Elixir的论点往往围绕其市场影响力不足展开，而非质疑其技术严肃性。
> 许多钟爱Elixir的人也认为Ruby不可取，尽管后者曾是重要影响。反对Elixir的论点往往围绕其市场影响力不足，而非严肃性问题。
Elixir很有意思。我使用Elixir已有多年，职业生涯初期也接触过Ruby。许多人因其类似Ruby的语法(但基于函数式编程)而转向Elixir——他们喜欢Ruby却厌倦了面向对象编程和可变状态，渴望尝试新事物。而BEAM运行时/虚拟机往往成为他们留下的关键因素。
别误会，Elixir语言本身很出色，但BEAM及其运行特性与Ruby等为单线程编程世界设计的语言相比，简直是天壤之别。
当你使用BEAM(现已支持多种语言)时，会产生一种奇妙的体验——你正在使用专为运行而设计的系统。任何事物都能被监控。你可以追踪任何事物。你可以实时查看任何状态。你可以重启任何组件。这不仅是门语言，更是一个构建系统的整体性_系统_。
> 当你使用BEAM(任何语言——如今已有数种)时，会产生一种奇妙的体验：你正在操作的系统是_为被操作而设计_的。你可以监控任何事物。你可以追踪任何事物。你可以实时查看任何状态。你可以重启任何事物。它是一个构建系统的整体_系统_，而不仅仅是一种语言。
说得好。问问Elixir爱好者或批评者：当前阻碍广泛采用的瓶颈是什么？多年前，阻碍无非是第三方库和框架的匮乏。如今这方面理应改善，还是仍有短板清单？
虽有些跑题，但原文未提及Python——对Ruby开发者而言，这仍是(至今未被正视的)核心问题。无论好坏，Python在目标领域和受众层面都已占据优势。我知道这想法有些天真，但我曾真心期待Elixir能让 所有 Ruby用户为之振奋，促使他们将不可或缺的核心功能移植到Elixir平台。为何他们没有/不愿这么做？是否 完全 因为面向对象编程？或者说，既然Rails是杀手级应用，为Phoenix开发Rails“皮肤”难道不能有效解决痛点？
我认为这个基于Elixir的项目多少受到Rails的影响：
https://hexdocs.pm/phoenix/overview.html
尚未尝试过，但在更新关于类似/受Rails影响及/或具有特定立场的框架知识时偶然发现它。
另题外话：关于Elixir，发现这个Rust相关链接：
https://loco.rs/
若已掌握Rails的部署技巧，对初创公司而言，放弃这个久经考验的框架转投新平台恐怕难以说服。
> 当前阻碍广泛采用的瓶颈是什么？多年前无非是第三方库和框架的问题。如今情况应该改善了，还是存在关键缺失项？
情况很复杂。
库/框架生态确实比过去完善许多，明显缺失的功能已不多见。部分组件维护力度可能不及预期，但核心功能基本齐备。
Elixir和BEAM有种特殊困境：除非亲身体验，否则难以领会其优势。这点与其他技术截然不同。若你90年代从Java转战Ruby，无需实际使用就能通过代码示例看出实现相同功能所需代码量的大幅减少。
若你当年用过Perl，即使不接触Python，也能看出Python对初学者的友好性远胜于Perl的怪癖。
BEAM引擎难以推广，因为其优势无法在技术聚会屏幕上直观呈现。“假设你拥有从底层就为并发设计的虚拟机”这类概念难以打动人。人们会反驳：‘我的语言已有线程和Promise机制’。而当你提出“如果你的语言能提供内置工具包，以严谨明确的方式划分并重启不同子系统呢？” 人们会说：“我用systemd就能重启服务。”
经过数年实践，BEAM已具备某种“无名品质”[0]。它呈现出其他环境难以企及的“完整性”，这种特质难以用视觉呈现。这种特质无法简单地通过幻灯片或宣传页面展现，更何况多数人不会冒险选择一个规模较小、被视为异类且怪异的语言社区——尤其当他们听到的最积极评价仅是“这是种更擅长并发处理的功能型语言”时。对多数人而言，这根本不足以让他们放弃Python、JavaScript、Java(或Ruby)。
顺带一提，我并非在责怪大家——当面临难以预见的收益与显而易见的风险(小众社区、职业前景不明、库覆盖存疑等)时，这种风险评估方式既理性又正常。我认为作为社区，我们(Elixir)在降低Elixir风险感方面做得不够好。
> 虽有些跑题，但原文未提及Python，而对Ruby开发者而言这仍是(至今)无法回避的问题。无论好坏，当两者瞄准相同细分领域和受众时，Python确实赢得了这场竞争。
依我之见，Python赢得了战争。Ruby凭借Rails赢得了服务器端Web应用之战，至今仍势头强劲，但Python在其他领域以压倒性优势全面取胜。Python甚至还有Django框架。Python可谓无处不在。虽无确切数据佐证，但我敢说90%以上的Ruby使用场景都依赖Rails，而Python并非如此。
需要明确的是，以上讨论仅限于 普及度 层面。Ruby或许永远无法达到Python的普及程度，但其 影响力 极其深远。众多技术都可追溯到Ruby的血脉，无论是Elixir语言本身，还是Rust的工具链(Cargo)等。
> 我知道这想法有点天真，但真心希望Elixir能吸引Ruby用户群的热情，促使他们将无法割舍的核心功能移植到Elixir。为何他们没有/不愿这么做？
Rails在技术和文化层面都具有强大惯性，在自身领域依然表现优异。要让Rails用户放弃Rails，除非出现比Java时代更优越的替代方案。况且许多人就是钟爱Ruby！Elixir并非Ruby——它更显式、无变性、无对象等特性。两者相似性仅止于语法层面，而多数Ruby用户对现有状态很满意，这完全合理。
抱歉回答太长。
[0] – https://onluminousgrounds.wordpress.com/2010/04/24/the-quali…
令人惊讶的是，深受Ruby启发的编译语言Crystal[1][2]竟未被提及。尽管它面临的问题比Elixir更突出——许多人认为Elixir尚未获得足够关注[3][4](根据各类排名)。至少Elixir在TIOBE排行榜上稳居前50名。
[1]: https://crystal-lang.org/
[2]: https://en.wikipedia.org/wiki/Crystal_(programming_language)
[3]: https://archive.md/sJRyf (TIOBE 2025年11月)
[4]: https://www.slant.co/topics/15430/~compiled-programming-lang… (Slant Rankings)
Ruby在macOS系统中预装。因此若要在Mac上编写脚本而无需安装程序或非原生软件，可选方案就是Ruby、Perl、Bash或AppKeskript。
我记得他们提到过它很快会被移除
见仁见智，但两篇文章都毫无价值。第一篇对 Ruby 语言可能存在的问题只字未提，却在 StackOverflow 流行度和 Twitter 问题上啰嗦不休；第二篇对第一篇文章的缺陷毫无批判，只是在怀旧旧时光和美学差异上大做文章。
更令人沮丧的是，这些内容并非由大型语言模型为博眼球而生成的垃圾，而是真实人类撰写并获得真实人类关注的产物。
判断最爱编程语言的唯一标准如下：
不是“我喜欢用这门语言写代码”，而是“若接手现成的生产系统，我更希望它用这门语言编写”。
多数人对这两个问题的答案截然不同。
我认为这是两个独立的问题。编写代码与运营技术公司是截然不同的事情。我个人热爱Ocaml，认为它是卓越却被严重低估的语言。但(可能)不会选择用它构建生产级系统——因为其库与框架生态较弱，且难以招聘既懂该语言又愿意学习的新人。
> 我认为这两者是不同的考量。
确实如此。后者——即接手并维护他人编写的代码——才是日常工作中更常见的场景。比起从零创建系统，你更有可能参与现有系统的构建与优化。
这很大程度上取决于语言所处的特定发展阶段以及团队的具体编码实践。
例如，我乐于维护启用了类型注解和类型检查的Python代码库。若未启用这些功能，则代码库必须具备完善的文档字符串文化，且团队需愿意逐步添加类型检查。具体使用Python哪个版本并不重要。
> 例如，我乐于维护启用类型注释和类型检查的Python代码库。
“启用类型注释和类型检查的Python代码库”并非行业常态。不妨看看著名`pytorch`框架的随机文件：
https://github.com/pytorch/pytorch/blob/main/torch/_functorc…
即便这个文件也并非全程使用类型注释。
不过对于用Python编写的新系统而言，类型注释正逐渐成为常态。因此我认为仅凭语言本身不足以作为判断依据。这种启发式方法会对历史悠久的语言产生偏见——因为它们的大量代码是在编程实践尚未成熟时编写的。
没错，但…这取决于你的任务是无限期维持生产系统的现状，还是要在时间压力下持续开发并集成新技术。若是前者，COBOL可能是正确答案；若是后者，事情就变得有趣了。
为什么是COBOL？
COBOL被用于运行时间最长的持续运行系统，尤其在金融行业，其中许多系统自1960年代起便投入生产——主要运行于大型机，但如今在云环境中的应用也日益增多。没有任何技术能接近其可靠性水平，次接近的或许是Fortran、Ada和Erlang。
我发现这篇文章列出了若干数据[0]，其中最引人注目的是“95%的ATM刷卡交易依赖COBOL代码”。若您只需维护现行系统，仅需偶尔更新业务逻辑且无需升级架构，COBOL无疑是最佳选择。
[0] https://www.pragmaticcoders.com/resources/legacy-code-stats
我认为这种相关性相当明确，但因果关系值得商榷。存在若干重大混杂变量：
1. COBOL系统通常构建于更浅层的软件堆栈，容错空间有限
2. 银行系统历经数十年开发，在可靠性方面投入了巨大精力
我以前的老板在1975年——那时候我还没出生——就为核心财务流程编写了COBOL代码。他2019年退休时，那段代码经过少量修改后仍在运行，估计还能再撑十年。
公平地说，这确实是相当基础的东西。但……公司花了五六年时间试图迁移到Oracle系统。
只要是我编写的系统，用什么语言都行。否则就交给别人去折腾吧！
/s 但确实如此
没错，就是这样。我喜欢用Forth编程，但绝对他妈不想让它成为我的日常工作。
我热爱Ruby。这绝非感性之谈；我享受用它编写和开发的过程，远胜于JavaScript。
这类针对Ruby的攻击确实很奇怪。不喜欢特定编程语言无可厚非，但质疑其写作动机才值得深思。
关于Ruby成功的论述总让我感到困惑。Github、Twitter、Coinbase和Shopify都是成功典范。扩展性挑战本身就是成功的证明。
这确实是款优秀的工具。若你读到此处，不妨考虑评估Ruby是否适合你的下个项目。:)
这篇回应本身就很奇怪。原文未定义术语，正如Robby指出的，这使得批判变得困难。若仅当语言能无限扩展以适应所有场景才算“严肃”，那么Ruby确实不够严肃——大多数语言都不够。
话虽如此——这篇回应与批判的核心观点其实高度一致。批判可概括为“Ruby无法永续运行”(因此不应使用)，而本文同样在说“Ruby无法永续运行”(这无可厚非)。我几乎能理解这篇文章在表达：’Ruby不够严肃，但这对使用者而言并非问题。’
值得玩味的是，原文竟因 Ruby 在 Stack Overflow 开发者调查中“仅排第18位”(注：2024年实际为第14位)而抨击它，却大肆吹捧排名低9位的 Scala[1]。
[1] https://survey.stackoverflow.co/2024/technology#most-popular…
> “Ruby 无法永续发展”
回应中哪里提到了这个？
我只知道十年前写的Ruby代码至今仍在服役，比如整个编译器https://github.com/WebKit/WebKit/tree/main/Source/JavaScript…
我注意到以下几点：
> 批评者总爱拿Twitter举例。但仔细看看：Ruby带他们走得比多数公司更远。他们只是超出了自身能力范围——这并非失败，而是成功。
> 我从未见过团队因选择 Ruby 而失败。我见过他们因选择复杂性而失败。因选择优柔寡断而失败。
> GitHub 多年来用 Ruby 支撑着全球源代码体系。
许多公司曾成功使用Ruby，但当它不再契合需求时便另寻他法。这绝非对Ruby的批判！但确实印证了Ruby存在成长瓶颈——若你寻求一种永远不会被业务场景淘汰的语言，Ruby或许并非最佳选择。
GitHub就是个例子——它用Ruby比用React效果好得多…后来情况反而恶化了。
或许用新版Ruby会更好。
> 我十年前写的 Ruby 代码至今仍在服役，比如这个完整编译器 https://github.com/WebKit/WebKit/tree/main/Source/JavaScript…
真棒。offlineasm具体如何使用？(无需深入LLInt的背景细节——我的意思是编译器如何被调用？)它只是作为参考编译器，对应JSC内部的其他机制吗？
这就是JavaScriptCore解释器的编译方式。该解释器采用我发明的宏汇编方言编写，而offlineasm正是其专用编译器。
(我用“编译”而非“汇编”，因为它比普通汇编语言更高阶。实际存在完整的转换管道，且具备图灵完备的宏语言特性)
谢谢，很有帮助。(我误以为这个编译器是处理JSC字节码的，无论是作为输入还是输出。)
有趣的是他先调侃Java，却又因Scala的健壮性而喜爱它(而Scala的许多特性都源自Java)。
我常看到人们对Ruby赞不绝口，称其为“为人类打造的语言”。问题在于，所有语言本就为人类而生(至少理应如此)，但我们对“为人类打造”的定义往往各不相同。Ruby确实拥有简洁优美的语法，但我个人却因其动态类型(编写时难以确定类型)和大量宏及其他魔法特性(在不知情时执行未知操作，并神秘地向作用域引入符号)而感到难以驾驭。当然，它显然能完美契合某些人的需求——只是不包括我。
显然 Ruby 的意义远不止 Rails，但 Rails 无疑普及了“魔法对象”的概念——这些对象会自动同步状态并替你执行操作。粉丝们将其描述为惊喜而美妙，而非惊悚而恐怖。
Python热门项目如requests和flask也倾向于提供既表达力强又能在正常路径下极致简洁的编程接口——尤其可见于flask的上下文局部代理(request, session)；这些看似全局模块导入，实则专属于请求本身，尽管并未传递至处理程序…呃。
另一方面，像Zig和Go这类语言则像是对此的反动，它们宣称魔法是糟糕的，一切都应显式化，即便为此需要付出额外的代码成本。
Rust在这方面占据了有趣的平衡点：它本身严格而显式，但宏系统和类型系统的设计重新开启了提供DSL式功能的大门——在程序员接口层面，这种实现方式或许比其他语言更简洁。
有趣的是你提到了Flask——它最初确实是作为愚人节玩笑诞生的[0]，但这并未阻碍它成为第十[1]或第十一[2]大流行Web框架，其开发者数量已超过Rails两倍有余。可见“严肃性”与用户选择并无必然关联。
[0] https://lucumr.pocoo.org/2010/4/3/april-1st-post-mortem/
[1] https://www.statista.com/statistics/1124699/worldwide-develo…
[2] https://survey.stackoverflow.co/2025/technology#most-popular…
> 特别注意 Flask 中的上下文局部代理(request, session)；它们看似全局模块导入，但实际上是请求特有的——尽管并未传递给处理程序… 哎呀
我猜这是Armin Ronacher借鉴Bottle的设计：https://bottlepy.org/docs/dev/api.html#request-context
事后看来是个糟糕的设计，但现阶段难以修改：https://github.com/bottlepy/bottle/issues/761
约十年前我因多重因素从Ruby转投Elixir。其一在于将算法移植至Elixir后性能提升十倍；其二在于100%不可变特性彻底杜绝了整类错误；其三在于卓越的并发支持(当然得益于不可变特性)；其四在于它努力保留了Ruby的友好特性。
后来又涌现出不少优势：模式匹配+条件守卫堪称神级特性，彻底消除了大量冗余的参数检查逻辑；进程级GC、无GIL等特性更是锦上添花。
虽然掌握函数式语言语义需要些学习成本，但我从未后悔过这个选择。
Elixir在各个维度都展现出更优的扩展性——无论是长期维护还是负载处理。
不过Ruby社区确实令人惊叹。
唯一遗憾的是它无法编译为原生可执行文件或在浏览器中运行。
我的经历与此高度相似。
虽然至今仍保留着“Ruby式思维”——它确实是我首个能从容构建大型项目并深度运用元编程的语言。但个人项目更倾向使用Elixir/Erlang。
至今尚未有幸参与Elixir/Erlang团队协作开发大型代码库，因此这类场景我仍倾向C++。
工作中被迫使用Go和Python，二者皆无乐趣可言。个人需求的小脚本我依然会选择Ruby。
个人认为Ruby比Go或Python强千倍。当然这只是个人观点。
我有幸从事Elixir相关工作已有数年。有趣的是，自从接触LuaJIT及其C语言FFI并目睹其惊人的性能表现后(作为高级脚本背景出身者)，我开始渴望更深入地接触底层实现。我满足于将某些过于复杂的Bash实用函数移植到LuaJIT，目前体验全都是积极的。
我对Ruby并无好感，但《连线》原文纯粹是经过提炼的愤怒式点击诱饵，不值得任何人给予重视。若这篇文章仅发表在个人博客而非Wired.com上，或许会获得更宽容的解读。
但即便作者初衷良好，这类文章(具体指：由非长期使用者撰写的流行编程语言严苛批判)仍是HN的毒瘤，它们煽动的语言之争堪称我们社区最接近细胞因子风暴的现象。请勿助长此风。
这篇文章读来像是有人在为自己的语言辩护。这本身不让我困扰，但我并不看重这种辩护。
我不在乎什么语言流行或什么语言最熟悉。我想要的是冷静探讨不同语言特性如何影响代码质量，而这种探讨只能在更抽象的层面实现。那种谈论单子和应用器的讨论，往往令人望而却步。
> 我想要的是冷静探讨不同语言特性如何影响代码质量
这很困难，因为代码质量、生产力、安全性难以客观定义和衡量，我们总会退回到解读和经验的差异。
即便缺乏数据支撑，我仍乐见严肃论证此观点的尝试。
例如，我认为不可变性能显著简化多线程编程(可能伴随性能代价)，因为它能彻底杜绝常见类型的错误。
同样，允许方法开放扩展(如Kotlin或Julia)能让生态系统在无需显式协调的情况下更轻松地采用统一API，这点也颇具说服力。
垃圾回收能避免大量内存安全错误，尽管会牺牲互操作性和性能——这显然是极具说服力的论点。
> 冷静探讨不同语言特性如何影响代码质量
我认为我们在此处可以开始产生分歧。
评估标准不应仅限于代码质量，还应包含简洁性、可读性及表达效率。
增加语言摩擦力(如类型系统、“唯一”实现方式及函数式编程)将提升代码质量。在重型类型系统和严格函数的语言中，相同代码自然会“更稳健”。然而编写耗时将增加十倍，灵活性降低，可理解性也更差。
> 然而编写耗时将增加十倍，灵活性降低，可理解性也更差。
我的经验并非如此：仅在最初几个月的适应期存在这种现象。
可知晓哪些文章/论文深入分析了构建大型系统时哪些特性更有效？
我所见多数帖子基本只说“X语言好”或“Y语言差”，但我真正感兴趣的是“特性A比特性B更擅长实现目标Z”这类论证。
这观点非常精辟。我的经验是大型项目中架构同样至关重要。
大型项目虽代码庞杂，但若架构支持职责分离，便能保持代码精炼。
Ruby在这方面有个优势特性：无需yacc或lex即可创建领域特定语言，这能在需要时实现代码精简。
虽不完全相同，但我认为“数据导向编程”是管理大型代码库的强力方法。其核心在于：通过数据结构定义目标终态，另设代码集实现路径，并保持两者间清晰的边界。
(若你认同“函数式核心，命令式外壳”的理念，这正是进一步划分函数式核心的途径。)
这种方法之所以有效，在于它大幅缩小了潜在错误的范围：要么配置错误，要么转换逻辑有误。
你描述的类似于流式编程(FBP)，即数据传递给无状态功能模块。
Unix管道、Node-Red和n8n等工具都受到FBP的启发。
我认同你的描述，且代码通常无状态化后复用也更简单。
不过确实存在更适合DSL的语言。
有些编程语言期刊常被人们轻蔑地称为“学术性”刊物。但“学术性”恰恰是我在此看重的特质。
编程语言期刊数量众多——您是否推荐哪些专门探讨功能取舍的期刊？
你需要的是《优雅的Ruby》这本书：http://eloquentruby.com/
我确实曾因Ruby的表达力、纯粹面向对象特性以及优美易读的语法而钟爱它。
不过那已是二十年前的事了。如今我发现Kotlin凭借静态类型和符合人体工学的语法，完美契合我的项目需求。当Ruby项目规模扩大时，我便不再有把握。尽管如此，我依然热爱这门语言——虽然主要用于小型项目。
确实。我对Ruby原本持中立态度，直到某次工作中同事给会话相关的变量加了@符号，结果突然所有人都能看到彼此的账户。
有人或许不会因此责怪语言本身，但这简直是自掘坟墓。我注意到一个趋势：最危险的项目往往倾向于选择安全机制最薄弱的语言(类型安全不足、无编译检查、内存安全缺失、并发安全薄弱、共享状态保护不足)。
你为何认为这比有人说“某同事在Java中给会话相关的变量加上
this.后，突然所有人都能看到彼此的账户”更严重？因为“@”的含义不如“this”明显？编辑：我忘了Java有隐式
this！那才叫糟糕透顶！这种情况在任何语言都可能发生。我曾在Java项目中见过类似问题，源于有人错误设置了Bean作用域。
你指的应该是变量上的@@，这种用法在Ruby项目中并不常见。@@表示类变量，确实可能导致跨会话数据出现各种问题。
我用Ruby十三年，只见过一次有人给变量加@符号…那还是广告随机化程序的分布式缓存策略的一部分。
Ruby 默认不支持不可变性，哈希表在读写时不复制键值的事实呢？几乎所有程序都用到哈希表，而 Ruby 让它们变得格外危险。
至少 Ractors 提供了新的不可变特性。
例如：Ractor.make_shareable(data)
倒也不尽然。比如在IRB里试试
if.class就知道了。但确实是主流编程语言中最接近实现的方案。
作为20年的Python爱好者，我选择忽略这些缺陷，享受编程乐趣。
用Ruby编程是种享受。在接触过Haskell和Smalltalk后开始探索Ruby，惊喜地发现它能同时兼顾这两种语言的特性。
仅供参考 作为没有Ruby编程经验的人，我的体验是它会做不可预测的“魔法”操作，在编写日常代码时并不实用。 仅供参考
使用Ruby时需牢记四点要诀：
1. 万物皆对象，核心思想是向对象发送消息而非调用方法。这点至关重要，既是语言运作机制的核心，更是解读Ruby代码的关键。
2.
false和nil属于假值(falsy)，其他类型在条件语句中直接使用时均为真值(truthy)。例如：当变量值非false/nil时，if语句将进入true分支；否则进入else分支。3. 启动irb(交互式控制台)，使用
<对象>.inspect+<对象>.class可查看内部机制。Ruby具备强大的内省能力——谨记开篇所述(万物皆对象)，几乎任何内容都能被检视。4. Ruby 中括号可省略。例如：user.upgrade_to “admin” 实际等同于 user.upgrade_to(“admin”)
这是在 Rails 应用中吗？我不确定标准库 Ruby 会做哪些特殊处理，但 Rails 确实做了 很多 。
若想了解 Ruby(及衍生框架 RoR)广受欢迎的核心原因，请参阅非主流编程语言 Stanza 作者撰写的这篇精彩文章[1]。
引自该文[1]：
"休闲网站设计师可完全忽略类型和内存释放概念，因为 Ruby 采用动态类型和垃圾回收机制。这些特性在其他语言中根本不存在。例如Java的元编程功能，其强大程度远不足以实现ActiveRecords这类系统。Rails之所以可能，正是因为Ruby的存在。"
但我认为，即使采用类型化设计，编译型语言(如D语言)仍能凭借强大的元编程特性实现类似ActiveRecords的系统[2]。
[1] 停止设计语言。转而编写库：
https://lbstanza.org/purpose_of_programming_languages.html
[2] D语言：特性概览：
https://dlang.org/comparison.html
真高兴有人已经对此发声——我喜欢《连线》杂志，但那篇文章实在太差劲(并非因为我偏爱Ruby或认为它完美无缺，而是因为其论点本质上是“它不像Ruby或Python那样具备静态类型工具”)。
那篇《连线》文章简直像是GPT对过去二十年人们对Ruby各种诋毁的总结。
继续把“无法扩展”当作有效论据简直愚蠢至极。并非所有应用都是或将来会成为Twitter。
作者素来以贬低编程语言为乐，这似乎成了他的个人标签：https://www.wired.com/author/sheon-han/
我曾享受过Ruby作为语言的乐趣，但真正令人抓狂的是(至少十年前如此)没人真正编写线程安全的Gems(因为所有人都为单线程的Rails开发)。再加上泛滥的猴子补丁导致标准库难以依赖。这些特质让我觉得它实在不够“严肃”。不过这些抱怨是否依然成立我不得而知。至少线程安全问题应该已得到解决。
> 泛滥的猴子补丁导致标准库难以依赖
使用Rails后进行常规开发时，这种情况令人非常沮丧——所有“内置功能”其实都是Rails补丁到标准库中的，脱离Rails就无法使用。
> 其中最令人抓狂的一点是(至少十年前如此)
如今已不复存在。
> Rails 采用单线程架构
同样已成为历史。
看来十年间事物确实能改变？
Ruby最大的缺陷在于它坚持认为人类很重要。有些人对此深恶痛绝。
这种论调几乎和说Ruby不是严肃语言一样居高临下。
Ruby的崛起与流行，源于它填补了当时竞争对手未能满足的细分需求(虽然我不是历史学家，但Rails在Ruby的普及中起到了 关键 作用)。
Ruby确实极具人体工学设计，Rails亦然。坦白说，即便离开它近十年，ActiveRecord仍是衡量其他语言ORM人体工学的标杆——当然不同领域对人体工学的定义各异。
使用Ruby和Python这类语言时，从零开始构建出基本可用的应用几乎轻而易举。轻量级语法、大量隐式功能以及灵活的类型系统都为此提供了极佳支持。但在我的当前领域(现使用Rust开发)，这种特性并不适用——尽管语法更繁重、语义更复杂，但 显式控制 却是Rust的核心优势。这并非意味着Rust设计时忽视了用户体验，相反，它恰恰体现了对用户体验的深度考量。
若你指的是优先考虑编码体验(人体工学)，我个人更倾向避免被某些魔幻效果咬伤。
书写Ruby确实令人愉悦，这点我承认，但大规模维护他人编写的Ruby代码则令人痛苦。
与什么相比？
当时是Java。J2EE(实体bean和会话bean)、Java服务器页面、Apache Struts。我认为没经历过那段岁月的人很难体会1999-2003年间使用这套技术栈的痛苦——整个行业竟能接受如此冗余的模板代码换取微薄附加值，简直难以置信。
后来Ruby和Rails让许多人意识到：API设计不仅要遵循S.O.L.I.D.等原则，更应追求“愉悦性”。如今已有更多主流语言、框架和社区开始重视人性化API的设计。
暂且不论这其实是Ruby与其他语言的较量而非Rails与其他框架的对抗，我始终觉得Ruby更注重让代码在幻灯片上好看，而非满足人类真正的需求(比如一目了然地传达语义)。
我确实写过大量Ruby代码，对这门语言并无强烈偏见——除了“下一个用method_missing的人我准毙”这句宣言。但那些对Ruby怀有强烈执念的人，始终令我着迷不已。迄今为止，这门语言最人性化的特质，莫过于围绕它形成的社群生态。
显然是人工智能。
作为一个不懂Ruby的人，我完全搞不懂你这话是什么意思
Ruby试图让事物接近自然语言。
> 它坚持认为人类很重要。
呃，怎么说？
程序员是人类，而他们浪费资源的终端用户却不是。这很明显。
呃，读读这个试试看。https://www.ruby-lang.org/en/about/
维基百科Ruby页面中的“语义与哲学”章节提供了很好的概述：
https://en.wikipedia.org/wiki/Ruby_(programming_language)#Se…
在我接触过的六种以上编程语言中，Ruby是最有趣的之一，使用它时我效率极高。遗憾的是，由于曾在一家滥用Rails框架导致公司瘫痪的Ruby公司工作，我如今不再享受使用Ruby，也绝不会推荐将Rails用于生产级软件。但愿你对Ruby的体验更为美好，仍能享受用它编写优雅软件的乐趣——当然最好别用Rails。
J.K.罗琳在鸡尾酒餐巾纸上构思《哈利·波特》大纲固然是种艺术。一支笔加一张餐巾纸确实能成为绝佳的创作载体。但这种灵活性同样让旁人得以涂鸦，甚至有人借它擦鼻涕。
赋能卓越的 能力 既不等同于 激励 卓越，也非 保证 卓越，而Ruby和Rails社区顶层充斥着幸存者偏差。
我也有类似经历。
我热爱Ruby，但太多公司默认我指的是Rails。我永远不会推荐Rails用于任何项目。
我宁愿每天都用Sinatra和Ruby。
这正是我的做法。我不太喜欢Rails，但热爱使用Ruby和Sinatra。社区在发布工具时做得很好，将Rails与Ruby分离，确保它们不依赖或要求Rails。
许多人对Ruby的抵触情绪主要源于：我认同Rails的哲学理念(需要时进行大改动就像驾驶货轮而非小船)，以及由此带来的复杂性，或是那些关于元编程实现不当的恐怖故事——这些观点我都深有同感。但Rails不等于Ruby，且如今社区在元编程应用上已比早期谨慎得多。
Ruby通过Rails取得的成功虽是短期利好，却也同时阻碍了其未来发展——开发者对庞大Rails应用的糟糕体验，往往与他们使用Ruby本身的感受混为一谈。
就个人而言，我对 Ruby 的热爱已深入骨髓。倘若它真会衰落到无法胜任现代任务的地步，我已决定届时便从编程领域退休，转而追求人生其他可能。并非我无法学习新语言来支撑日常工作，而是此刻…实在不愿如此。
若想保留Ruby语法体验新语言，我推荐尝试Elixir。
它基于Erlang理念构建，却拥有Ruby的语法，堪称截然不同的编程范式。
我曾觉得Crystal语言相当酷且类似，但从未遇到适用场景去尝试它——因为Ruby本身已能处理所有需求。在我的领域中性能极少成为瓶颈，而且我也不愿用它构建包含大量复杂业务逻辑的大型Web应用。
引自楼主回应的文章：
> 关键在于，Ruby的性能表现始终在主流语言中垫底(即最慢)。
未见引用依据，或许因其并非事实。Ruby的性能与Python相当。诚然，两者都不会在竞赛中胜出——尽管我不确定“主流语言”的具体范畴。
> Ruby 的性能与 Python 相当。诚然，两者都不会在任何竞赛中胜出…
问题不仅在于它们无法赢得速度竞赛，更在于 Ruby 和 Python 注定垫底。唯一悬念是哪个垫底哪个倒数第二。紧随其后的通常是 Perl、PHP，有时还有非即时编译的 Lua。任取任何基准测试，结果都如出一辙：https://benchmarksgame-team.pages.debian.net/benchmarksgame/…
选取任意基准测试，逐行转译程序代码就能彻底印证这个结论：
https://benchmarksgame-team.pages.debian.net/benchmarksgame/…
关键在于，若有人能提交更快的实现方案，此刻早该出现了。当前公布的数值已是极限表现。
这纯属猜测。
这完全呼应了我对Ruby的感受。虽然多年未曾深入编写Ruby代码，但我始终以经典的ruby/rails/rake/gem/bundler体验作为衡量所有开发环境的标尺，无论在Rails生态内外，我都怀念Ruby曾带来的高效协作体验。Ruby最卓越之处在于能灵活调整结构以契合问题领域。Rspec、ActiveRecord，以及程度稍逊的Bundler和Rake，至今仍是同类工具中我用过最符合人体工学的版本——它们都提供了某种强大的领域特定语言(DSL)，那种恰到好处的魔力感令人着迷。
如今我主要使用更“严肃”的语言(Python、Java、C#、C++)，但这源于我想在这些语言的特定领域工作，而非没有时间将该领域迁移到Ruby。我该给她打电话了…
关于“Ruby不是严肃编程语言”这篇垃圾文章的精彩评论比比皆是，它确实垃圾。真正困扰我的是这篇文章竟刊登在wired.com上。我本期待《连线》能有更高水准，可惜这篇文章注定会获得大量点击。
> 我从未见过团队因选择Ruby而失败。我见过他们因选择复杂性而失败。因选择优柔寡断而失败。因选择“严肃性”而非发展势头而失败。Ruby只需退居幕后，让人们专注于真正的工作。
我对Ruby话题完全无感，但这句话深得我心。我宁可选择发展势头，也不愿为规模而过早优化。
我的回应更为简洁：文中所有批评其实都不影响可用性，若它真不如其他语言实用，人们早就弃用它了。真希望Shopify能成为主要案例，因为它正是《连线》杂志声称“几乎不可能实现”的那类高并发、数据密集型应用。
说真的，将Ruby定性为“不严肃”实属小题大做。我本人虽不热衷此语言，且十多年前调试云部署Rails应用的依赖腐化问题后便兴趣索然，但将其斥为“不严肃”，其荒谬程度几乎可与贬低Python相提并论。
罗比这篇文章写得很好，毕竟争论定义往往是徒劳无功的浪费时间。摘录自[1]部分内容：
参见[1]获取突破无谓争论的技巧：
> 个人认为若出现定义争议，双方应转而用明确的低层级构成要素描述事件…
> …或各自创造新词如“alberzle”与“bargulum”，
> …并保持一致使用。如此双方既无需退让丢脸，又能继续沟通。
> 当然，必须始终追踪争议的核心——某个可验证的命题。
> 各位觉得这个方案合理吗？
[1]: https://www.readthesequences.com/Disputing-Definitions
作为逐渐被卷入智能体与AI工具浪潮的一员，我愈发觉得语言之争比以往更无意义。
手动内存管理与GC、JIT与AOT、解释型与编译型、大括号与花括号、安全模式与否——这些争论皆无意义。
我们将逐步迈向某种面向自主系统的规范(请别是基于YAML的)，到那时语言之争将变得毫无意义，仅对少数负责实现底层集成技术的开发者仍有意义。
作为从未深度使用Ruby的人，我唯一的抱怨是：鉴于其技术渊源，它本应提供更接近Smalltalk的开发体验(不确定RubyMine表现如何)，以及内置完善的JIT(这正在实现)。
《连线》那篇文章纯属诱饵，但确实奏效了。至少我们现在讨论的是Ruby <3
若Ruby能养家糊口，称其为“不严肃的语言”未免牵强。看看Mike Perham的Sidekiq——他靠销售RubyGem谋生。
说实话，若非Rails框架，Ruby如今早被遗忘了。
如今Ruby不过是维护老旧Rails系统的工具语言。
全球绝大多数Ruby程序员都聚集在日本，在那里Ruby的应用远不止于构建Rails应用。因此Ruby不会消亡，尽管在西方世界它终将沦为一种怀旧的玩意儿。
文化或许如此，但商业只奖励能推动商业运转的事物。Ruby证明了它能让企业起步并持续发展。那些超越运行时能力的少数项目不得不部分或完全转向其他技术——但若Twitter最初选择用你心目中“严肃”的语言编写，我们还会拥有它吗？或许竞争对手早已将其碾压。这永远是个未知数。
我确信的是，Ruby近二十年来始终支撑着我的生计。这远超我使用过的任何语言——无论严肃与否。它对我而言行之有效。
我敢肯定，Ruby应用的用户根本不在乎你的编程语言有多“严肃”。
任何语言的用户会关心语言的严肃性吗？..如今选择如此丰富，我热爱Ruby并持续使用，但也钟情Python、Elixir以及C++这类系统语言..
不会，这正是我的观点 😉 用适合你的语言，其余皆是噪音。
真希望有种像Ruby但支持强类型或静态类型的语言。
我喜欢它丰富的标准库风格和封装方式(比如带lambda的.map操作)。
我转用Scala纯粹因为Ruby没有类型系统。在大规模代码库中，重构变得极其困难，连重命名都变得复杂。
Ruby是强类型语言
好奇为何评论中无人提及https://crystal-lang.org/
《连线》原文本质上是围绕一个站不住脚的论点展开的冗长论述：Ruby因缺乏静态类型支持而落后。用“严肃性”来评判任何事物都显得滑稽可笑，但若硬要从这篇逻辑混乱的文章中揪出一个定义，那必然是“静态类型”。性能问题无法构成严肃批评——毕竟有Python的存在，况且在合理范围内本就不该成为问题。
除了静态类型和Ruby特有的元编程风格(有人或许会辩称Python支持基于装饰器的“元”编程，但无所谓)，Ruby和Python本质上是同类语言，仅存在些许语义差异。当然两者在采用率、库支持、社区氛围等方面存在显著差异。有人说Python本质是函数式语言叠加了面向对象特性，而Ruby恰好相反——但这些都无关紧要。在日常使用体验中，这两种语言本质上是相通的，而Ruby/Python与Go(或Java、Elixir等)则截然不同。除了静态类型支持之外。
我乐观地认为Ruby很快会解决这个问题，因为推动JavaScript和Python发展的静态类型支持正是Ruby能够且应当支持的。我的意思是这两种语言实际上都不具备真正的静态类型。TypeScript是另一种编译为JavaScript的语言，而Python的类型支持始终是可选的，可能永远如此，且如同JavaScript那样依赖外部工具(mypy、pyright等)实现。Python和JavaScript均不具备类型中心化/感知型运行时，甚至完全不考虑类型机制。它们本质仍是动态语言，仅通过优质开发工具辅助编写“类型安全”代码——但实际生产环境中，我们不过是在假装开发阶段使用的类型在运行时真实存在。
这并非对该方法的批判，而是对我们普遍存在的伪装行为的反思——当我们批评 Ruby“缺乏类型”时，却又赞美 JavaScript 或 Python“具备类型”，而它们显然并不具备。但这种方法本身是可取的，至少若你认同可选类型比 Java/Go 式的静态类型更优。
我不清楚是什么阻碍了 Ruby 更好地支持可选类型，但希望他们能尽快解决。我的感觉是——过度简化地说——Sorbet 变得过于流行，但本质上它属于一种“围绕语言构建类型系统”而非“在语言内部构建类型系统”的解决方案。
就个人而言，我迫不及待想看到“类型炒作”热潮退去。我承认类型提示在优化方面的实用性，但厌倦了人们总把类型当作编写安全代码的必要条件。他们列举的例子大多是类型如何防范最基础的错误——这些在面向对象的消息传递范式中同样能实现。在我看来，对象本身就是类型，其额外优势在于能以(姑且称之为)类型特有的方式定义操作。给JavaScript强行添加类型系统并不能消除所有缺陷，而将其硬塞进Ruby也未必带来变革(至少我希望如此)。这类需求已有Crystal语言应对。
暂且抛开性能问题，针对Ruby这类语言的合理批评主要集中于其幕后魔法机制的泛滥(以及程序员在不理解这些魔法的情况下使用库文件可能遭遇的困境)。但魔法本身并非天生有害。诚然，它可能增加大规模编程的难度，但同样能成为倍增力量的催化剂，大幅简化开发过程。我们不该因优秀程序员短缺就让编程变得痛苦。我们应当探索如何培养更多优秀程序员——而Ruby恰恰能在这方面发挥作用。它易于上手，虽是面向对象语言却支持各类编程范式，能助你探索各种可能性。当有人超越Ruby时，他们应该具备足够的认知来理解为何需要换马，并权衡这种转变的利弊。
> 你可以说Python的核心是函数式的，只是在上面叠加了OOP
你如何论证这一点？我认为如果一种语言至少不支持纯函数，就不能被视为核心函数式语言。
确实，你说的有道理。我的意思更偏向风格层面——Python允许从文件导出函数，其OOP风格显得比Ruby更基础且生硬，而Ruby提供了多种实现OOP和传递状态的方式(类、模块等)。
还有人觉得这类讨论因生成式AI而显得过时吗？
尽管存在诸多问题，AI的存在似乎本该为绝大多数程序员解决这些争论。只是我目前还说不清具体原因。
不，因为与AI协作编程的本质，已不同于我们传统定义的编码/编程。
这是全新的范式。若要论证其相对于既定标准的“优越性”，倒也无可厚非。
不妨用驾驶类比说明： 你可以说汽车能载人从A点到B点，因此自动驾驶和传送技术是更优的进化。但若有人想开车、享受驾驶、想提升驾驶技术，你不会建议他们坐上Waymo汽车或使用传送。
没错，但这个比喻很好，我们继续延伸。
可以设想这样一个未来：由于公共交通+Waymo的普及，全球多数人不再驾驶汽车。
在这个世界里，围绕“人类驾驶”的问题将呈现截然不同的特质与意义。安全性变得次要，界面偏好反而更重要，诸如此类。
我认为编程领域的类似变革近在咫尺，甚至可能已经到来。
此话怎讲？编程语言各有优劣，这些特性与大型语言模型完全无关。
即便你能用“氛围代码”编写完整系统，人类终究需要阅读并修改这种代码。通常是为了重构整体架构，即便奇迹般地保证了整体质量，也总有人需要审查代码并修复漏洞。此时编程语言及其生态系统始终是关键因素。
没错，但那些所谓的优劣势往往最终成为无关紧要的问题——即大众热议的语言优劣与实际应用场景几乎从不吻合。
我认为这种“脱节”在人工智能领域只会愈演愈烈。
我并非否定这类讨论的理论价值，也尊重参与者的兴趣。但我的判断是：在实际应用层面，这些争论绝大多数都无关紧要。
这种观点未免太天真。编程语言存在巨大差异，这些差异直接影响软件的开发、构建、分发及运行时执行方式，更不用说使用和维护方式了。
我尚未见到任何大型语言模型能消除这些差异。我唯一看到的是，它们给资深开发者制造了更多工作——不得不修复那些混乱不堪的意大利面代码。语言选择至关重要。
我不理解这条评论的含义。听起来你似乎认为编程时代已经终结，事实并非如此。
不，但正如我在别处所言——我感觉“编程和风格上的个人偏好”可能变得显著不那么重要了，这种情况甚至很可能发生。
我深有同感。我认为原因在于通用人工智能已有效消解了工具层面的差异。虽非完美且效率未必最高，但在需求→可行成果的转化过程中，它极大减轻了开发者在不同工具体验间抉择的痛苦。
这些文章读起来简直像是由通用人工智能撰写的，我敢这么说！
> 若工具使用体验良好……那必然意味着它不够“严肃”。
结构精妙。永远把稻草人论点摆在最前面。
敬请期待我那篇关于汽水的文章，开篇是：“我错过了那份备忘录——上面写着’味道好就等于不健康’”
读完整篇文章我仍不明白何为“严肃”编程语言的标准。它显然与Python截然不同，但用“严肃”或“不严肃”来描述这种差异实在令人费解。
RoR问世时堪称一股清流，它能以更少代码实现更高效开发，但如今我不会再选择它——其他语言早已迎头赶上。
RoR不等于Ruby。
这是多数人的误区——他们从RoR入门就误以为这就是Ruby。
这或许正是Ruby永远被视为“Web语言”、在其他领域难以获得_严肃_认知的根源。
除Chef等运维工具外，我未见其在其他领域应用。
值得一提的项目有：DragonRuby[1]——采用SDL底层渲染引擎，游戏逻辑基于mruby实现。我用不到两周的业余时间完成了这个[2]游戏开发大赛作品(存在少量bug但可运行)
[3] Sonic Pi——使用Ruby指令的音乐创作工具
[1]: https://dragonruby.org/
[2]: https://itch.io/jam/linux-game-jam2023/rate/2101760
[3]: https://sonic-pi.net/
Homebrew 也是不错的选择。
本文将 Ruby 仅视为 Rails 的附庸，这种视角严重偏离了语言本质，当前正削弱该语言的价值。作者显然未深入探索 Ruby 3 的强大特性。更不必说，它作为编程入门语言具有极佳的学习价值。
Ruby 具备惊人的多功能性：NASA 用它进行模拟计算，它也是脚本编写、DevOps 自动化和静态网站生成的热门选择。这种简单动态的语言最适合快速原型开发。
不过 Elixir 则是另一番景象。作为多年生产环境使用者，我可证明其生态系统卓越非凡。它缺乏主流人气无关紧要，真正的力量在于BEAM——这套架构精妙的软件。Elixir不过是获取这种力量的绝佳途径。除了类Ruby的语法，它早已成为独立存在。它曾主要作为Erlang的替代方案，但近年已发展出独特生命力。
我深恶痛绝语言教条主义，几乎每种编程语言都应成为程序员工具箱中的利器。学习和使用已淘汰的语言同样具有价值，这能让你跳出当前生态系统的局限获得全新视角。Fortran和Lisp等语言能在特定领域持续发挥重要作用自有其道理，我认为Ruby也将长期存在。
Ruby只是工具，这很正常。我不买那些关于它的感性宣传，更像是创意营销。
“傻瓜化”策略回报丰厚——取决于你站在哪边。但若说这代表“共鸣、清晰、人性、联结”，恐怕难以成立。
事实是，商业与文化在不同语境下会奖励千差万别的做法，这种现象贯穿多重抽象层面——从特定岗位所需的人才类型，到企业相对于市场的定位。你希望薪资管理员充满玩心吗？是追求深度共鸣——管他发多少工资，关键在氛围嘛兄弟？还是要求其按标准完成工作？作为财务软件供应商，你希望企业形象传递的是“共鸣·清晰·人性·联结”的理念？还是专注于“协助机构应对审计负担”？
正如商业在不同情境下重视不同要素，编程亦然。我不会用Ruby做底层系统编程，不会用Rust搞图形编程，更不会用C语言匆匆敲出CRUD应用。面对具体问题时，你只需选择当时最易获取的合适工具。有时是因为特定语言能提供优质的库访问与支持；有时是因为现有代码库已采用该语言编写；有时则是语言特性与特定任务高度契合。
这无关工具是否严肃。严肃与否取决于人。语言只是工具，当你选择它时，真正赋予语言严肃性的，是你对待工作的态度是否认真。
Ruby是种优秀语言，它将人置于机器之上。
然而Rails的成功也成了它的最大包袱。尽管Ruby适用于系统任务(如自动化配置等——Chef确实存在，但此后未见新一代工具诞生)，人们却遗忘了它的这种能力。
另一问题在于某些社会正义战士未能区分程序员D.H.H.与个人身份，且忽视金钱(流动性与引力)如何驱动世界——例如Shopify对Ruby生态的渗透。
未能理解初学者是生态系统的生命线——至今仍不清楚Ruby能否有效运行于Windows环境。多数人使用Windows而非Mac或Linux设备。
它并非因速度过慢而失败(其速度已足够快)
> 未能理解初学者是生态系统的生命线——至今仍不清楚Ruby能否在Windows上高效运行。
标准安装中也未包含类似Python自带的IDLE环境。
我认同作者观点：在AI代码生成与开发者倦怠的时代，Ruby这类语言能延续编程的乐趣。但编程终将如同手工摘棉籽般费力，而非使用脱籽机。
Ruby确实是种享受。我日常使用C#，它恰好平衡了趣味性与严谨性。但我始终更偏爱 Ruby 而非 Python 及其他 C# 生态外的语言。必须说明，我确实热爱 C# 开发。可惜 Ruby 未能持续崛起。
Ruby 略显俏皮，但凭借其承载数代互联网项目的血统，Rails 无疑是严肃的框架。
这读起来像是用ChatGPT生成的文本，把所有破折号替换成省略号。几乎每个段落都以“那不是X，而是Y”式的论断收尾。
若非AI生成的垃圾，那也绝对是拙劣的写作。
它的严肃程度取决于你想要/需要的程度。
我莫名觉得这段文字曾被批量替换过破折号。
撇开这个不谈，虽然我足够“老”，记得编程语言社区间这种基于文化/氛围的竞争，也读过足够多的文献知道这种现象比最年长的灰胡子前辈还要古老(TIMTOWTDI vs Python禅，‘真正的程序员不写Pascal’，“BASIC有害论”)，但我不确定这种论调如今还有效。
若暗示Ruby与其他社群的差异在于Ruby开发者是(唯一？)在乎“代码体验”的人群，未免有些不合时宜——这恰恰是所有编程语言推广的核心卖点。我甚至有点紧张地等待着首个以“你可能不喜欢它，但大型语言模型爱死它了”为宣传点的重量级语言。
我怀疑真正的问题在于：数据科学+机器学习/人工智能领域涌入了(大约)无数人投奔Python，而LLM训练数据集的构成将使他们继续留在那里。与此同时，所有关注性能或正确性的Ruby开发者(好吧，我这话说得有点煽动性)都转投了Rust(或者早已离开，转投Erlang、Haskell、Elm或其他语言)。如今在动态类型至上的Ruby世界里还剩谁？DHH？(这位人物近来颇具争议。)
回溯二十年前，有两个Web框架正彻底改变人们对Web开发的认知。可惜我当时所在的公司并未采用，这正是我转投他处的缘由。
它们分别是Django和Ruby on Rails。我已掌握Python，而Django代码精良、文档完善，让我能快速上手。即便文档未尽其详，我还能直接研读源代码。简直完美。
那家公司雇了个精通Ruby on Rails的家伙，我真心想喜欢上这个框架。我欣赏那家伙的工作成果，他看起来也是个正派人，况且我没那么自负，不会在别人有完美替代方案时硬要说“非用我的不可”。好吧，其实我确实有点自负，但这次例外。关键在于，虽然我当时已经会写Python，但我其实并不在乎用哪个框架——毕竟任何框架都比公司网站当时使用的、混杂着HTML的臃肿无结构PHP4代码好得多。
我真心想喜欢 Ruby on Rails，但文档似乎默认读者已精通 Ruby 甚至 Rails。好吧，那就先学 Ruby。
IRC 频道推荐了付费视频教程——“这就是未来，现在人人都看视频学东西”——还有《(Poignant) Ruby 指南》。
我完全不喜欢《(Poignant) Ruby指南》。每页充斥的“我超搞怪搞怪搞怪”式幽默让我反感，更对书中狗的故事毫无兴趣——这段插曲直接让我对整章内容失去兴趣。后来我尝试重读过五次左右，但始终无法适应那种美式胡言乱语诗体写作风格。
(顺带一提，我也对艾伦·金斯堡没什么好感)。
后来整个Basecamp事件闹得沸沸扬扬，DHH在赛车圈早已臭名昭著，难怪他最终暴露成那种人物——要是1940年代我祖父还在世，绝对会开枪毙了他。
所以，这就是我始终与Ruby合不来的原因——尽管我多么希望喜欢它。
坦白说这篇文章根本不值得回应。这是我近年读过最糟糕的新闻报道，让我怀疑是AI生成的垃圾。
> Ruby吸引着特定类型的人。并非更优秀，也非更聪明，只是…与众不同。他们关注代码书写与阅读的体验，视编程为能传递情感的工艺，深谙职业生涯多在他人决策中度过——因此快乐并非奢侈品…而是维系这份工作人性化的唯一途径。
所谓“在意程序的书写与阅读体验”竟被视为“异类”，这想法让我感到奇怪。我不用 Ruby 编程，或许只是不懂得欣赏这种差异。
不过话说回来，我在Octave、Fortran和Python里写过些有趣又傻气的实验代码……虽然不确定别人读起来是否愉快，但我实在想不出哪种语言能阻碍编程的乐趣(当然Java除外/s)。
>我实在想不出哪种语言能阻碍编程的乐趣
因为编程者需要背负大量语法规则和陷阱，这些在创作时很难时刻牢记于心。
像C++和Java这样的语言虽然功能强大，但从开始到结束之间存在太多障碍，除非你精通该语言或有学习的渴望，否则很容易就放弃了。
Ruby和Python这类语言虽非最快，但其语法极其直观，从零到成的学习成本仅为其他语言的零头，使开发者能更快交付成果。
从热爱学习的开发者视角看，简洁的语言反而激发我探索复杂语言的热情，进而获得更多享受编程乐趣的机会。
C其实并不复杂，坦白说它属于文档最完善的语言之一。其语义清晰明确，若不喜欢概念、模板元编程和类层次结构等高级特性，完全可以选择专注于C的子集(我通常建议避免在C++中使用面向对象编程，正如在其他语言中一样)。
Ruby为初学者施展了诸多魔法，这意味着其语义模糊不清。在我看来，这类似苹果公司为提升销售而优化UI/UX初体验的做法——忽视了熟练用户的需求，简单操作易于上手，但最强大的功能却对熟练用户和高级用户缺失。
我并非否定Ruby的价值，只是持相反观点。我也热爱学习，但Ruby非但未能助我成长，反而成为学习的绊脚石。
打造语义清晰的简洁语言并非难事，Go、C、Python皆为明证。
> C++ 没那么复杂
C++ 复杂到这样的程度：把十位 C++ 开发者关进同一间屋子，他们谁都读不懂彼此的代码——因为每个人都用了一套互斥的 C++ 特性集编写代码。
你写过C++吗？根本不存在“互斥”的特性集。我能想到的过时特性只有auto指针和三字符序列，但现实中从未见过它们的身影。
我是在开个夸张的玩笑。但“互斥特性集”指的是两个特性集之间没有任何重叠特性。
如果毫无事实依据，这种玩笑就不好笑了。
我明白互斥的含义。根本不存在两个编写C++时语言特性完全不重叠的人。我实在难以理解你究竟想表达什么。
指完整语言特性集中的非等价子集？任何非简单语言都会存在这种情况。
那就算了，你不懂笑话也无妨。
>C++没那么复杂
具体相对于什么而言？
当资深开发者至今仍在发布存在内存漏洞的软件——这些漏洞会泄露数据甚至导致系统崩溃——这种情况下，实在很难认真看待你这样的论断。
我所说的“不复杂”并非指C完美无缺，也非暗示用它编写无瑕疵代码易如反掌。显然C最擅长的领域是其专属领域：电子游戏、科学计算和性能关键型软件。你提到的那些问题，正是开发者获得更高控制权所付出的代价。这些问题确实存在，你的观点完全成立。
我的意思是：若想彻底理解语言机制，我敢打赌C++比Ruby提供更清晰的认知路径。其文档体系及周边生态——包括会议演讲、内容创作者、新特性深度解析等资源——都极为出色。更不用说像libera.chat上的IRC频道这类公开在线社区了。
我回应的原帖作者认为C需要极大投入才能掌握，但我认为这适用于所有语言，而C在引导学习者达到这个境界方面表现尤为出色。
> 相对于什么而言？
生活
我热爱Ruby(…具体场景下，最关键的场景是“小型程序”)及其整体文化(_why是/曾是传奇人物)，但厌恶Rails。
实际操作中，这意味着我不再专业使用Ruby，因为非Rails的Ruby项目寥寥无几。由于工作中大量编写Python代码，我个人也倾向用Python写快速脚本——纯粹出于简化“工作记忆”负担的考虑。况且Python已预装在多数系统中，Ruby则不然。
我确实关心语言的“愉悦性”，但更在意代码库经历过众多承包商和代理公司之手后变得混乱不堪，测试套件在两年活跃开发期内从未更新——这种情况下语言的易用性才是关键。若为个人“愉悦”着想，在这种情况下请给我Go或C#，甚至Java也行。当代码库陷入这种状态时——而这种情况屡见不鲜——我很难从Ruby中获得多少乐趣。
说得好。
RobbyonRails提过自己是无神论者。但根据我的经验，多数人并非真正的无神论者，他们只是用自我取代了上帝。在软件工程领域，我见过太多自负与自以为是，现在觉得当初选择这条路是个错误。
在风投狂欢/Ruby时代仓促拼凑的平台中存在重大缺陷，似乎积攒了无法化解的技术债务。或许Ruby天生吸引着这类人——他们宁可在推特上讨论F1赛车，也不愿指挥成千上万员工修复发货计算器。
Ruby从设计之初就不是严肃语言。它追求PHP般的趣味性，却不愿陷入PHP的丑陋。而PHP逐渐成熟，Ruby却日渐荒芜。
爱一件事物并意识到它存在无法解决的问题，以及某些人注定要维持这种状态，这无可厚非。当今世间，多数事物皆如此。
人们攻击Ruby的原因在于其用户总高调自负，宣称“他们的语言”占据特殊地位，是专为开发者快乐与幸福而生。
正是这种荒谬的自负与傲慢(注意从未被量化)，促使人们想要让Ruby的自负回归现实。
Ruby之所以遭受攻击——正是因为它毫无特殊之处，而Ruby爱好者俱乐部却坚称它与众不同。
这类观点往往比你讨论的对象更能反映你自身。