加载失败
文章提出一种以函数体为依据的“按函数”调用约定/优化思路，试图减少调用开销并改进 Rust 的函数调用表现，但评论认为这更像是介于调用约定和内联之间的静态优化，而非可替代标准的 C ABI（C 语言的应用二进制接口）。讨论建立在编译器优化、符号可见性、LTO（Link Time Optimization，链接时优化）和内联成本等现实限制之上，也涉及 Rust 早期设计历史——例如 pre-1.0 时移除 green threads（绿色线程、用户态轻量线程）的决定及其对系统编程适用性的影响。评论者要求实证数据或编译器实践说明该方案的实际收益，并提醒不要把改变问题表述当作解决原问题的证据。读者被建议参考旧的 HN 讨论以了解该议题的演化与反驳要点。
多名评论者认为文章实际上在主张基于函数体进行逐函数优化──利用函数内部信息决定参数传递和寄存器使用——而非提出一个通用的 calling convention 或标准 C ABI。评论指出这更像是在调用约定与内联（inlining）之间的中间静态优化策略，而不是可跨模块、跨语言保证兼容性的 ABI。有人强调如果这种优化能带来显著收益，编译器可能已经在做类似工作；但现实中对于对外可见（externally visible）函数和内联成本的权衡限制了收益。整体态度是怀疑其把问题换了个表述后再宣称发现新方案的做法，建议不要把这种设计直接等同于替代 C ABI 的“调用约定”。
讨论进一步聚焦在编译器是否已经能做出类似的跨函数或跨模块优化。有人补充说在 LTO（Link Time Optimization，链接时优化）模式下，GCC 能进行跨模块的优化和内联，从而在一定程度上实现文章想要的效果，但这依赖于符号可见性和链接阶段的全局视角。评论暗示真实世界的限制包括外部可见性、代码膨胀与维护 ABI 稳定性的要求，这些都削弱了按函数微调调用约定的实用性。因此即便技术上可行，实际收益与成本需要更严格的度量和实证数据来支持。
有评论回顾 Rust 在 1.0 前移除了 green threads（绿色线程、用户态轻量线程）的历史决策，并认为这是 Rust 能直接与 C/C++ 在系统编程领域竞争的关键改变之一。讨论指出若保留强制运行时（如早期语言带有的 GC 和调度器），Rust 可能会更像 OCaml 或 Go，难以用于内核、固件等对运行时约束严格的场景。也有人提到现在通过 async runtimes（异步运行时）可以获得类似“可选绿色线程”的效果，但 Rust 本身没有自动 GC，引用计数（如 Arc）可被用作近似的内存管理手段。总体评论把语言设计的运行时依赖与调用/布局约定联系起来，认为运行时模型会强烈影响调用约定和代码布局的可接受设计空间。
[来源1] [来源2] [来源3] [来源4] [来源5] [来源6]
有评论直接质疑文章中的某个比喻或例子——“Diana 的 $89 洋装”——并请求解释该段落的含义或与主题的关联。这个问题表明部分读者觉得文章在用词或例子上存在让人困惑的“word games”，从而影响论证的清晰度和说服力。评论区并未在该处给出明确的释义，反映出文章写作风格在技术细节之外也成为讨论点。与此同时，还有人指出这类散乱的比喻可能是读者难以接受技术主张的一部分原因。
讨论中有人贴出此前的 Hacker News 话题链接，说明这篇文章及其观点并非孤立，而是对早前（2024 年 4 月）已有讨论的延续或重复。之前的线程包含大量评论（示例提到 137 条），表明关于 Rust 调用约定与 ABI 的辩论已经持续一段时间且多有争议。把新帖和旧帖串联起来有助于读者看到论点如何演化、哪些技术细节被反复质疑，以及社区对解决方案可行性的长期怀疑。总体上，评论提示读者参考历史讨论以获得更全面的证据链和反驳点。
calling convention（调用约定）: 规定函数如何传递参数、返回值、以及哪些寄存器由调用方或被调用方保存的规则，直接影响二进制兼容性和生成代码的开销。
C ABI（C 语言的应用二进制接口）: 定义跨编译单元和语言边界的调用约定、栈布局和寄存器使用等二进制约定，目标是保证不同编译器/模块间的兼容性与稳定性。
inlining（内联）: 编译器把被调用函数的代码直接插入调用点以消除调用开销，但会增加代码体积并影响可见性与编译时间，需权衡使用。
LTO（Link Time Optimization，链接时优化）: 在链接阶段进行跨模块分析和优化，允许对原本不可见或未内联的函数做整体优化或内联，从而实现跨文件的性能提升。
green threads（绿色线程 / 用户态线程）: 由语言运行时在用户态实现的轻量级线程或协作式调度，不依赖内核线程，常伴随运行时和垃圾回收策略，对系统级编程的适用性有重要影响。