Apple 正在招聘编译器开发者，以改进 Swift / C++ 互操作性

原文 ↗ Hacker News 讨论 ↗

Apple 为编译器前端工程师开出的新职位，凸显了其加深 Swift 与 C++ 互操作性的意图，以便把像 WebKit 和系统组件这样的大型既有 C++ 代码库逐步迁移到 Swift，而不是冒险进行一次性重写。评论者讨论 Apple 是否有长期目标要用 Swift 取代大部分 C/C++，包括性能关键、甚至可能是内核代码，同时权衡 Swift 在安全性和性能特性（ARC、move-only 类型）上的演进，与 C++ 的成熟度和 ABI 问题。这个职位还引发了关于薪酬、Cupertino 现场办公要求，以及语言和工具选择如何与 Apple 更广泛的软件质量和平台战略相互交织的讨论。

Apple 的策略：Swift–C++ 互操作性与迁移

  • 许多人认为，这次招聘是 Apple 长期计划的一部分：将大型 C++ 代码库（例如 WebKit，可能还有驱动程序和系统组件）逐步迁移到 Swift，而不是通过大规模重写来完成。
  • 这种互操作性被描述为一种方式：在现有的 C++ 项目内部用 Swift 编写新功能，并支持双向调用，同时尽量减少数据拷贝。
  • 也有人把这看作一种延续：Apple 过去曾公开淡化 C++ 的重要性，后来又接受了它（例如 Metal 的 C++ API），而现在正构建桥梁，让 Swift 能够有效地取而代之。

C++ 及其他语言在 Apple 平台上的地位

  • 关于 C++ 是否算“第一等公民”存在争论：
    • 一方认为：Apple 内部大量使用 C++（CoreAudio、守护进程、驱动程序），并且借助 Clang/Xcode 拥有稳定的 ABI 和强大的工具支持。
    • 另一方认为：平台 API、UI 框架和模板默认偏向 Swift/Objective‑C；你无法仅用 C++ 构建完整的 UI 应用。
  • Objective‑C 和 Swift 被描述为“托管式”的，因为它们具有运行时、ARC、反射和动态加载，但在术语上也存在分歧。

性能、安全性与语言取舍

  • 有人批评 C++ 过于复杂（模板、未定义行为），并认为投资应转向更安全的新语言（Swift、Rust 等）。
  • 也有人认为专家完全可以写出安全且高性能的 C++，而且其易用性和既有代码基础足以证明继续使用它的合理性。
  • 有人担心 Swift 能否达到 C/C++ 的性能，尤其是在 ARC 和引用计数方面；回应则指出，Swift 在可变所有权（move-only）类型和值语义方面仍在持续推进，以避免在关键路径上产生 ARC 开销。
  • 也有人怀疑，仅靠语言变更并不能解决死锁或糟糕算法之类的问题。

生态系统与替代方案（Rust、Kotlin、D）

  • 不少人建议新系统软件使用 Rust，因为它更安全；同时也指出 Apple 已在服务器端使用 Rust（但并不明确出现在已发布的客户端 OS 二进制中）。
  • D 和 Kotlin 被举为已经具备 C++/平台互操作能力的语言示例；Kotlin 因其强大的多平台支持而受到称赞，并有人推测它在通用用途上可能会超过 Swift。

软件质量与遗留代码

  • 多位评论者抱怨 macOS/iOS 的守护进程和应用占用高 CPU、UI 卡死以及操作缓慢，并将问题分别归因于 Objective‑C 的动态性、Swift 时代的质量下降，以及 Apple 每年一次的发布节奏。
  • 也有人表示几乎没遇到这些问题，并认为质量好坏取决于工作负载或数据规模（例如非常大的联系人列表）。

工作地点、薪酬与工作方式

  • 该职位要求在 Cupertino 现场办公，并提供签证担保。
  • 评论者指出，湾区高昂的房价与所列基础薪资之间存在差距；对总薪酬的常见估计约为基础薪资的 1.5–2 倍，但若没有双收入或超长通勤，仍很难在当地购房。
  • 有人批评 Apple 严格的现场办公政策，并担心 FAANG 的规范会推动整个行业回到办公室；也有人认为现场与远程本身就是一种合理的组织选择。

学习编译器与小众技能价值

  • 有人推荐给有志于成为编译器工程师的人一些资源：在线编译器课程、《Crafting Interpreters》、《Modern Compiler Implementation》、LLVM 的 Kaleidoscope 教程，以及小型 C 编译器（8cc/chibicc）作为学习材料。
  • 对于编译器岗位究竟有多“小众”、薪资溢价有多高，评论者意见不一；有人表示其相对普通软件岗位的溢价并不算大。