good to see incredible stuff being shipped in Swift. Haven't used it since v3 though.
around 2015-17 - Swift could have easily dethroned Python.
it was simple enough - very fast - could plug into the C/C++ ecosystem. Hence all the numeric stuff people were doing in Python powered by C++ libraries could've been done with Swift.
the server ecosystem was starting to come to life, even supported by IBM.
I think the letdown was on the Apple side - they didn't bring in the community fast enough whether on marketing, or messaging - unfortunately Swift has remained largely an Apple ecosystem thing - with complexity now chasing C++.
> the server ecosystem was starting to come to life, even supported by IBM.
I was in college at the time and doing some odd freelance jobs to make some money. Unbeknownst to my clients I was writing their website backends in swift, using build packs on heroku to get them hosted.
It was a fun time for me and I love swift but I will admit last year I went ahead and rewrote an entire one of those sites in good ol typescript. I love swift but anything outside of the Apple ecosystem with it just seems like it hasn’t hit critical mass yet.
> around 2015-17 - Swift could have easily dethroned Python.
Why could it?
> it was simple enough - very fast - could plug into the C/C++ ecosystem. Hence all the numeric stuff people were doing in Python powered by C++ libraries could've been done with Swift.
Half a dozen languages fit this description.
> the server ecosystem was starting to come to life, even supported by IBM.
No, not at all. Kitura, Vapor (a fitting name) were just a toys that no serious player ever touched.
After that, and IBM losing interest, Apple did hire a few competent people (including contributors to Netty and Akka) to build the Swift Server Workgroup.
But I don't know why I'd pick Swift on the server when Rust is better in almost every dimension, with a thriving and more community-driven ecosystem.
I think it's not about that but about dogfooding Swift on the server. Apple uses Go, Java etc for a lot of its server components and refused to invest in hiring people that would extend the ecosystem for server Swift.
It certainly doesn't help, but among big tech, Apple is not the only company where teams are siloed and independent. Microsoft has people writing Java or Go instead of C# too.
I assume the server side usage is not zero, but not enough to reach a critical mass, you're probably right there.
I was enthusiastic about early TensorFlow in Swift efforts, sorry when the effort ended. My interest then flowed into early Mojo development for a while.
I wrote an eBook on Swift several ago but rarely update that book anymore. Count me as one of the many developers who for a while thought Swift would take over the world. At least Swift is a fun language to use, and now with LLM coding tools writing macOS/iOS/iPadOS apps is fairly easy.
funnily enough, I talked recently to someone working on the swift compiler (not an Apple employee) to make Swift functions differentiable. So its not all dead yet
Even today, with the fancy Swift 6.3, the experience of using Swift for anything other than apps for Apple platforms is very painful. There is also the question of trust - I don't think anyone would voluntarily introduce Apple "The Gatekeeper" in parts of their stack unless they're forced to do it.
Exactly true - they've created all these "working groups" of open source / volunteers to care for Android / Server / Wasm / ... all while being constraint "as an Apple product". Of course the end result is crappy
> could plug into the C/C++ ecosystem. Hence all the numeric stuff people were doing in Python powered by C++ libraries could've been done with Swift.
In 2015-2017 you could interop with C, C++ support wasn't added until very recently.
I do agree with you though and I am not sure what the exact reasoning is, but Swift is definitely an Apple ecosystem language despite the random efforts to gain traction elsewhere.
Just IMO, but... no. To me a "could have easily" requires n-1 things to have happened, and 1 thing not happening. Like, we "could have easily" had a nuclear exchange with the USSR, were it not for the ONE Russian guy who decided to wait for more evidence. https://en.wikipedia.org/wiki/1983_Soviet_nuclear_false_alar...
But even in '15-'17, there were too many people doing too many things with Python (the big shift to data orientation started in the mid/late 90's which paved the way to ML and massive python usage) by then.
The 'n' was large, and not nearly of the 'n' things were in Swift's favor then.
Lattner probably left because Apple didn't give the team any breathing room to properly implement the language. It was "we must have this feature yesterday". A lot of Swift is the equivalent of Javascrip's "we have 10 days to implement and ship it":
Swift has turned into a gigantic super complicated bag of special cases, special syntax, special stuff...
We had a ton of users, it had a ton of iternal technical debt... the whole team was behind, and instead of fixing the core, what the team did is they started adding all these special cases.
For this language to become default at Apple they had to be doing a massive amount of internal promotion - in other words they knew where it was going.
And then if that's the case, how were they not ready to solve the many problems that a big organization would run into? And all the schedule constraints that come with it?
Swift was feeling pretty exciting around ~v3. It was small and easy to learn, felt modern, and had solid interop with ObjC/C++.
...but then absolutely exploded in complexity. New features and syntax thrown in make it feel like C++. 10 ways of doing the same thing. I wish they'd kept the language simple and lean, and wrapped additional complexity as optional packages. It just feels like such a small amount of what the Swift language does actually needs to be part of the language.
I get this feeling with C#. I have been here since its release. I looked at Swift and then they moved very quickly at the beginning, so the book I had to teach me was out of date moments after it was printed. With all the complexity being thrown in, I stuck with C++ because at least it was only 1 language I had to keep track of (barely)!
I've been using C# since the first release in 2003/4 timeline?
Aside from a few high profile language features like LINQ, generics, `async/await`, the syntax has grown, but the key additions have made the language simpler to use and more terse. Tuples and destructuring for example. Spread operators for collections. Switch expressions and pattern matching. These are mostly syntactic affordances.
You don't have to use any of them; you can write C# exactly as you wrote it in 2003...if you want to. But I'm not sure why one would forgo the improved terseness of modern C#.
Next big language addition will be discriminated unions and even that is really "opt-in" if you want to use it.
The C# impl is still early and I think what will end up happening is that a lot of the boilerplate will end up being owned by source generators in the long term. C# team has a habit of "make it work, make it better". Whatever v1 gets released is some base capability that v2+ will end up making more terse. I'm happy and OK with that; I'd rather have ugly unions than no unions (yes, I already use OneOf)
I would remove result builders and all other uses of @attributes that change the semantics of the code (e.g property wrappers).
I would remove the distinction between value types and reference types at the type level. This has caused so many bugs in my code. This distinction should be made where the types are used not where they are defined.
I would remove everything related to concurrency from the language itself. The idea to let code execute on random threads without any explicit hint at the call site is ridiculous. It's far too complicated and error prone, which is why Swift designers had to radically change the defaults between Swift 6.0 and 6.2 and it's still a mess.
I would remove properties that are really functions (and of course property wrappers). I want to see at the call site whether I'm calling a function or accessing a variable.
I would probably remove async/await as well, but this is a broader debate beyond Swift.
And yes you absolutely do have to know and use all features that a language has, especially if it's a corporate language where features are introduced in order to support platform APIs.
I agree with you about result builders, silly feature that only exists for SwiftUI.
But a lot of what you said, except for the concurrency and property wrapper stuff, largely exists for Obj-C interop. The generated interface is more readable, and swift structs act like const C structs. It’s nice.
I'm not a Swift user, but I can tell you from C++ experience that this logic doesn't mitigate a complex programming language.
* If you're in a team (or reading code in a third-party repo) then you need to know whatever features are used in that code, even if they're not in "your" subset of the language.
* Different codebases using different subsets of the language can feel quite different, which is annoying even if you know all the features used in them.
* Even if you're writing code entirely on your own, you still end up needing to learn about more language features than you need to for your code in order that you can make an informed decision about what goes in "your" subset.
The absence of guard in Kotlin is one of those things that regularly trips me up when bouncing between it and Swift. Rather than Swift losing guard I’d prefer if Kotlin gained it.
Focusing on the keywords rather than the macros, I think the rest of them have legitimate use cases, though they're often misused, especially fileprivate.
You can take this approach in personal projects - with teams you need to decide on this and then on-board people into your use of the language. This does not work.
That number is unfairly exaggerated. The list includes ~40 internal keywords used only by language developers, plus dozens of tokens that would be called preprocessor directives, attributes, or annotations in other languages (e.g. `canImport` as in `#if canImport(...) #endif`; `available` and `deprecated` as in `@available(*, deprecated) func`).
Ah makes sense, personally I wouldn't consider reserved but unused words as keywords in the sense that you don't need to know them to read the language (even though they're keywords in some other technical sense). I was curious because I just tried counting number of keywords by language and it seemed surprisingly ambiguous/subjective/up to the language to say what's a "keyword" vs some type of core module. So my attempt (https://correctarity.com/keywords) probably has mistakes...
Eh, I don't think Swift would ever have dethroned Python. What pain point would it practically solve? I don't use Python often but I don't hear folks complaining about it much.
I do, though, think Swift had/has(?) a chance to dethrone Rust in the non-garbage collected space. Rust is incredibly powerful but sometimes you don't really need that complexity, you just need something that can compile cross-platform and maintain great performance. Before now I've written Rust projects that heavily use Rc<> just so I don't have to spend forever thinking about lifetimes, when I do that I think "I wish I could just use Swift for this" sometimes.
You're right, though, that Swift remains Apple's language and they don't have a lot of interest in non-Apple uses of it (e.g. Swift SDK for Android was only released late last year). They're much happier to bend the language in weird ways to create things like SwiftUI.
>"around 2015-17 - Swift could have easily dethroned Python."
NumPy, SciPy, Pandas, and Pytorch are what drove the mass adoption of Python over the last few years. No language feature could touch those libraries. I now know how the C++/Java people felt when JS started taking over. It's a nightmare to watch a joke language (literally; Python being named for Monty Python) become the default simply because of platform limitations.
No way something that compiles as slowly as Swift dethrones Python.
Edit: Plus Swift goes directly against the Zen of Python
> Explicit is better than implicit.
> Namespaces are one honking great idea -- let's do more of those!
coupled with shitty LSP support (even to this day) makes code even harder to understand than when you `import *` in Python.
Edit 2: To expand a little on how shitty the LSP support is for those who don't work with Swift: any trivial iOS or macOS project that builds fine in Xcode can have a bunch of SourceKit-LSP (the official Swift LSP) errors because it fails to resolve frameworks/libraries. The only sane way to work with Swift in VS Code or derivatives I've found is to turn off SourceKit diagnostics altogether and only keep swiftc diagnostics. And I have the swift-lsp plugin in Claude Code, there's a routine baseline of SourceKit errors ignored. So you have symbols without explicit namespaces, and the LSP simply can't resolve lots of them, so no lookup for you. Good luck.
That's funny. To me magic is implicit by definition and Python strikes me as a very magical language compared to something like Java that is way more explicit.
I _can_ do the same with Rust, doesn't mean it's "the language I reach for" for making e.g. a website. Because the tooling, ergonomics, hireability factor, etc. are still very harshly against it.
Same with Swift, but I'd call that more of a wasted opportunity because Apple, unlike Rust Foundation, has a mountain of money to make it happen, and yet they don't seem to care.
I don’t believe that’s true. Things are moving constantly, and in the right direction. Then again it would help if you cited particular grievances, because being a regular (cross-platform/cross-target) Swift user I am not sure what you are talking about…
I did not choose ClearSurgery’s example randomly. I was at a conference recently where the CTO was here, and he explicitly told us they were moving fast thanks to the Swift ecosystem. (I am not working there personally, nor am I affiliated.)
if they really want me to use this lang for everything, they'd have to 1. massively improve compilation speed, 2. get the ecosystem going (what's the correct way to spin up an http server like with express?) and 3. get rid of roughly 150 of the 200 keywords there are
especially w.r.t. the last one, of course everyone frets at huge breaking changes like this, so it won't happen, so people won't use it
I don't know why anyone would want to use Apple tools if they are not developing for Apple platforms. Apple barely maintains compatibility for their own platforms, using Swift on a non-Apple platform is setting yourself up for doubule pain.
Why are you interpreting this comment as "never receives updates"? It takes great effort to maintain API compatibility, some things aren't improved or are implicitly deprecated.
In a way it still is true. Swift works on Windows and Linux until it doesn't. It's taken until a couple years ago for other build systems to get swift support (which I suppose is the fault of said build system, but Swift taking so long to be cross-platform contributed to that), and even now it (still) doesn't quite work right. C interop is a mess requiring hacks to generate clang modules to actually get Swift to see them (and CMake for example provides no easy way of doing this, or last time I checked it didn't). Oh and Swift tends to take over the linker and compilation pipelines when you enable it, at least with CMake, because... Reasons? I honestly don't know why. It causes very weird errors when I integrated Swift code into my C++ project that were a pain to actually diagnose. I eventually got it working, but still, it wasn't simple or seamless.
No mention of compilation speed improvements? Very unfortunate. Compilation times slower than rust really hampers the devx of this otherwise decent language.
> Swift 6.3 introduces the @c attribute, which lets you expose Swift functions and enums to C code in your project. Annotating a function or enum with @c prompts Swift to include a corresponding declaration in the generated C header that you can include in your C/C++ files
Why did this take so long to be added? Such strange priorities. Adding an entire C++ compiler for C++ interoperability before adding... C exports. Bizarre.
C++ interop got attention because it helps Apple absorb low-level codebases that already moved past pure C. Exporting Swift to plain C mostly means more DIY FFI spaghetti.
Once enums, ownership rules, and nullability cross that boundary, the generated header stops looking like a neat bridge and starts looking like one more place for ABI bugs to hide. Closures make it weirder fast, because now your error handling and calling conventions can drift just enough to produce the kind of bug that wastes a whole afernoon.
It would be really nice if instead we could just do one style of development and then ship a set of libraries as used to work for OpenSTEP (which was why it had "OPEN" in the name).
The language doesn’t really matter. The underlying SDK/framework is where the action is at.
However, I suspect that we may not be too far off, from LLMs being the true cross-platform system. You feed the same requirements, with different targets, and it generates full native apps.
Fully agree. I have zero Swift knowledge and currently use LLM to write a native app. I'm well aware of the SDKs and concepts in iOS development, so even if something's wrong I got intuition where to look and how to make the LLM fix it.
Interestingly, Kotlin has a pretty solid cross-platform story.
I'd pick it over Swift if targeting Android since it can build and run in the JVM as well as natively -- and has Swift/ObjC interop. Its also very usable on the server if you wanted to, since you can use it in place of Java and tap into the very mature JVM ecosystem. If that's what you're into.
And I have a lot more faith in JetBrains being good stewards of the language rather than Apple, who have a weird collection of priorities.
Kotlin is practically a no-brainer when you have JVM at your finger tips, versus something like Swift which is comparatively young.
I tried to use Vapor with Swift recently and struggled to get something working because the documentation looked comprehensive, but had a lot of gaps. I ended up throwing it out because I didn't have the time to dig through the source to understand how to do something, when I could use a mature framework in any other language instead.
The promise is there but I'm just not ready to invest. My youthful days of unbounded curiosity are coming to an end and these days I just want to get something done without much faff.
Mind you, Kotlin/Native (which is what gets used when you're compiling for iOS) doesn't have access to the JVM.
However, the Kotlin community is fundamentally all about open source, whereas Apple & iOS Devs have an allergy to it. The quality and quantity is already miles above the vast majority of what's in the Swift ecosystem. https://klibs.io has all the native compatible libs. And if you're targeting a platform where the JVM is available then yeah, it's massive. Compose makes UI tolerable compared to JWT too. Even large projects like Spring are Kotlin first nowadays.
JetBrains has monetary interest in promoting Kotlin beyond Android, there’s zero incentive to promote Swift as the language outside of iOS and Mac. They don’t need to capture minds of devs for them to develop for Apple devices.
This is going to be used much more than Swift for servers. Swift is a primarily client-side mobile language. It makes sense that you tap into reusing the logic.
I remember building dylibs in Swift for use in C programs, had to use @cdecl annotation iirc to achieve that, which was experimental. Good to see it's finally official
Whats the stdlib situation for swift in comparison to newish languages like go or rust. I know its not batteries included lke python - and doesnt have a massive dev ecosystem of helper libs seeming to be mostly tied to macOS/iOS operating system API/ABI.
There are still challenges with basics like compression, which tends to involve trawling Github for the least dubious toy project. Even Apple's Compression framework is missing important algorithms like ZSTD.
Another problem is the Apache Software Foundation don't seem to have any Swift maintainers, which means there really aren't any good pure Swift libraries for Arrow or Parquet.
There are some really good open-source libraries from Apple like Swift Collections or Swift Binary Parsing.
Re: module name selectors, wasn't this already possible, e.g. ModuleA.getValue()? Though I suppose this disambiguates if you also have a type called ModuleA.
I remember jumping into Swift from Obj-C in 2014 and using words like "beautiful" and "expressive" to describe syntax, and saying things like "you can tell what language someone is coming from by how they code in Swift". Now it's grown as it has - sometimes feels like season 4 of Lost. Makes me feel old too.
While the Flash guys had to use a native development environment and compile their stuff, I could just edit JavaScript in a plain text file and hit reload.
20 years later, and some of the same friends now swear by Swift. And have to use a native development environment and compile their stuff. While I still prefer to just edit JavaScript in a plain text file and hit reload.
good to see incredible stuff being shipped in Swift. Haven't used it since v3 though.
around 2015-17 - Swift could have easily dethroned Python.
it was simple enough - very fast - could plug into the C/C++ ecosystem. Hence all the numeric stuff people were doing in Python powered by C++ libraries could've been done with Swift.
the server ecosystem was starting to come to life, even supported by IBM.
I think the letdown was on the Apple side - they didn't bring in the community fast enough whether on marketing, or messaging - unfortunately Swift has remained largely an Apple ecosystem thing - with complexity now chasing C++.
> the server ecosystem was starting to come to life, even supported by IBM.
I was in college at the time and doing some odd freelance jobs to make some money. Unbeknownst to my clients I was writing their website backends in swift, using build packs on heroku to get them hosted.
It was a fun time for me and I love swift but I will admit last year I went ahead and rewrote an entire one of those sites in good ol typescript. I love swift but anything outside of the Apple ecosystem with it just seems like it hasn’t hit critical mass yet.
Python 3 barely managed to dethrone Python.
> around 2015-17 - Swift could have easily dethroned Python.
Why could it?
> it was simple enough - very fast - could plug into the C/C++ ecosystem. Hence all the numeric stuff people were doing in Python powered by C++ libraries could've been done with Swift.
Half a dozen languages fit this description.
> the server ecosystem was starting to come to life, even supported by IBM.
No, not at all. Kitura, Vapor (a fitting name) were just a toys that no serious player ever touched.
After that, and IBM losing interest, Apple did hire a few competent people (including contributors to Netty and Akka) to build the Swift Server Workgroup.
But I don't know why I'd pick Swift on the server when Rust is better in almost every dimension, with a thriving and more community-driven ecosystem.
I think it's not about that but about dogfooding Swift on the server. Apple uses Go, Java etc for a lot of its server components and refused to invest in hiring people that would extend the ecosystem for server Swift.
Thats the problem.
It certainly doesn't help, but among big tech, Apple is not the only company where teams are siloed and independent. Microsoft has people writing Java or Go instead of C# too.
I assume the server side usage is not zero, but not enough to reach a critical mass, you're probably right there.
> Haven't used it since v3 though.
Since 5.10 it's been worth picking back up if you're on MacOS.
True. Google was even thinking of switching TensorFlow from Python to Swift.
https://github.com/tensorflow/swift
That’s really because Chris Lattner was at Google Brain at the time. Don’t think it ever took off in meaningful ways
I was enthusiastic about early TensorFlow in Swift efforts, sorry when the effort ended. My interest then flowed into early Mojo development for a while.
I wrote an eBook on Swift several ago but rarely update that book anymore. Count me as one of the many developers who for a while thought Swift would take over the world. At least Swift is a fun language to use, and now with LLM coding tools writing macOS/iOS/iPadOS apps is fairly easy.
funnily enough, I talked recently to someone working on the swift compiler (not an Apple employee) to make Swift functions differentiable. So its not all dead yet
> Swift has remained largely an Apple ecosystem
Even today, with the fancy Swift 6.3, the experience of using Swift for anything other than apps for Apple platforms is very painful. There is also the question of trust - I don't think anyone would voluntarily introduce Apple "The Gatekeeper" in parts of their stack unless they're forced to do it.
You can use swift on the server but what for? You have a gigantic ecosystems in languages X,Y,Z.
Even Apple does not use Swift on the server (AFAIK) so why would you?
> Even Apple does not use Swift
Exactly true - they've created all these "working groups" of open source / volunteers to care for Android / Server / Wasm / ... all while being constraint "as an Apple product". Of course the end result is crappy
Yea there is no incentive. Why use Swift on the server or in k8s when you have gazillion other languages that are performant and have the ecosystems.
> could plug into the C/C++ ecosystem. Hence all the numeric stuff people were doing in Python powered by C++ libraries could've been done with Swift.
In 2015-2017 you could interop with C, C++ support wasn't added until very recently.
I do agree with you though and I am not sure what the exact reasoning is, but Swift is definitely an Apple ecosystem language despite the random efforts to gain traction elsewhere.
> Swift could have easily dethroned Python.
Just IMO, but... no. To me a "could have easily" requires n-1 things to have happened, and 1 thing not happening. Like, we "could have easily" had a nuclear exchange with the USSR, were it not for the ONE Russian guy who decided to wait for more evidence. https://en.wikipedia.org/wiki/1983_Soviet_nuclear_false_alar...
But even in '15-'17, there were too many people doing too many things with Python (the big shift to data orientation started in the mid/late 90's which paved the way to ML and massive python usage) by then.
The 'n' was large, and not nearly of the 'n' things were in Swift's favor then.
Again, IMO.
Maybe Chris Lattner leaving and creating Mojo also didn’t help in that regard.
Swift for TensorFlow was a cool idea in that time …
Lattner probably left because Apple didn't give the team any breathing room to properly implement the language. It was "we must have this feature yesterday". A lot of Swift is the equivalent of Javascrip's "we have 10 days to implement and ship it":
https://youtu.be/ovYbgbrQ-v8?si=tAko6n88PmpWrzvO&t=1400
--- start quote ---
Swift has turned into a gigantic super complicated bag of special cases, special syntax, special stuff...
We had a ton of users, it had a ton of iternal technical debt... the whole team was behind, and instead of fixing the core, what the team did is they started adding all these special cases.
--- end quote ---
For this language to become default at Apple they had to be doing a massive amount of internal promotion - in other words they knew where it was going.
And then if that's the case, how were they not ready to solve the many problems that a big organization would run into? And all the schedule constraints that come with it?
To be fair, I think such a fate in inevitable for most languages after many years of changes and development.
That's my read too.
Swift was feeling pretty exciting around ~v3. It was small and easy to learn, felt modern, and had solid interop with ObjC/C++.
...but then absolutely exploded in complexity. New features and syntax thrown in make it feel like C++. 10 ways of doing the same thing. I wish they'd kept the language simple and lean, and wrapped additional complexity as optional packages. It just feels like such a small amount of what the Swift language does actually needs to be part of the language.
I get this feeling with C#. I have been here since its release. I looked at Swift and then they moved very quickly at the beginning, so the book I had to teach me was out of date moments after it was printed. With all the complexity being thrown in, I stuck with C++ because at least it was only 1 language I had to keep track of (barely)!
C# is the other direction, IMO.
I've been using C# since the first release in 2003/4 timeline?
Aside from a few high profile language features like LINQ, generics, `async/await`, the syntax has grown, but the key additions have made the language simpler to use and more terse. Tuples and destructuring for example. Spread operators for collections. Switch expressions and pattern matching. These are mostly syntactic affordances.
You don't have to use any of them; you can write C# exactly as you wrote it in 2003...if you want to. But I'm not sure why one would forgo the improved terseness of modern C#.
Next big language addition will be discriminated unions and even that is really "opt-in" if you want to use it.
> Next big language addition will be discriminated unions and even that is really "opt-in" if you want to use it.
I was excited for DU until I saw the most recent implementation reveal.
https://github.com/dotnet/csharplang/blob/main/proposals/uni...
Compared to the beauty of Swift:
https://docs.swift.org/swift-book/documentation/the-swift-pr...
The C# impl is still early and I think what will end up happening is that a lot of the boilerplate will end up being owned by source generators in the long term. C# team has a habit of "make it work, make it better". Whatever v1 gets released is some base capability that v2+ will end up making more terse. I'm happy and OK with that; I'd rather have ugly unions than no unions (yes, I already use OneOf)
Which keywords would you get rid of and why? You don't have to use all of them!
I would remove result builders and all other uses of @attributes that change the semantics of the code (e.g property wrappers).
I would remove the distinction between value types and reference types at the type level. This has caused so many bugs in my code. This distinction should be made where the types are used not where they are defined.
I would remove everything related to concurrency from the language itself. The idea to let code execute on random threads without any explicit hint at the call site is ridiculous. It's far too complicated and error prone, which is why Swift designers had to radically change the defaults between Swift 6.0 and 6.2 and it's still a mess.
I would remove properties that are really functions (and of course property wrappers). I want to see at the call site whether I'm calling a function or accessing a variable.
I would probably remove async/await as well, but this is a broader debate beyond Swift.
And yes you absolutely do have to know and use all features that a language has, especially if it's a corporate language where features are introduced in order to support platform APIs.
I agree with you about result builders, silly feature that only exists for SwiftUI.
But a lot of what you said, except for the concurrency and property wrapper stuff, largely exists for Obj-C interop. The generated interface is more readable, and swift structs act like const C structs. It’s nice.
I'm not a Swift user, but I can tell you from C++ experience that this logic doesn't mitigate a complex programming language.
* If you're in a team (or reading code in a third-party repo) then you need to know whatever features are used in that code, even if they're not in "your" subset of the language.
* Different codebases using different subsets of the language can feel quite different, which is annoying even if you know all the features used in them.
* Even if you're writing code entirely on your own, you still end up needing to learn about more language features than you need to for your code in order that you can make an informed decision about what goes in "your" subset.
But you have to know all of them to read other people's code.
To answer your question: I would immediately get rid of guard.
Also, I think the complexity and interplay of structs, classes, enums, protocols and now actors is staggering.
I'm surprised, guard is really useful, especially when unwrapping optionals. It's terse, explicit and encourages defensive programming.
internal should definitely go though.
The absence of guard in Kotlin is one of those things that regularly trips me up when bouncing between it and Swift. Rather than Swift losing guard I’d prefer if Kotlin gained it.
i would get rid of associatedtype, borrowing, consuming, deinit, extension, fileprivate, init, inout, internal, nonisolated, open, operator, precedencegroup, protocol, rethrows, subscript, typealias, #available, #colorLiteral, #else, #elseif, #endif, #fileLiteral, #if, #imageLiteral, #keyPath, #selector, #sourceLocation, #unavailable, associativity, convenience, didSet, dynamic, indirect, infix, lazy, left, mutating, nonmutating, postfix, precedence, prefix, right, unowned, weak, and willSet
It's true that internal is pointless.
Focusing on the keywords rather than the macros, I think the rest of them have legitimate use cases, though they're often misused, especially fileprivate.
You can take this approach in personal projects - with teams you need to decide on this and then on-board people into your use of the language. This does not work.
Yes exactly, it’s easy to blame a language when really it’s a team problem.
1. You don't have to use it all, but someone will. And there are over 200 keywords in the language: https://x.com/jacobtechtavern/status/1841251621004538183
2. On top of that many of the features in the language exist not because they were carefully designed, but because they were rushed: https://news.ycombinator.com/item?id=47529006
That number is unfairly exaggerated. The list includes ~40 internal keywords used only by language developers, plus dozens of tokens that would be called preprocessor directives, attributes, or annotations in other languages (e.g. `canImport` as in `#if canImport(...) #endif`; `available` and `deprecated` as in `@available(*, deprecated) func`).
are there actually 217 keywords? Just wondering what the difference between that file and https://docs.swift.org/swift-book/documentation/the-swift-pr... (a mere 102 keywords)
That file is the compiler's list of reserved keywords, so some of them may not have been added to docs, or they're experimental/internal/...
I'm not 100% sure but I think the swift doc you linked is missing at least a dozen keywords so the truth probably lies in the middle
Ah makes sense, personally I wouldn't consider reserved but unused words as keywords in the sense that you don't need to know them to read the language (even though they're keywords in some other technical sense). I was curious because I just tried counting number of keywords by language and it seemed surprisingly ambiguous/subjective/up to the language to say what's a "keyword" vs some type of core module. So my attempt (https://correctarity.com/keywords) probably has mistakes...
Eh, I don't think Swift would ever have dethroned Python. What pain point would it practically solve? I don't use Python often but I don't hear folks complaining about it much.
I do, though, think Swift had/has(?) a chance to dethrone Rust in the non-garbage collected space. Rust is incredibly powerful but sometimes you don't really need that complexity, you just need something that can compile cross-platform and maintain great performance. Before now I've written Rust projects that heavily use Rc<> just so I don't have to spend forever thinking about lifetimes, when I do that I think "I wish I could just use Swift for this" sometimes.
You're right, though, that Swift remains Apple's language and they don't have a lot of interest in non-Apple uses of it (e.g. Swift SDK for Android was only released late last year). They're much happier to bend the language in weird ways to create things like SwiftUI.
> just need something that can compile cross-platform and maintain great performance.
I think Go has already taken that part of the cake.
Go is garbage collected, though. Rust and Swift still occupy a niche Go doesn't.
ARC is a form of garbage collection. Swift does not fare better than Go usually.
>"around 2015-17 - Swift could have easily dethroned Python."
NumPy, SciPy, Pandas, and Pytorch are what drove the mass adoption of Python over the last few years. No language feature could touch those libraries. I now know how the C++/Java people felt when JS started taking over. It's a nightmare to watch a joke language (literally; Python being named for Monty Python) become the default simply because of platform limitations.
> Swift could have easily dethroned Python
No way something that compiles as slowly as Swift dethrones Python.
Edit: Plus Swift goes directly against the Zen of Python
> Explicit is better than implicit.
> Namespaces are one honking great idea -- let's do more of those!
coupled with shitty LSP support (even to this day) makes code even harder to understand than when you `import *` in Python.
Edit 2: To expand a little on how shitty the LSP support is for those who don't work with Swift: any trivial iOS or macOS project that builds fine in Xcode can have a bunch of SourceKit-LSP (the official Swift LSP) errors because it fails to resolve frameworks/libraries. The only sane way to work with Swift in VS Code or derivatives I've found is to turn off SourceKit diagnostics altogether and only keep swiftc diagnostics. And I have the swift-lsp plugin in Claude Code, there's a routine baseline of SourceKit errors ignored. So you have symbols without explicit namespaces, and the LSP simply can't resolve lots of them, so no lookup for you. Good luck.
>No way something that compiles as slowly as Swift dethrones Python.
This must have pushed Chris Lattner towards making Mojo both interpreted and compiled at the same time.
> Explicit is better than implicit.
That's funny. To me magic is implicit by definition and Python strikes me as a very magical language compared to something like Java that is way more explicit.
Until you start using frameworks like Spring and then everything is so painfully magic that no one knows how the program actually runs.
Magical language how? And you should see what reflection based Java monstrosities do in the background.
Plus Swift goes directly against the Zen of Python
The Zen of Python is how we got crap like argparse where arguments are placed in the namespace instead of a dict.
I wouldn't change that in any way. I'd might make it an Arguments class, but I wound't make what parser returns merely a dict.
Yeah, so what happens when you have an option with a '-' in it that isn't valid as a variable name (I know what happens). It's just stupid.
Dethroned Python? The Apple language, seriously. Where is numpy for swift?
> Swift is designed to be the language you reach for at every layer of the software stack.
It's a nice lang for sure, but this will never be true with the way things are. Such wasted opportunity by Apple.
How so? I can indeed target every layer of the software stack using Swift, today.
E.g. ClearSurgery[0] is written fully in Swift, including the real-time components running on the Linux boxes.
[0] https://clearsurgery.vision
I _can_ do the same with Rust, doesn't mean it's "the language I reach for" for making e.g. a website. Because the tooling, ergonomics, hireability factor, etc. are still very harshly against it.
Same with Swift, but I'd call that more of a wasted opportunity because Apple, unlike Rust Foundation, has a mountain of money to make it happen, and yet they don't seem to care.
> They don't seem to care.
I don’t believe that’s true. Things are moving constantly, and in the right direction. Then again it would help if you cited particular grievances, because being a regular (cross-platform/cross-target) Swift user I am not sure what you are talking about…
I did not choose ClearSurgery’s example randomly. I was at a conference recently where the CTO was here, and he explicitly told us they were moving fast thanks to the Swift ecosystem. (I am not working there personally, nor am I affiliated.)
they seem to be adding more and more keywords
if they really want me to use this lang for everything, they'd have to 1. massively improve compilation speed, 2. get the ecosystem going (what's the correct way to spin up an http server like with express?) and 3. get rid of roughly 150 of the 200 keywords there are
especially w.r.t. the last one, of course everyone frets at huge breaking changes like this, so it won't happen, so people won't use it
> I don’t believe that’s true. Things are moving constantly, and in the right direction.
Hah! I'll use that argument if I ever get PIP'd.
No but seriously, constantly moving doesn't mean fast enough. Swift took took long to have cross-platform support.
And it is still uberslow to compile. To the point of language servers giving up on analyzing it and timeout.
I don't know why anyone would want to use Apple tools if they are not developing for Apple platforms. Apple barely maintains compatibility for their own platforms, using Swift on a non-Apple platform is setting yourself up for doubule pain.
> Apple barely maintains compatibility for their own platforms...
You're commenting on a post about an update... that they apparently don't do? What?
Why are you interpreting this comment as "never receives updates"? It takes great effort to maintain API compatibility, some things aren't improved or are implicitly deprecated.
That was true for Swift 2, maybe a little for Swift 3, but it has not been true since a long time now…
In a way it still is true. Swift works on Windows and Linux until it doesn't. It's taken until a couple years ago for other build systems to get swift support (which I suppose is the fault of said build system, but Swift taking so long to be cross-platform contributed to that), and even now it (still) doesn't quite work right. C interop is a mess requiring hacks to generate clang modules to actually get Swift to see them (and CMake for example provides no easy way of doing this, or last time I checked it didn't). Oh and Swift tends to take over the linker and compilation pipelines when you enable it, at least with CMake, because... Reasons? I honestly don't know why. It causes very weird errors when I integrated Swift code into my C++ project that were a pain to actually diagnose. I eventually got it working, but still, it wasn't simple or seamless.
If cross platform support took so long, it's a major red flag.
Plus Swift is arguably too unnecessarily complex now.
And there's Rust/Zig so why use Swift for low level?
https://github.com/finagolfin/swift-android-sdk
At least 6 years old.
That it's designed for a thing and becoming the go-to choice for that thing can be far apart indeed.
It just works. One language. Many platforms. Incredible performance.
With a simple tooling. No ugly script. Everything is naturally integrated.
> No ugly script
What’s that supposed to mean?
Isn’t that Go?
Go and “simple tooling” don’t really belong in the same sentence. Powerful tooling, sure, but simple?
Would be helpful if you elaborate which part is not simple.
Coming from C++ and JavaScript, there aren't many languages that can claim to have "simpler" tooling than Go.
The typical Apple sales pitch. Forgive me for assuming it’s only surface level.
No mention of compilation speed improvements? Very unfortunate. Compilation times slower than rust really hampers the devx of this otherwise decent language.
> Swift 6.3 introduces the @c attribute, which lets you expose Swift functions and enums to C code in your project. Annotating a function or enum with @c prompts Swift to include a corresponding declaration in the generated C header that you can include in your C/C++ files
Why did this take so long to be added? Such strange priorities. Adding an entire C++ compiler for C++ interoperability before adding... C exports. Bizarre.
C++ interop got attention because it helps Apple absorb low-level codebases that already moved past pure C. Exporting Swift to plain C mostly means more DIY FFI spaghetti.
Once enums, ownership rules, and nullability cross that boundary, the generated header stops looking like a neat bridge and starts looking like one more place for ABI bugs to hide. Closures make it weirder fast, because now your error handling and calling conventions can drift just enough to produce the kind of bug that wastes a whole afernoon.
They had it earlier, as an underscored attribute.
You already had ObjC export so it was arguably low priority given the crossover
it's been there for a while as an experimental feature. I used it in a project
> Swift 6.3 includes the first official release of the Swift SDK for Android.
Anything similar for Windows and Linux?
For Windows there's a 5 year old blog post: https://www.swift.org/blog/swift-on-windows/
For Linux there's a guide for GNOME: https://www.swift.org/blog/adwaita-swift/
It would be really nice if instead we could just do one style of development and then ship a set of libraries as used to work for OpenSTEP (which was why it had "OPEN" in the name).
Swift on Windows has been part of the official distribution for a long time:
https://www.swift.org/install/windows/
The blog posts seems to place higher on search results --- maybe arrange to have it edited?
Which GUI toolkit(s) does that install support?
None, you’re on your own. The Browser Company made bindings for WinRT so you can use WinUI imperatively but it’s non trivial to set up.
I haven't shipped any Swift on Windows myself but I have a production Linux system using Swift (and C++ interop) and it works really well
That is going to be used... less than Swift for the servers
I don't know. Could be nice for those developers that prioritize iOS and now they could keep writing Swift also for Android.
Is it gonna be what you primarily use if you wanna write an Android app? Probably not.
Is it gonna displace react Native? Probably not. Is it gonna reach the levels of flutter? Maybe.
The language doesn’t really matter. The underlying SDK/framework is where the action is at.
However, I suspect that we may not be too far off, from LLMs being the true cross-platform system. You feed the same requirements, with different targets, and it generates full native apps.
> from LLMs being the true cross-platform system
Fully agree. I have zero Swift knowledge and currently use LLM to write a native app. I'm well aware of the SDKs and concepts in iOS development, so even if something's wrong I got intuition where to look and how to make the LLM fix it.
I’m not sure about that but porting libraries from one language to another seems well within their capabilities.
I don't think we're there yet, but I suspect that it's just a matter of time.
It would certainly be quite profitable. Money tends to drive progress.
> Is it gonna reach the levels of flutter? Maybe.
Never. It won’t even reach Compose level, Flutter level DX is unattainable for any framework outside Flutter.
Interestingly, Kotlin has a pretty solid cross-platform story.
I'd pick it over Swift if targeting Android since it can build and run in the JVM as well as natively -- and has Swift/ObjC interop. Its also very usable on the server if you wanted to, since you can use it in place of Java and tap into the very mature JVM ecosystem. If that's what you're into.
And I have a lot more faith in JetBrains being good stewards of the language rather than Apple, who have a weird collection of priorities.
Kotlin is practically a no-brainer when you have JVM at your finger tips, versus something like Swift which is comparatively young.
I tried to use Vapor with Swift recently and struggled to get something working because the documentation looked comprehensive, but had a lot of gaps. I ended up throwing it out because I didn't have the time to dig through the source to understand how to do something, when I could use a mature framework in any other language instead.
The promise is there but I'm just not ready to invest. My youthful days of unbounded curiosity are coming to an end and these days I just want to get something done without much faff.
Mind you, Kotlin/Native (which is what gets used when you're compiling for iOS) doesn't have access to the JVM.
However, the Kotlin community is fundamentally all about open source, whereas Apple & iOS Devs have an allergy to it. The quality and quantity is already miles above the vast majority of what's in the Swift ecosystem. https://klibs.io has all the native compatible libs. And if you're targeting a platform where the JVM is available then yeah, it's massive. Compose makes UI tolerable compared to JWT too. Even large projects like Spring are Kotlin first nowadays.
JetBrains has monetary interest in promoting Kotlin beyond Android, there’s zero incentive to promote Swift as the language outside of iOS and Mac. They don’t need to capture minds of devs for them to develop for Apple devices.
This is going to be used much more than Swift for servers. Swift is a primarily client-side mobile language. It makes sense that you tap into reusing the logic.
Just like .NET for linux... right? RIGHT?
I remember building dylibs in Swift for use in C programs, had to use @cdecl annotation iirc to achieve that, which was experimental. Good to see it's finally official
Swift lives only for macOS,iOS and besides those ecosystems does not have a solid and robust ecosystem to be used for anything else.
It's a shame but it for sure needs BigTech for it to be used anywhere else.
I still have hope Swift will break free like C# has. I hope one day something like Vapor or Kitura takes off.
If Swift was paired with smh like QT/GTK (could have replaced Vala) it would've been interesting.
smh?
In an effort to use swift for scripting, without the startup cost:
Swift Caching Compiler - https://github.com/jrz/tools
>nocopy for disabling copy-to-clipboard
Im curious how is this used?
Whats the stdlib situation for swift in comparison to newish languages like go or rust. I know its not batteries included lke python - and doesnt have a massive dev ecosystem of helper libs seeming to be mostly tied to macOS/iOS operating system API/ABI.
There are still challenges with basics like compression, which tends to involve trawling Github for the least dubious toy project. Even Apple's Compression framework is missing important algorithms like ZSTD.
Another problem is the Apache Software Foundation don't seem to have any Swift maintainers, which means there really aren't any good pure Swift libraries for Arrow or Parquet.
There are some really good open-source libraries from Apple like Swift Collections or Swift Binary Parsing.
A good source of available packages is the Swift Package Index. You can search here packages compatible with Linux[0].
[0] https://swiftpackageindex.com/search?query=platform%3Alinux
The Lord's language keeps getting better and better. The easier C interop could not have come at a more serendipitous time in my life.
Re: module name selectors, wasn't this already possible, e.g. ModuleA.getValue()? Though I suppose this disambiguates if you also have a type called ModuleA.
I want to like swift so bad
Lack of Mingw support keeps me away from it, and Odin.
> @c @specialized @inline(always) @export(implementation)
Reminds me of "In case you forgot, Swift has 217 keywords now" https://x.com/jacobtechtavern/status/1841251621004538183
I remember jumping into Swift from Obj-C in 2014 and using words like "beautiful" and "expressive" to describe syntax, and saying things like "you can tell what language someone is coming from by how they code in Swift". Now it's grown as it has - sometimes feels like season 4 of Lost. Makes me feel old too.
I'm glad Chris Lattner moved on and founded Mojo. It's such a cool language with ton of potential.
I was excited about it when it first came out, but haven't heard anything about it since.
Swift reminds me a lot of Flash back in the day.
While the Flash guys had to use a native development environment and compile their stuff, I could just edit JavaScript in a plain text file and hit reload.
20 years later, and some of the same friends now swear by Swift. And have to use a native development environment and compile their stuff. While I still prefer to just edit JavaScript in a plain text file and hit reload.
Given that Swift has one of the slowest compilation times, this is a valid criticism.