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 生成,可能有误。

    编程与软件工程kornel.ski

    Rust 与 C 的速度对比

    Speed of Rust vs. C

    2次上首页
    3年跨度
    699累计得分
    574条评论

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

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

    导读

    这篇文章从性能角度对比 Rust 与 C:作者指出两者编译到机器码的速度基本相当,但 Rust 在内存安全、所有权规则和默认内联等方面的设计,使其在保持同等性能的同时更易于写出安全、可并行的代码。文章还讨论了不透明指针、缓冲区复用、computed goto 等具体差异。

    为什么经久不衰:它以具体技术细节而非口号回应了“Rust 是否和 C 一样快”这一长期争论,多年后仍是理解两者性能权衡的经典参考。

    关键词 RustC性能对比内存安全

    HN 评论精选

    作者亲身经历佐证:Rust 的所有权模型让原本高风险的并行化变得轻松可靠。

    “最大的潜力在于可以放心地对大部分 Rust 代码并行化,而等价的 C 代码并行化风险太大。在这方面 Rust 比 C 成熟得多。”——是的。今天我把 3D 图形程序的两个部分整合了:一个刷新屏幕并允许移动视角,另一个向场景加载新对象。以前必须先加载完所有对象,图形窗口才能启动;今天我让这两个操作并行运行,窗口先显示天空和地面,随后几秒内场景可见地逐步加载,且不降低帧率。这只改了大约 10 行 Rust 代码,第一次编译就跑通了。

    Animats查看英文原文

    "But the biggest potential is in ability to fearlessly parallelize majority of Rust code, even when the equivalent C code would be too risky to parallelize. In this aspect Rust is a much more mature language than C." Yes. Today, I integrated two parts of a 3D graphics program. One refreshes the screen and lets you move the viewpoint around. The other loads new objects into the scene. Until today, all the objects were loaded, then the graphics window went live. Today, I made those operations run in parallel, so the window comes up with just the sky and ground, and over the next few seconds, the scene loads, visibly, without reducing the frame rate. This took about 10 lines of code changes in Rust. It worked the first time it compiled.

    指出文中几处 Rust 优势其实源于动态/静态链接的惯例差异,而非语言本身。

    C 库对数据结构返回不透明指针,主要不是为了安全,而是为了维持 ABI 兼容性。Rust 不做动态链接,所以不必如此;Common Lisp 出于类似原因也这样做。至于跨编译单元内联:这同样是因为 C 惯用动态链接而 Rust 静态链接——如果用 LTO,C 也能跨模块内联。

    moonchild查看英文原文

    > C libraries typically return opaque pointers to their data structures, to hide implementation details and ensure there's only one copy of each instance of the struct. This costs heap allocations and pointer indirections. Rust's built-in privacy, unique ownership rules, and coding conventions let libraries expose their objects by value The primary reason c libraries do this is not for safety, but to maintain ABI compatibility. Rust eschews dynamic linking, which is why it doesn't bother. Common lisp, for instance, does the same thing as c, for similar reasons: the layout of structures may change, and existing code in the image has to be able to deal with it. > Rust by default can inline functions from the standard library, dependencies, and other compilation units. In C I'm sometimes reluctant to split files or use libraries, because it affects inlining This is again because c is conventionally dynamically linked, and rust statically linked. If you use LTO, cross-module inlining will happen.

    Zig 作者补充:computed goto 的效果可以通过简单循环写法让 LLVM 生成,无需专门语言特性。

    关于 computed goto:我最近在考虑是否给 Zig 加这个语言特性时深入研究过。虽然有些挑剔,但只要给 LLVM 一个足够简单的 while 循环 continue 表达式,它就能生成想要的机器码。所以我认为没必要专门提供 computed goto 特性。

    AndyKelley查看英文原文

    > computed goto I did a deep dive into this topic lately when exploring whether to add a language feature to zig for this purpose. I found that, although finnicky, LLVM is able to generate the desired machine code if you give it a simple enough while loop continue expression[1]. So I think it's reasonable to not have a computed goto language feature. More details here, with lots of fun godbolt links: https://github.com/ziglang/zig/issues/8220 [1]: https://godbolt.org/z/T3v881

    对“C 中缓冲区复用导致 Heartbleed 漏洞”的调侃。

    这让我笑了。(原文提到:在 C 里人们会想把为某用途分配的缓冲区挪作他用——这种技巧被称为 HEARTBLEED。)

    vlmutolo查看英文原文

    > "Clever" memory use is frowned upon in Rust. In C, anything goes. For example, in C I'd be tempted to reuse a buffer allocated for one purpose for another purpose later (a technique known as HEARTBLEED). This made me laugh

    历次讨论

    同类还值得读

    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

    关注向阳乔木

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

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

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