3 HN users recommended this talk3 months2023–2025score 3
Years with an HN recommendation, 2007–2026
Used as the primary source for Apple's stated plan to make Swift its successor to C++ and for how interop supports gradual transition.
John McCall of Apple's Swift team presents at CppNow 2023 on introducing a memory-safe successor language into large C++ code bases. He argues incremental improvement of C++ hits hard limits and explains Swift's C++ interoperability for gradual migration.
Java also compiles to native code on Android. Try to write an iOS application using only C and C++, instead of either Objective-C or Swift. "Swift was designed from the outset to be safer than C-based languages, and eliminates entire classes of unsafe code" -- [link] "Swift is a successor to the C, C++, and Objective-C languages. It includes low-level primitives such as types, flow control, and operators. It also provides object-oriented features such as classes, protocols, and generics, giving Cocoa and Cocoa Touch developers the performance and power they demand." -- [link] Some of the information related their Safe C dialect, [link] "2023 EuroLLVM - Keynote: “-fbounds-safety”: Enforcing bounds safety for production C code" [link] Finaly a recent gem from CppNow 2023, "Introducing a Memory-Safe Successor Language in Large C++ Code Bases" [this video]
Recent talk on Swift as a memory-safe successor to C++
I wonder what the author thinks about Swift’s new C++ interop story? Since the Swift compiler includes Clang, and can thus compile both your C++ and Swift into LLVM IR, without the need for an FFI later between the two, couldn’t this be the “Typescript for C++” that the author points out a space for? The Swift folks are very much thinking about Swift as a C++ successor that can be incrementally migrated to so I’m a bit surprised the author didn’t discuss it further — especially given Swift’s spiritual similarities to Rust. There’s a couple great talks on this by folks on the Swift team. John McCall at CppNow [this video] Konrad Malawski at StrangeLoop 2023 [link]
One of a couple great talks on Swift's C++ migration story
I'm not a (direct) user of the C++ interop, but everything I've heard about it has been quite positive. A few hopefully relevant resources, first a couple of videos: - "Introducing a Memory-Safe Successor Language in Large C++ Code Bases" (John McCall; CppNow 2023) [this video] - "Swift as C++ Successor in FoundationDB" (Konrad Malawski; Strange Loop 2023) [link] And then a series of blog posts by Doug Gregor: - "Swift for C++ Practitioners" [link] And finally: - "Mixing Swift and C++" (Swift.org) [link]
Listed among relevant resources on Swift C++ interop
As mentioned on the Swift talk at CppNow 2023, most of the C bindings are actually C++ with extern "C", and Apple would rather write less of them than more of. "CppNow 2023:Introducing a Memory-Safe Successor Language in Large C++ Code Bases" [this video]
Apple talk noting C bindings are mostly C++ with extern C
Don’t forget that this interoperability was put in place to support a specific engineering goal: to make it possible to slowly (over decades, probably) transition from 4 different languages (C, ObjC, C++, ObjC++) at every level of Apple’s stack towards a single successor language. Would you recommend they wait for some weird Java-esque 100% Pure implementation within the compiler itself before they can begin that work? The ideal you’re suggesting is actually made more possible by this work. One can imagine a Swift LLVM/Clang now. See: [this video]
Supports point that interop enables gradual transition to Swift
Apple have chosen to go all in on Swift for their first-party code, from the kernel to the libraries to the apps. Even things running on microcontrollers (but there’s no official or standard embedded Swift subset yet). It’s quite interesting actually that they’ve very intentionally focused on building transition layers so they can start gradually integrating Swift into C, Objective-C, and recently new support for C++ and Objective-C++. See this talk for the details on that - [this video] So don’t expect to see any Rust code from Apple, although of course they might ship third party things written in it at some point.
Details Apple's transition layers from C, ObjC and C++ to Swift
On the same subject, some talks from Apple folks, "Introducing a Memory-Safe Successor Language in Large C++ Code Bases" [this video] "Swift as C++ Successor in FoundationDB" [link]
In the recent talk about the new Swift to C++ bidirectional bridge [1] the presenter from Apple says that they intend to eventually use Swift for basically all their first-party code from embedded code on microcontrollers, to the kernel, libraries and apps. There will be language subsets for embedded and kernel development, not all features would be able to be used at the lower levels. 1. [this video]
Apple intends Swift for nearly all first-party code, with subsets for low levels
The raisons d'être between the CLR (and C#) and Swift are entirely different. Apple has explicitly set out to adopt Swift as a successor language to C, Objective-C, C++, and Objective-C++[0][1]. This stands in stark contrast to Microsoft's vision for the CLR, which was… to be a better Java, more or less? (Does anyone actually know what the .NET initiative was all about? Microsoft went absolutely ham on it in their branding, but the momentum unceremoniously fizzled out before Server 2003 went RTM.) That said, apropos .NET fitting into Windows, the work on Singularity[2] by MSR had a lasting impact. I'm told that there is in use a System C# dialect that generates native object code via a more production grade version of Bartok[3]. 0: [this video] 1: [link] . 2: [link] 3: [link]
Source that Apple adopts Swift as successor to C and C++
That is exactly their plan. Swift could always link into C applications, and they have recently come out with C++ interoperability [1] so things like WebKit etc. can start having parts re-written or new parts written from the start in Swift so they can gradually replace C and C++ codebases instead of trying to rewrite everything (which sucks because even for things much, much less complex than WebKit, you can have a team working for three years working on a replacement and it’ll have less features than the original had when you started). They’re even working on an embedded subset for embedded devices so things like microcontrollers like battery management, the Secure Enclave etc. can run it. 1. [this video]
Source for Apple's plan to incrementally replace C++ with Swift
They definitely have opened some things up, like a full C++ interface to Metal. I think the idea with this current effort is kind of the opposite though - not to encourage more use of C++, but to start writing new features of C++ projects in Swift (the presenter at the C++ Now 2023 talk [1] goes into this). I expect WebKit is a big target for them, I think they eventually want to replace all their C++ with Swift gradually (instead of trying to do ground-up rewrites, where you dedicate a team to doing that for years and you have a replacement at the end with fewer features than the old project). 1. [this video]
Presenter explains writing new C++ project features in Swift
Apple's John McCall makes a picture of where they are going with Swift in "Introducing a Memory-Safe Successor Language in Large C++ Code Bases" [this video]
Apple's John McCall makes a picture of where they are going with Swift in "Introducing a Memory-Safe Successor Language in Large C++ Code Bases" [this video]
There are zero references to Rust on that talk. It is all about C, C++, Objective-C and how Apple is replacing them with Swift. Rust isn't even shown on languages in use at Apple, [this video] As for tracking down the exact minutes of each Swift reference, maybe I will try to find some time on my side to prove me right on the Internet.
Talk has no Rust references; about replacing C and C++ with Swift
I wonder if they are thinking Swift - their C++ interop is still pretty new and has a way to mature, but it’s designed for exactly this [1] (we should expect Apple to start doing it with WebKit and other big C++ projects, even perhaps LLVM). 1. [this video]
Swift's C++ interop is designed for migrating C++ projects
John McCall (Swift team) gave a talk on Swift replacing C++ earlier this year: [this video] Selfishly I wish mixed C targets were a priority before C++ but I get why this was more important to them
Apple wants to migrate away from C++, including code in the kernel, so they need a safe, low-overhead language. Swift has originally been designed as an ObjC replacement, mostly for UI glue code, with conveniences more like a scripting language. So now they're working on making Swift support more low-level low-overhead code. [this video]
Apple wants to migrate from C++ to a safe low-overhead Swift
Yes, Apple themselves, apparently folks wanting Apple to use Rust don't read Apple's documentation or watch talks done by Apple compiler developers. > Swift was designed from the outset to be safer than C-based languages, and eliminates entire classes of unsafe code. -- [link] > Swift is a successor to the C, C++, and Objective-C languages. It includes low-level primitives such as types, flow control, and operators. It also provides object-oriented features such as classes, protocols, and generics. -- [link] "Introducing a Memory-Safe Successor Language in Large C++ Code Bases" [this video] "So we feel pretty strongly, obviously at Apple our sucessor language is Swift and I am here to talk about features of Swift, both to try to sell you on to it, but also to talk about the things we think are pretty necessary and the ways in which a programming language can support, you know, clear code, safer and more correct code." "Like I said before, Apple has always intended for Swift to be a sucessor language for all of our predecessors, from the top to the bottom of our stack, accessible to novices, powerful enough for experts, it is real a tall order. From [this video] to [this video] "Swift as C++ Successor in FoundationDB" [link]
Apple's own talk stating Swift is its successor language
Video list and Hacker News comment labels from HackerTube (prompted by @karpathy), released under ODC-By 1.0, built on the open-index/hacker-news archive. Hacker News data is provided by Y Combinator; comments remain the work of their authors. Video titles, channel names and thumbnails belong to their creators and are shown via YouTube. HackerTube Watch is an unofficial edition. Data export of 2026-10-31.
20 Hacker News comments
From the HN archive; up to 20 kept per video, favoring different commenters. Recommendations first.
Read more
Read more
Citations, criticism and jokes
Read more
Read more
Read more
Read more
Read more