{"id":43512,"date":"2024-06-04T14:58:13","date_gmt":"2024-06-04T18:58:13","guid":{"rendered":"https:\/\/mjtsai.com\/blog\/?p=43512"},"modified":"2026-02-02T14:27:59","modified_gmt":"2026-02-02T19:27:59","slug":"swift-at-10","status":"publish","type":"post","link":"https:\/\/mjtsai.com\/blog\/2024\/06\/04\/swift-at-10\/","title":{"rendered":"Swift at 10"},"content":{"rendered":"<p><a href=\"https:\/\/x.com\/BasicAppleGuy\/status\/1797333259514454382\">Basic Apple Guy<\/a>:<\/p>\n<blockquote cite=\"https:\/\/x.com\/BasicAppleGuy\/status\/1797333259514454382\">\n<p>10 Years Ago: Apple Announced Swift<\/p>\n<\/blockquote>\n\n<p><a href=\"https:\/\/mastodon.social\/@bwebster\/112550036275547377\">Brian Webster<\/a>:<\/p>\n<blockquote cite=\"https:\/\/mastodon.social\/@bwebster\/112550036275547377\">\n<p>10 year anniversary of Swift being announced at WWDC.<\/p>\n<\/blockquote>\n\n<p><a href=\"https:\/\/x.com\/clattner_llvm\/status\/1797344409627087321\">Chris Lattner<\/a>:<\/p>\n<blockquote cite=\"https:\/\/x.com\/clattner_llvm\/status\/1797344409627087321\"><p>Wow that&rsquo;s right. This was a big day and Swift has come a long way in the intervening decade: Congrats to everyone who has driven it forward to support such an amazing tech platform! &#x1F34E;&#x1F423;<\/p><\/blockquote>\n\n<p><a href=\"https:\/\/techhub.social\/@provuejim\/112550252539266273\">Jim Rea<\/a>:<\/p>\n<blockquote cite=\"https:\/\/techhub.social\/@provuejim\/112550252539266273\">\n<p>Interesting to go back and watch <a href=\"https:\/\/www.youtube.com\/watch?v=w87fOAG8fjk&amp;t=6260s\">this presentation<\/a> and see how Swift was originally promoted ten years ago. I would certainly say that Swift has been a huge success. On the other hand, I&rsquo;m personally still 100% programming in Objective-C and that continues to be an excellent development environment for building a sophisticated Mac app.<\/p>\n<\/blockquote>\n\n<p>My high-level take is that I generally like programming in Swift. I&rsquo;m <a href=\"https:\/\/mjtsai.com\/blog\/2023\/09\/24\/spamsieve-3-0\/\">rewriting<\/a> all my apps in it. But I&rsquo;m not sure it was the right thing to build. It&rsquo;s been such an immense effort both within Apple and for the community. This has been a <a href=\"https:\/\/mastodon.social\/@tolmasky\/111195011405830650\">distraction<\/a> from apps, frameworks, architecture, and documentation. So much mindshare has been taken up by the language itself, which should be just a tool for building the things that actually matter for our customers. It&rsquo;s come a <em>long<\/em> way, but the &ldquo;end&rdquo; is not yet in sight, as, even 10 years in, essential pieces are still being designed.<\/p>\n\n<p>I think it&rsquo;s quite possible that most of the parts that I, as an app developer, care about could have been had&mdash;sooner, and with greater tools speed and reliability&mdash;with a less ambitious project that <em>actually<\/em> tried to be <a href=\"https:\/\/mastodon.social\/@helge\/112549207653085462\">Objective-C without the C<\/a>, rather than a more static mega language that tries to replace C, C++, Objective-C, and Rust. The question is not how Swift 5.10 compares with Objective-C 2 but how it would compare with the hypothetical Objective-C <em>n<\/em> or Objective-Mojo that we could have had instead.<\/p>\n\n<p>It all comes down to the big vision of world domination and having a <a href=\"https:\/\/mastodon.social\/@colincornaby\/112549382164146255\">single language<\/a> from the bottom of the stack to the top. That would never have happened with a more <a href=\"https:\/\/mastodon.social\/@tolmasky\/111195071493204775\">pragmatic<\/a> evolution of Objective-C. If that eventually pans out, and Swift ends up being good at all levels of the stack, that would be a triumph. But, here in 2024, it still seems like a very long way away. In another 10 years, I suspect that XNU and WebKit will still be mostly C and C++, and the app frameworks will still have large amounts of Objective-C (or C++ in the case of SwiftUI).<\/p>\n\n<p>Now let&rsquo;s look at some specifics. The good:<\/p>\n<ul>\n<li><p>Overall, it&rsquo;s very ergonomic. I like the syntax. Basic type inference works well. Most of my code is more concise and readable. It&rsquo;s generally fun to program in, in the way that people often talk about scripting languages like Ruby and Python.<\/p><\/li>\n\n<li><p>Objective-C\/Cocoa interop works really well. I can access (almost) all of the old APIs, and they look and feel better than before. Bridging overhead is in most cases not an issue. Though it&rsquo;s not as flexible as migrating Objective-C code to ARC, it is possible to incrementally convert an existing project to Swift.<\/p><\/li>\n\n<li><p>Optionals are really great.<\/p><\/li>\n\n<li><p>I feel encouraged&mdash;because of the low ceremony&mdash;to do the right thing in terms of defining new types where they make sense and splitting up large classes. I don&rsquo;t have to maintain header files or write lots of boilerplate.<\/p><\/li>\n\n<li><p>Error handling works well, has low overhead, and manages to be clear without being burdensome.<\/p><\/li>\n\n<li><p>I like having more tools to structure and process my data: enums, tuples, structs, and pattern matching.<\/p><\/li>\n\n<li><p>Extensions on non-class types are really useful.<\/p><\/li>\n\n<li><p>I like being able to add implementations in protocol extensions, a limited but very pragmatic form of multiple inheritance.<\/p><\/li>\n\n<li><p>Performance of the compiled code can indeed be very swift. I&rsquo;m very happy with how <code>Data<\/code> lets me work at a high level but then optimizes down to very low overhead.<\/p><\/li>\n\n<li><p>The standard library is well designed and provides lots of useful functionality. They seem to have gotten Unicode strings right.<\/p><\/li>\n\n<li><p>I like <code>let<\/code>\/<code>var<\/code> and the overall way of handling value types and CoW collections.<\/p><\/li>\n\n<li><p>ARC mostly does the right thing and stays out of my way.<\/p><\/li>\n\n<li><p>Standalone <tt>.swift<\/tt> files work well as scripts.<\/p><\/li>\n\n<\/ul>\n\n<p>The bad:<\/p>\n<ul>\n<li><p>I had high hopes given how awesome Clang is, but the Swift compiler has been a disappointment. It&rsquo;s still slow, has terrible <a href=\"https:\/\/mastodon.social\/@helge\/112548261563145554\">error messages<\/a>, and is unreliable (crashes, spurious errors, frequent need to clear derived data and\/or relaunch Xcode). The compiled binaries are huge. It seems like in designing the type inference and optimizer plan that they made a bet on being bailed out by compiler tech that did not yet exist and mostly lost. Now it&rsquo;s too late to fix.<\/p><\/li>\n\n<li><p>The greatest potential was always for new Swift-only frameworks that would not have been possible otherwise. The jury is still out, but overall I do not like what I&rsquo;ve seen from SwiftUI. So far it seems less <a href=\"https:\/\/mastodon.social\/@schwa\/112538170654583382\">capable<\/a>, and the code seems brittle. It&rsquo;s not clear to me that the more static\/declarative approach is a good fit for UI stuff. SwiftData is also not encouraging in that it seems incredibly buggy and limited compared with Core Data, with only minor advantages due to being Swift. <a href=\"https:\/\/mastodon.social\/@helge\/112538083932686114\">Swift Concurrency<\/a> makes tradeoffs analogous to static vs. dynamic typing, and it&rsquo;s not yet clear whether this was the right decision.<\/p><\/li>\n\n<li><p>More generally, the Swift-forward API design&mdash;as with SwiftUI, Swift Regex, and format styles&mdash;seems to lead to systems that are harder to document and learn. There are lots of little interacting pieces, in scattered types and extensions. How do they all fit together? Where do you look to find a particular feature? There&rsquo;s been a lot of talk of progressive disclosure, but I&rsquo;m not sure that was actually achieved.<\/p><\/li>\n\n<li><p>The core selling point of more reliable code seems to have been realized in the micro but not in the macro. That is, any given class or function is probably more solid due to more precise typing and handling of nulls and errors. But I find the overall quality and reliability of Apple&rsquo;s apps, frameworks, and tools to be much <em>lower<\/em> now than before the introduction of Swift. I think this is mostly not <em>because<\/em> of Swift, but it&rsquo;s certainly not a win yet.<\/p><\/li>\n\n<li><p>The other main selling point of speed has been partially realized. <em>Some<\/em> stuff can be much faster than Objective-C. But in other cases there&rsquo;s <em>more<\/em> overhead for mandatory ARC and slower runtime checks. Sometimes code needs tuning to get rid of overhead from exclusivity checking and bridging. Overall, I would say that for most code there is not a huge difference either way. Port your old code because you like the language or the new APIs or you are rearchitecting, anyway, not to magically make the same old design faster.<\/p><\/li>\n\n<li><p>Playgrounds seemed like such a good idea, but they just don&rsquo;t work very well. I tend to do my exploratory work in test methods or small projects instead.<\/p><\/li>\n\n<li><p>I guess Swift has really advanced the state of the art with generics and protocols, but I still feel like they get in the way a lot and sometimes prevent me from being able to write what I want to write. Whereas general Swift code is more concise than the equivalent Objective-C, generics often create verbose messes. In some places, like with tests or integrating with Objective-C, you can&rsquo;t use generics at all, and in other places they can &ldquo;infect&rdquo; other layers of code that shouldn&rsquo;t really need to know about them. Basic generics, like with collections in the standard library, work well. The problems come when trying to do more &ldquo;dynamic&rdquo; stuff. Enhancements are making more and more things possible, but it&rsquo;s not easy or pretty.<\/p><\/li>\n\n<li><p><a href=\"https:\/\/mjtsai.com\/blog\/2019\/03\/27\/swift-5-released\/\">C interop<\/a> is confusing for those of us who only dabble in it occasionally. It&rsquo;s hard to know how to satisfy the compiler and even harder to know whether you&rsquo;ve done so in the right way. Part of this is surely C&rsquo;s fault, but the end result is that I don&rsquo;t want to rewrite my C code in Swift the way I do want to rewrite my Objective-C code in it.<\/p><\/li>\n\n<li><p>Swift has terrible <a href=\"https:\/\/twitter.com\/steipete\/status\/1414853296154677248\">handling<\/a> of <a href=\"https:\/\/x.com\/steipete\/status\/1279030286584553472\">deprecated<\/a> <a href=\"https:\/\/mastodon.social\/@chockenberry\/110890515845065228\">APIs<\/a> and, <a href=\"https:\/\/stackoverflow.com\/questions\/31540446\/how-to-silence-a-warning-in-swift\">in<\/a> <a href=\"https:\/\/twitter.com\/steipete\/status\/1178456406904786945\">general<\/a>, <a href=\"https:\/\/forums.swift.org\/t\/swift-should-allow-for-suppression-of-warnings-especially-those-that-come-from-objective-c\/19216\">suppression<\/a> <a href=\"https:\/\/x.com\/drewmccormack\/status\/1530118784727629824\">of<\/a> <a href=\"https:\/\/twitter.com\/reidmain\/status\/1279074601998397441\">warnings<\/a>.<\/p><\/li>\n\n<li><p>Namespaces feel half-baked.<\/p><\/li>\n\n<li><p>The <a href=\"https:\/\/iosdev.space\/@jonhendry\/112549626165404443\">complexity<\/a> of the language is ever-growing. I suppose that this was inevitable given the vision of being all things to all people and the need to give the compiler more static information so that it can verify what you&rsquo;re doing. If Objective-C was a small language with most of the important stuff in libraries and creative use of the runtime, Swift seems to put everything into the language itself. That means ideas can&rsquo;t come from anywhere; you need the technical and political chops to modify the compiler. Macros may improve this somewhat, though they also have a high barrier to entry.<\/p><\/li>\n\n<li><p>Auto-indent in Xcode seems to often do the wrong thing and isn&rsquo;t consistent between versions.<\/p><\/li>\n\n<li><p>Though Swift is clearly here to stay, and has attained a hip\/cool aura, it has not really had the hoped for uptake on the server and other non-Apple platforms.<\/p><\/li>\n<\/ul>\n\n<p>Previously:<\/p>\n<ul>\n<li><a href=\"https:\/\/mjtsai.com\/blog\/2024\/06\/04\/swiftdata-issues-in-macos-14-and-ios-17\/\">SwiftData Issues in macOS 14 and iOS 17<\/a><\/li>\n<li><a href=\"https:\/\/mjtsai.com\/blog\/2024\/05\/28\/dynamic-swift-predicates-in-macos-14-and-ios-17\/\">Dynamic Swift Predicates in macOS 14 and iOS 17<\/a><\/li>\n<li><a href=\"https:\/\/mjtsai.com\/blog\/2024\/05\/20\/swift-formatstyle-issues\/\">Swift FormatStyle Issues<\/a><\/li>\n<li><a href=\"https:\/\/mjtsai.com\/blog\/2024\/05\/10\/swift-proposal-objective-c-implementations-in-swift\/\">Swift Proposal: Objective-C Implementations in Swift<\/a><\/li>\n<li><a href=\"https:\/\/mjtsai.com\/blog\/2024\/05\/13\/xcode-15-4\/\">Xcode 15.4<\/a><\/li>\n<li><a href=\"https:\/\/mjtsai.com\/blog\/2024\/03\/11\/mac-dialog-in-auto-layout-vs-swiftui\/\">Mac Dialog in Auto Layout vs. SwiftUI<\/a><\/li>\n<li><a href=\"https:\/\/mjtsai.com\/blog\/2024\/03\/06\/swift-5-10\/\">Swift 5.10<\/a><\/li>\n<li><a href=\"https:\/\/mjtsai.com\/blog\/2023\/06\/12\/swiftdata\/\">SwiftData<\/a><\/li>\n<li><a href=\"https:\/\/mjtsai.com\/blog\/2023\/06\/02\/a-vision-for-using-c-from-swift\/\">A Vision for Using C++ From Swift<\/a><\/li>\n<li><a href=\"https:\/\/mjtsai.com\/blog\/2023\/05\/04\/mojo-programming-language\/\">Mojo Programming Language<\/a><\/li>\n<li><a href=\"https:\/\/mjtsai.com\/blog\/2023\/03\/17\/equality-in-swift-nsobject-subclasses-and-existentials\/\">Equality in Swift: NSObject, Subclasses, and Existentials<\/a><\/li>\n<li><a href=\"https:\/\/mjtsai.com\/blog\/2022\/06\/10\/swift-regex\/\">Swift Regex<\/a><\/li>\n<li><a href=\"https:\/\/mjtsai.com\/blog\/2022\/02\/22\/why-latter-left-the-swift-core-team\/\">Why Lattner Left the Swift Core Team<\/a><\/li>\n<li><a href=\"https:\/\/mjtsai.com\/blog\/2017\/01\/10\/chris-lattner-is-leaving-apple\/\">Chris Lattner Is Leaving Apple<\/a><\/li>\n<li><a href=\"https:\/\/mjtsai.com\/blog\/2014\/08\/18\/its-a-coup\/\">&ldquo;It&rsquo;s a Coup&rdquo;<\/a><\/li>\n<li><a href=\"https:\/\/mjtsai.com\/blog\/2014\/06\/04\/swift-links\/\">Swift Links<\/a><\/li>\n<\/ul>\n\n<p id=\"swift-at-10-update-2024-06-05\">Update (2024-06-05): See also: <a href=\"https:\/\/news.ycombinator.com\/item?id=40577911\">Hacker<\/a> <a href=\"https:\/\/news.ycombinator.com\/item?id=40581713\">News<\/a>.<\/p>\n\n<p><a href=\"https:\/\/layer8.space\/@teilweise\/112564802370134712\">Der Teilweise<\/a>:<\/p>\n<blockquote cite=\"https:\/\/layer8.space\/@teilweise\/112564802370134712\">\n<p>I&rsquo;d say what I like most about Swift is <code>Optional<\/code>. It is simple to use (especially since we got <code>if let x {}<\/code>) but gives one a warm feeling of not missing a nil.<\/p>\n<p>I 100% agree with each and every point in the bad list.<\/p>\n<p>Thinking of integer index for string, I&rsquo;d add a &ldquo;Stubbornness of the language guardians&rdquo; (phrased as &ldquo;Strict adherence to a clean design.&rdquo;) but I do not disagree with any of the points that are on the list.<\/p>\n<\/blockquote>\n\n<p><a href=\"https:\/\/x.com\/DamienPetrilli\/status\/1798253975604801910\">Damien Petrilli<\/a>:<\/p>\n<blockquote cite=\"https:\/\/x.com\/DamienPetrilli\/status\/1798253975604801910\"><p>I agree with Michael&rsquo;s take but to me the jury is still out on performance. It&rsquo;s clearly not competitive against C++.<\/p><\/blockquote>\n\n<p id=\"swift-at-10-update-2024-06-06\">Update (2024-06-06): See also: this <a href=\"https:\/\/mastodon.social\/@callionica\/112566661053923562\">Swift roast<\/a> and <a href=\"https:\/\/mas.to\/@Cykelero\/112568758114056285\">Nathan Manceaux-Panot<\/a>.<\/p>\n\n<p><a href=\"https:\/\/mastodon.social\/@tolmasky\/112566649141820756\">Francisco Tolmasky<\/a>:<\/p>\n<blockquote cite=\"https:\/\/mastodon.social\/@tolmasky\/112566649141820756\"><p>Swift is 10. I think at 7 or so I asked whether it felt it was as mature as ObjC\/Cocoa were at that age. I have a different question now. Where do we think Swift will be in 10 years? Will SwiftUI actually be capable of making a real Mac app? Or will we have a new language and\/or framework by then (20 years after Swift). Or will the Mac maybe just no longer exist by then, making this question moot?<\/p><\/blockquote>\n\n<p><a href=\"https:\/\/mastodon.social\/@iKyle\/112566475934971132\">Kyle Howells<\/a>:<\/p>\n<blockquote cite=\"https:\/\/mastodon.social\/@iKyle\/112566475934971132\"><p>There&rsquo;s 2 separate worlds of software development.<\/p><p>Building apps and user facing features.<\/p><p>Infrastructure and low level language design.<\/p><p>Swift concurrency (and a lot of Swift actually) just looks to me like evidence the language people being given far too much power, to run away with architecture astronauting projects.<\/p><\/blockquote>\n\n<p><a href=\"https:\/\/mastodon.social\/@troz\/112567894839765524\">Sarah Reichelt<\/a>:<\/p>\n<blockquote cite=\"https:\/\/mastodon.social\/@troz\/112567894839765524\">\n<p>Apple banning employees from developing their own apps has many negative effects and this is one of them.<\/p>\n<\/blockquote>\n\n<p><a href=\"https:\/\/mastodon.social\/@a_grebenyuk\/112566779975452474\">Alex Grebenyuk<\/a>:<\/p>\n<blockquote cite=\"https:\/\/mastodon.social\/@a_grebenyuk\/112566779975452474\">\n<p>The parts of Swift Concurrency that make me more productive when building apps are Async\/Await and maybe MainActor. Everything else is more work for little benefit, making it impractical.<\/p>\n<\/blockquote>\n\n<p id=\"swift-at-10-update-2024-06-07\">Update (2024-06-07): See also: <a href=\"https:\/\/old.reddit.com\/r\/programming\/comments\/1d9pe1j\/swift_at_10\/\">Reddit<\/a> and <a href=\"https:\/\/lobste.rs\/s\/iig2qs\/swift_at_10\">Lobsters<\/a>.<\/p>\n\n<p><a href=\"https:\/\/indieweb.social\/@stevestreza\/112571146627424003\">Steve Streza<\/a>:<\/p>\n<blockquote cite=\"https:\/\/indieweb.social\/@stevestreza\/112571146627424003\"><ul><li>The language delivered on core promises of better architecture, reduced crashes, more semantic types<\/li><li>The compiler is simply not adequate, it is barely functional and Apple has failed to invest in it sufficiently<\/li><li>Initiatives like WASM, server-side are exciting but hamstrung by the BDFL problem making it difficult to widen the ecosystem like in Rust, JavaScript, etc<\/li><li>Swift is still just &ldquo;the language for Apple dev&rdquo;, not a true C-level player like Rust<\/li><\/ul><\/blockquote>\n\n<p id=\"swift-at-10-update-2024-06-19\">Update (2024-06-19): <a href=\"https:\/\/mastodon.social\/@andyfinnell\/112621047104548168\">Andy Finnell<\/a>:<\/p>\n<blockquote cite=\"https:\/\/mastodon.social\/@andyfinnell\/112621047104548168\"><p>After 10 years of Swift, I still get compiler crashes on the regular. Xcode should at least make them actionable.<\/p><p>The compiler logs give instructions on how to file a bug report. It should just be a button I can press.<\/p><p>The compiler logs give zero indication of what&rsquo;s causing the crash. Xcode should have a command that runs a bisect over the file causing the crash until it&rsquo;s identified the offending lines. i.e. automate what a human would do by commenting out code.<\/p><\/blockquote>\n\n<p><a href=\"https:\/\/danielchasehooper.com\/posts\/why-swift-is-slow\/\">Daniel Hooper<\/a> (via <a href=\"https:\/\/news.ycombinator.com\/item?id=40661001\">Hacker News<\/a>):<\/p>\n<blockquote cite=\"https:\/\/danielchasehooper.com\/posts\/why-swift-is-slow\/\">\n<p>The Swift compiler can take an absurdly long time to compile expressions due to how types are inferred. Here&rsquo;s an explanation by the creator of Swift, Chris Lattner (from from his <a href=\"https:\/\/www.youtube.com\/watch?v=9ag0fPMmYPQ&amp;t=373s\">Mojo talk<\/a> [<a href=\"https:\/\/news.ycombinator.com\/item?id=40344837\">Hacker News<\/a>] and edited for clarity):<\/p><blockquote><p>My experience with Swift is we tried to make a really fancy bi-directional Hindley-Milner type checker and it&rsquo;s really great because you can have very beautiful minimal syntax but the problem is that A) compile times are really bad (particularly if you have complicated expressions) and B) the error messages are awful because now you have a global constraint system and when something goes wrong you have to infer what happened and the user can&rsquo;t know that something over there made it so something over here can&rsquo;t type check. In my experience it sounds great but it doesn&rsquo;t work super well.<\/p><\/blockquote>\n<p>[&#8230;]<\/p>\n<p>Swift 6 spends <em>42 seconds<\/em> on these 12 lines on an M1 Pro, only to spit out the notorious <code>error: the compiler is unable to type-check this expression in reasonable time; try breaking up the expression into distinct sub-expressions<\/code>. In the same amount of time, Clang can perform a clean build of my 59,000 line C project <em>38 times<\/em>. The Swift standard library has 17 overloads of <code>+<\/code> and 9 types adopting the <code>ExpressibleByStringLiteral<\/code> Protocol. This leads to an exponential combination of types and operators for the constraint solver to try.<\/p>\n<\/blockquote>\n\n<p>Even <a href=\"https:\/\/news.ycombinator.com\/item?id=40664513\">very short<\/a> snippets of code can trigger that error message, and compilation is also slow even for code that doesn&rsquo;t trigger it.<\/p>\n\n<p><a href=\"https:\/\/mastodon.social\/@stroughtonsmith\/112627765126478497\">Steve Troughton-Smith<\/a>:<\/p>\n<blockquote cite=\"https:\/\/mastodon.social\/@stroughtonsmith\/112627765126478497\"><p>People seem to be blissfully unaware of just how many resources go into making yearly OS updates happen. An anecdatapoint I&rsquo;ve heard thrown around is that the introduction of Swift into Apple&rsquo;s codebases more than doubled the time it takes to build all of Apple&rsquo;s OSes every night across their build farms, to the point where it now takes a day and a half to run a &lsquo;nightly&rsquo; build.<\/p><\/blockquote>\n\n<p><a href=\"https:\/\/x.com\/mpweiher\/status\/1801900026043515000\">Marcel Weiher<\/a>:<\/p>\n<blockquote cite=\"https:\/\/x.com\/mpweiher\/status\/1801900026043515000\">\n<p>Scrub a little earlier for more details on the problems with unpredictable performance.<\/p>\n<\/blockquote>\n\n<p><a href=\"https:\/\/mastodon.social\/@airspeedswift\/112581989142480137\">Ben Cohen<\/a>:<\/p>\n<blockquote cite=\"https:\/\/mastodon.social\/@airspeedswift\/112581989142480137\"><p>In May 2015 (so still in the Swift 1 days) I wrote a version of Peter Norvig&rsquo;s simple spelling correction generator. I happened to think of it again and thought I&rsquo;d try updating it to use all the improvements to Swift that have happened since then.<\/p><\/blockquote>\n\n<p>See also: <a href=\"https:\/\/old.reddit.com\/r\/programming\/comments\/1d9pe1j\/swift_at_10\/l7jeqbe\/\">Reddit<\/a>, <a href=\"https:\/\/daringfireball.net\/2024\/06\/the_talk_show_live_from_wwdc_2024\">The Talk Show<\/a>.<\/p>\n\n<p id=\"swift-at-10-update-2024-06-25\">Update (2024-06-25): See also: <a href=\"https:\/\/news.ycombinator.com\/item?id=40757411\">Hacker News<\/a>.<\/p>\n\n<p><a href=\"https:\/\/news.ycombinator.com\/item?id=40758404\">christophilus<\/a>:<\/p>\n<blockquote cite=\"https:\/\/news.ycombinator.com\/item?id=40758404\"><p>Ocaml is really fast to compile when I play with toy projects. It&rsquo;s a fairly simple type system compared to, say, TypeScript (I&rsquo;m not familiar enough with Swift to know how it compares to Ocaml in terms of type system complexity). I&rsquo;d prefer the simpler language if it means faster compilation.<\/p><\/blockquote>\n\n<p><a href=\"https:\/\/mastodon.social\/@helge\/112672863959463442\">Helge He&szlig;<\/a>:<\/p>\n<blockquote cite=\"https:\/\/mastodon.social\/@helge\/112672863959463442\">\n<p>My protobuf schema now needs ~30 seconds to compile on the Swift side.&#x23F3;<\/p>\n<\/blockquote>\n\n<p id=\"swift-at-10-update-2024-07-15\">Update (2024-07-15): <a href=\"https:\/\/www.youtube.com\/watch?v=ovYbgbrQ-v8&amp;t=1325s\">Chris Lattner<\/a> <a href=\"https:\/\/mastodon.social\/@krzyzanowskim\/112781210402350180\">discusses<\/a> progressive disclosure and Swift&rsquo;s complexity (via <a href=\"https:\/\/news.ycombinator.com\/item?id=40951979\">Hacker News<\/a>):<\/p>\n<blockquote cite=\"https:\/\/mastodon.social\/@krzyzanowskim\/112781210402350180\"><p>Swift, the original idea was factor complexity (&#8230;) massively failed, in my opinion (&#8230;) Swift has turned into a gigantic, super complicated bag of special cases, special syntax, special stuff<\/p><p>[&#8230;]<\/p><p>instead of fixing the core, what the team did, both when I was there, so partially my fault, but also subsequently, is they started adding all these special cases (&#8230;) a lot of this stuff got added under extreme time pressure to enable a feature like SwiftUI. And there&rsquo;s a bunch of stuff that feeds into that, as well as just the language gets more and more and more and more complicated.<\/p><\/blockquote>\n\n<p id=\"swift-at-10-update-2024-09-23\">Update (2024-09-23): <a href=\"https:\/\/x.com\/clattner_llvm\/status\/1831015874880512096\">Chris Lattner<\/a>:<\/p>\n<blockquote cite=\"https:\/\/x.com\/clattner_llvm\/status\/1831015874880512096\">\n<p>Great to <a href=\"https:\/\/www.youtube.com\/watch?v=ENviIxDTmUA\">dive into PL with Richard<\/a>, a legit language implementer! We explored a wide range of topics, incl lessons learned Swift=&gt;Mojo, how the structure of integer types + overflow is more complex than it might look, approaches to safety, acceleration of novel HW with Mojo etc.<\/p>\n<\/blockquote>\n<p>He talks about design decisions that led to Swift&rsquo;s type checking being slow and its error messages being unhelpful, and how Mojo avoids these problems. Mojo also has much more limited support for custom operators because the fancy system developed for Swift ended up not getting much use to justify the complexity.<\/p>\n\n<p><a href=\"https:\/\/ds9soft.com\/blog\/2024\/06\/the-liberating-experience-of-common-lisp\/\">Sebasti&aacute;n Ben&iacute;tez<\/a>:<\/p>\n<blockquote cite=\"https:\/\/ds9soft.com\/blog\/2024\/06\/the-liberating-experience-of-common-lisp\/\">\n<p>After using Swift for more than 5 years I can confidently say that it&rsquo;s getting worse with each addition, very similar to how C++ ended up being the monster it is. In comparison, Objective-C is simpler, somewhat minimalistic, and yet it did a great job for many Mac developers for a long time. I&rsquo;ve heard that Swift code leads to less crashes and better performance, but that&rsquo;s not what I&rsquo;ve experienced. Well written Objective-C code can be easy to understand as much as well written Swift code. But overly complex Swift code is much more difficult to maintain and understand than similar Objective-C code.<\/p>\n<\/blockquote>\n\n<p id=\"swift-at-10-update-2025-01-27\">Update (2025-01-27): <a href=\"https:\/\/mastodon.social\/@nicklockwood\/113895179364742200\">Nick Lockwood<\/a>:<\/p>\n<blockquote cite=\"https:\/\/mastodon.social\/@nicklockwood\/113895179364742200\"><p>I&rsquo;ve been writing code in Swift daily for 10 years and I still keep finding out that my mental model of how basic things work is completely wrong.<\/p><p>Take this example - I would have sworn that function overload resolution would have called the outer, <code>Int<\/code>-returning version of <code>foo()<\/code> here - but nope!<\/p><p>It turns out inner functions shadow outer ones regardless of argument names or types.<\/p><\/blockquote>\n\n<p id=\"swift-at-10-update-2025-02-12\">Update (2025-02-12): <a href=\"https:\/\/mastodon.social\/@helge\/113987277203440809\">Helge He&szlig;<\/a>:<\/p>\n<blockquote cite=\"https:\/\/mastodon.social\/@helge\/113987277203440809\"><p>I still think that SwiftUI itself isn&rsquo;t actually bad (it is awesome!), it just showcases how bad Swift is, when it is actually applied as intended.<\/p><p>There are a lot of people which go along w\/ Swift in UIKit\/AppKit contexts. That only really works because they are not using the advanced Swift features (generics etc) but are in some kind of Objective-C compat mode using ObjC libs.<\/p><p>SwiftUI isn&rsquo;t doing that, it actually <em>uses<\/em> Swift as intended. That is why it is so slow and painful to work with. &#x1F937;&#x200D;&#x2640;&#xFE0F;<\/p><\/blockquote>\n\n<p id=\"swift-at-10-update-2025-06-04\">Update (<a href=\"#swift-at-10-update-2025-06-04\">2025-06-04<\/a>): <a href=\"https:\/\/www.youtube.com\/watch?v=-1z4MYsCIIk\">Paul Hudson<\/a>:<\/p>\n<blockquote cite=\"https:\/\/www.youtube.com\/watch?v=-1z4MYsCIIk\"><p>In this video I talk about Swift&rsquo;s journey over a decade, along with my own journey with Swift in that same time.<\/p><\/blockquote>\n\n<p id=\"swift-at-10-update-2026-02-02\">Update (<a href=\"#swift-at-10-update-2026-02-02\">2026-02-02<\/a>): See also: <a href=\"https:\/\/news.ycombinator.com\/item?id=46841374\">Hacker News<\/a>.<\/p>","protected":false},"excerpt":{"rendered":"<p>Basic Apple Guy: 10 Years Ago: Apple Announced Swift Brian Webster: 10 year anniversary of Swift being announced at WWDC. Chris Lattner: Wow that&rsquo;s right. This was a big day and Swift has come a long way in the intervening decade: Congrats to everyone who has driven it forward to support such an amazing tech [&hellip;]<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"apple_news_api_created_at":"2024-06-04T18:58:17Z","apple_news_api_id":"5ef40495-49cb-4812-a95b-5b2d4ef084a8","apple_news_api_modified_at":"2026-02-02T19:28:07Z","apple_news_api_revision":"AAAAAAAAAAAAAAAAAAAAGQ==","apple_news_api_share_url":"https:\/\/apple.news\/AXvQElUnLSBKpW1stTvCEqA","apple_news_coverimage":0,"apple_news_coverimage_caption":"","apple_news_is_hidden":false,"apple_news_is_paid":false,"apple_news_is_preview":false,"apple_news_is_sponsored":false,"apple_news_maturity_rating":"","apple_news_metadata":"\"\"","apple_news_pullquote":"","apple_news_pullquote_position":"","apple_news_slug":"","apple_news_sections":"\"\"","apple_news_suppress_video_url":false,"apple_news_use_image_component":false,"footnotes":""},"categories":[4],"tags":[2070,55,69,255,109,31,2321,46,30,2385,54,71,2200,2080,901,2404,1812,1227,226],"class_list":["post-43512","post","type-post","status-publish","format-standard","hentry","category-programming-category","tag-anniversary","tag-arc","tag-cocoa","tag-compiler","tag-coredata","tag-ios","tag-ios-17","tag-languagedesign","tag-mac","tag-macos-14-sonoma","tag-objective-c","tag-programming","tag-swift-concurrency","tag-swift-playgrounds","tag-swift-programming-language","tag-swiftdata","tag-swiftui","tag-top-posts","tag-xcode"],"apple_news_notices":[],"_links":{"self":[{"href":"https:\/\/mjtsai.com\/blog\/wp-json\/wp\/v2\/posts\/43512","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/mjtsai.com\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/mjtsai.com\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/mjtsai.com\/blog\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/mjtsai.com\/blog\/wp-json\/wp\/v2\/comments?post=43512"}],"version-history":[{"count":29,"href":"https:\/\/mjtsai.com\/blog\/wp-json\/wp\/v2\/posts\/43512\/revisions"}],"predecessor-version":[{"id":50875,"href":"https:\/\/mjtsai.com\/blog\/wp-json\/wp\/v2\/posts\/43512\/revisions\/50875"}],"wp:attachment":[{"href":"https:\/\/mjtsai.com\/blog\/wp-json\/wp\/v2\/media?parent=43512"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/mjtsai.com\/blog\/wp-json\/wp\/v2\/categories?post=43512"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/mjtsai.com\/blog\/wp-json\/wp\/v2\/tags?post=43512"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}