HackerPapers

HN 二十年,最值得读的论文。

从 Hacker News 2006 年以来的全部投稿里,挑出链接本身就是论文的帖子:arXiv、期刊、会议论文、技术报告。每篇附中文标题,讨论最热的那些再加上中文导读和高赞评论翻译。

从必读开始
  • 8,000+篇被 HN 讨论过的论文

Essential

必读 30 篇

在论文库里看全部精选

编辑精选里 HN 讨论最热的 30 篇,每篇都有中文导读。不知道从哪读起,就从这里开始。

  1. 正在载入论文…

Archive

论文库

点柱子按年份筛选。注:源数据里 2023 年的帖子分数记录不全,2026 年尚未过完,这两年收录偏少。

难度
排序

    About

    这些论文是怎么挑出来的

    1. 01

      全量扫一遍

      读取 Hacker News 自 2006 年以来的全部 446 万条链接投稿,找出指向 arXiv、期刊、会议、技术报告和学术 PDF 的帖子。

    2. 02

      只留论文本身

      由 AI 逐条判断,剔除介绍论文的新闻、博客和幻灯片,同一篇论文的多次投稿合并计算,并统计它在评论区被引用的次数。

    3. 03

      写导读、译评论

      讨论最热的 1,500 篇配上中文导读,并精选、翻译 HN 高赞评论。导读由 AI 生成,可能有误,请以原文为准。

    编程语言与软件工程2015ds.cs.ut.ee

    Erlang 运行时系统与 Java 虚拟机的比较

    Comparison of Erlang Runtime System and Java Virtual Machine

    进阶 · 约 60 分钟读完前置知识:Erlang/BEAM 基础、JVM 基础、并发编程模型

    读论文 HN 讨论
    191HN 得分
    69条评论
    2次投稿

    导读

    这篇论文对比了 Erlang 运行时系统(ERTS/BEAM)与 Java 虚拟机(JVM)的设计差异,涵盖并发模型、调度、垃圾回收和内存管理等方面。核心观点是两者针对不同使用场景各有优势:BEAM 的进程模型和锁规避机制更优雅,而 HotSpot JIT 性能出色。

    HN 关注点:两种主流虚拟机在并发与运行时设计上的取舍,并延伸讨论 BEAM JIT、Project Loom 等后续进展。

    关键词 ErlangBEAMJVM并发模型

    HN 评论精选

    这几条评论里:支持 1 补充 2 亲历 1

    支持认为两个 VM 各有优势,但 BEAM 缺乏正式规范,且其并发模型更优雅

    这是一篇不错的对比。它让我好奇 BEAM JIT 的进展如何,也提醒我多么希望 BEAM 有一份正式规范——搞清楚字节码的细节比 JVM 费力得多,JVM 的一切都有明确文档。两个 VM 各有千秋:HotSpot JIT 令人惊叹,但我仍觉得 BEAM 的进程并发模型比 JVM 的更优雅,不过我只在 Erlang 里玩过,没有实战对比经验。

    jfaucett查看英文原文

    This was an decent comparison / contrast. It did make me wonder how they're coming along with the BEAM jit these days, I found this from a while back: http://www.erlang-factory.com/euc2014/frej-drejhammar It also reminded me how much I wish there was an actual specification for BEAM, finding out the details of the how the bytecodes work is an arduous task compared to the JVM where everything is explicitly stated. IMHO both VMs are excellent in their own right, the HotSpot JIT is incredible, but I still can't deny that I find the beam process model on concurrency more elegant than the JVM one, though in practice I've only toyed in erlang so I have no real-world grounds of comparison there. Does anyone by chance?

    亲历亲历者指出 Erlang 缺乏共享只读大数据结构支持,是针对特定场景优化的

    我在多语言环境中用了约两年 Erlang,网络消息基础设施基于 Erlang 协议构建,目前正在迁移。让我放弃它的一个主要原因是:无法在内存中放一个大型只读数据结构,让大量并行线程去分析或搜索它。虽然可以把数据塞进大字节二进制(大 bin 存在共享堆上)来变通实现,但处理非原生数据表示非常痛苦。Erlang 显然是为特定使用模式优化的,即使你处理的是函数式并行进程,它也可能与你的需求冲突。

    white-flame查看英文原文

    I was working with Erlang for about 2 years in a multi-language environment, and we based our networking messaging infrastructure on top of the Erlang protocol. It's still there, but we're migrating from it. One major thing that turned me off of the language for our particular project was that there was no way to have a large read-only data structure in RAM and sic a bunch of parallel threads to analyze or search it. It is hackable if you mash your data structure into a large byte binary, since large bins live on a shared heap, but it's a pain to deal with non-native representation for your data. It's very obvious that Erlang is optimized for a particular usage model, and even when you're dealing with a number of functional parallel processes, it might still clash with what you're doing.

    补充补充资料:Project Loom 和 ZGC 正在缩小 JVM 与 Erlang 的差距

    值得一提的是 Project Loom 旨在为 Java 添加续体和轻量级线程,由论文中提到的 Quasar 库作者 Ron Pressler 领导。另外 JDK 11 的 HotSpot 带来了新的并发非分代垃圾回收器 ZGC,平均暂停时间约 1 毫秒,目前仍是实验性特性,但以后大概率会转正。

    haglin查看英文原文

    It may be worth mentioning that project Loom [1][2] aims to add continuations and lightweight threading to Java. It is lead by Ron Pressler, the author of the Quasar library mentioned in the paper. Also, JDK 11 (Hotspot) comes with a new concurrent non-generational garbage collector (ZGC) [3] that has an average pause time of 1 ms [4]. It is still an experimental feature, but that will most likely change over time. [1] http://cr.openjdk.java.net/~rpressler/loom/Loom-Proposal.html [2] http://openjdk.java.net/projects/loom/ [3] http://openjdk.java.net/jeps/333 [4] https://youtu.be/tShc0dyFtgw?t=4m58s

    补充指出论文提出的问题正被 JVM 官方逐步解决,如 Fibers 和不可变数组

    这篇 2015 年论文提出的大多数问题,JVM 架构师在 2017 年的一次演讲中已承认,并正在着手解决。JVM 将引入 Fibers、不可变数组(可防止竞态条件)等重要升级,使 VM 更安全更快。显然这还需要数年才能就绪。

    cmjqol查看英文原文

    Most of the problems raised in this paper from 2015 have been acknowledge by the JVM architect in a 2017 talk[0] , and are know in the work of getting fixed. JVM is getting Fibers , Non Mutable Array (which would prevent from race condition) and other important upgrade to make the VM safer and faster. Obviously this will take years before being ready. [0]https://www.youtube.com/watch?v=OMk5KoUIOy4

    相关资源

    从这篇论文所有 HN 讨论帖的全部评论里整理出来的链接。

    自称作者的回复
    代码
    视频与演讲

    历次讨论

    同领域还值得读

    1. Google 的软件工程(2017)

      Software Engineering at Google (2017)

      介绍了 Google 的软件工程实践,包括其单一代码库(monorepo)、几乎全部开发在主干进行而非分支、代码审查、构建系统 Blaze、协议缓冲区等工具与流程,并讨论了频繁重…

      编程语言与软件工程2017 · 1,127 分 · 465 评 · 引用 15入门 · 约 45 分钟编辑精选
    2. Peter Naur:编程作为理论构建 (1985)

      Peter Naur – Programming as Theory Building (1985)

      Peter Naur 1985 年的经典论文《Programming as Theory Building》提出:编程的本质不是写代码或文档,而是在程序员头脑中构建对程序及其运行…

      编程语言与软件工程2016 · 629 分 · 74 评入门 · 约 45 分钟编辑精选
    3. SciPy 1.0:Python 科学计算的基础算法

      SciPy 1.0: fundamental algorithms for scientific computing in Python

      这篇发表于 Nature Methods 的论文介绍了 SciPy 1.0——Python 科学计算生态的基石库,涵盖其核心算法模块(优化、积分、插值、线性代数等)、软件架构与社…

      编程语言与软件工程2020 · 387 分 · 98 评入门 · 约 45 分钟编辑精选
    4. Lisp 的历史(1979)

      History of Lisp (1979)

      这是 Lisp 发明者 John McCarthy 于 1979 年为 HOPL(编程语言史)会议撰写的回顾文章,讲述 Lisp 的起源、设计动机与早期演进,文中也涉及 if 表…

      编程语言与软件工程2018 · 352 分 · 44 评入门 · 约 45 分钟编辑精选
    5. 使用 NumPy 进行数组编程

      Array Programming with NumPy

      这篇 Nature 文章介绍 NumPy 的数组编程模型及其在科学计算中的核心作用:以 ndarray 为中心,通过向量化操作让 Python 高效处理多维数组。

      编程语言与软件工程2020 · 318 分 · 134 评入门 · 约 40 分钟编辑精选

    打赏支持

    打赏二维码

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

    WeChat

    关注向阳乔木

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

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

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