HackerURLs

一次又一次被重新发现的经典。

同一个链接,相隔一年以上,一次又一次被人重新发现、再次冲上 Hacker News 首页。能经受住这种时间检验的,大多是值得一读再读的文章。每篇附中文标题,讨论最热的那些再加上中文导读和高赞评论翻译。

从名人堂开始
  • 4,700+篇经过时间检验的经典

Hall of fame

名人堂

在经典库里看全部精选

上首页次数最多、而且有中文导读的 30 篇。时间轴上每个黑点是一次上首页,空心点是一次没冲上去的投稿。

  1. 正在载入经典…

Archive

经典库

按第一次上首页的年份分布,点柱子筛选。

排序

    About

    这些经典是怎么挑出来的

    1. 01

      合并同一个链接

      读取 Hacker News 自 2006 年以来的全部链接投稿,把 http/https、www、跟踪参数等写法不同的同一篇文章合并成一条。

    2. 02

      只留经得起时间的

      同一链接至少两次拿到 50 分以上(约等于上首页),而且两次相隔一年以上;再由 AI 剔除状态页、产品首页和新闻事件。

    3. 03

      写导读、译评论

      上首页次数最多的 2,000 篇配上中文导读、"为什么经久不衰",并精选翻译 HN 高赞评论。导读由 AI 生成,可能有误。

    编程与软件工程hamidreza-s.github.io

    Erlang 垃圾回收细节及其重要性

    Erlang Garbage Collection Details and Why They Matter

    3次上首页
    6年跨度
    295累计得分
    92条评论

    2015 — 2021,它一次次回到首页

    黑点是上首页(≥ 50 分)的那次投稿,空心点是没冲上去的投稿,点越大分数越高。

    导读

    这篇文章讲解 Erlang(BEAM 虚拟机)的垃圾回收机制与其内存布局:每个进程拥有独立的小型堆,采用分代复制式 GC,进程被调度运行一段时间后各自回收,因此单次停顿很短;文中还介绍了堆碎片、引用计数二进制等堆外数据的处理方式。作者进而论证这种设计是 Erlang 适合软实时系统的关键原因之一。

    为什么经久不衰:它把 Erlang 低延迟背后的进程级独立堆与复制式 GC 讲得清楚透彻,是理解 BEAM 运行时行为的经典入门材料,多年后仍被反复翻出。

    关键词 Erlang垃圾回收BEAM软实时

    HN 评论精选

    文章只下结论不给基准数据,说服力不足。

    我原本期待这类文章先给出数据,证明 Erlang 的 GC 停顿比 Java 或 Go 更短,再解释原因。结果它只是断言 Erlang 的 GC 延迟优于其他系统,然后就让我们直接相信。作为对 Erlang GC 工作原理的描述它没问题,但作为“Erlang GC 停顿短”的论据则完全没用。

    kjksf查看英文原文

    I would expect this kind of article to start with numbers showing that Erlang's GC has shorter GC pauses than, say, Java or Go and then explain why this is so. Instead it merely states that Erlang GC has better latency than other system and we're supposed to just believe it. It's fine as a description of how Erlang GC works but totally useless as an argument that Erlang has short GC pauses.

    质疑这是语言规范保证还是当前实现的细节。

    这里面有多少是真正属于“Erlang”的 GC,又有多少只是 Erlang 当前实现恰好如此?Erlang 语言本身规定了 GC 必须这样工作吗,还是语言允许任意 GC 实现?简而言之,如果你用 Erlang 写代码,你能确定 GC 一定会按文中描述的方式行事吗?

    joosters查看英文原文

    How much of this is truly "Erlang" GC and how much just happens to be the current implementation found in Erlang? Does Erlang the language specify that this is how the GC acts, or is the language free to use whatever GC implementation it likes? iN short, if you are writing in Erlang, can you be certain that the GC will always act in the manner described?

    结论里对 Go 的讽刺跑题且曲解原意,比较不同设计目标的语言没意义。

    这篇意外地有信息量的文章我一路读得很享受,直到结论部分:作者引用 Go 内存模型文档里“如果你必须读完本文档才能理解程序行为,那你就太聪明了,别耍聪明”这句话来反驳,说我们必须足够聪明才能让系统更快更安全。可这一记对 Go 的暗讽适得其反——作者显然曲解了那段话的本意。Erlang 和 Go 确实有功能重叠,但两者在保证和工程现实上的取舍决定了各自适合不同领域,这样互相攻击纯属浪费时间。TLDR:拿设计目标截然不同的语言互相比高低显得很傻。

    jaytaylor查看英文原文

    I enoyed this [unexpectedly] informative read right up until the conclusion: Even if we are using a language that manages memory itself like Erlang, nothing prevents us from understanding how memory is allocated and deallocated. Unlike Go Language Memory Model Documentation Page that advices "If you must read the rest of this document to understand the behavior of your program, you are being too clever. Don't be clever.", I believe that we must be clever enough to make our system faster and safer, and sometimes it doesn't happen unless we dig deeper into what is going on. The potshot at Go in the conclusion seems counter-productive. The author is certainly taking the quote in a different spirit than it was intended.. Erlang and Go have functional overlap, sure. However the trade-offs between both the guarantees and operational realities of the two languages leaves each one best suited to a different domain. Thus it is a pointless waste of time to argue and criticize one or the other in this manner. While I may personally appreciate Go's opinionated-ness, it seems to lead to excessive amounts of conflict and drama. I wonder if it's an overall win or loss. On one hand, the controversy sparks interest which helps spread Go. On the other hand, it alienates many folks who may otherwise be open to getting involved. Food for thought. TLDR: It looks rather silly to compare languages with very different design goals.

    实用技巧:用 erlang:garbage_collect/1 主动控制回收时机以降低停顿影响。

    对于生命周期很长、又在意 GC 停顿的进程,有个实用技巧:调用 erlang:garbage_collect(pid)。如果你有实时性要求,往往可以通过自己选择在进程生命周期的哪个时刻触发 GC,来把 GC 的影响降到最低。

    crazydoggers查看英文原文

    A useful trick for long lived processes where you also care about GC pauses is to run erlang:garbage_collect(pid) If you’ve got real time requirements you can often minimize GC impact by choosing when in the process lifecycle the GC occurs. https://erlang.org/doc/man/erlang.html#garbage_collect-1

    历次讨论

    同类还值得读

    1. 开源应用架构

      The Architecture of Open Source Applications

      《开源软件架构》(AOSA)是一本在线免费书,邀请知名开源项目的作者亲自剖析其内部设计,涵盖 SQLAlchemy、LLVM、Audacity、Apache、Bash 等系统。

      编程与软件工程上首页 9 次 · 2011–2024aosabook.org编辑精选
    2. 编程语言简史:简短、不完整且多半错误

      A Brief, Incomplete, and Mostly Wrong History of Programming Languages

      一篇以戏谑、故意不准确的方式回顾编程语言史的博客文章,用夸张轶事和讽刺定义串起 Lisp、C、C++、Java、JavaScript、PHP 等语言。

      编程与软件工程上首页 8 次 · 2009–2021james-iry.blogspot.com
    3. SQLite 是如何测试的

      How SQLite is tested

      SQLite 官方文档页,系统介绍 SQLite 的测试体系:多种测试方法(TCL 测试、模糊测试、回归测试、静态分析等)和海量测试用例,展示了这个小型开源项目如何靠极致测试获得…

      编程与软件工程上首页 8 次 · 2009–2025sqlite.org编辑精选
    4. 高级编程语言(2009)

      Advanced programming languages (2009)

      Matt Might 的经典文章,按用途推荐“高级编程语言”:如果追求就业就选主流语言,如果追求表达力、学术研究或创业,则推荐 Haskell、OCaml、Scala 等函数式语…

      编程与软件工程上首页 8 次 · 2009–2022matt.might.net
    5. 我的 Forth 与栈机器经历

      Yosefk - My history with Forth & stack machines

      作者以亲身经历回顾了使用 Forth 语言和栈式机器的历程:既赞叹其简洁优雅、代码量小、可自举的优点,也坦率指出栈操作在实际编程中的痛苦,以及 Forth 社区文化中的问题。

      编程与软件工程上首页 8 次 · 2010–2024yosefk.com编辑精选

    打赏支持

    打赏二维码

    觉得有用,请作者喝杯咖啡。

    WeChat

    关注向阳乔木

    微信公众号「向阳乔木推荐看」

    微信公众号「向阳乔木推荐看」二维码

    微信扫一扫;在微信里打开本页时,长按二维码识别。