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.
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.
I'm sorry, that's absolutely bullshit. In fact, I wish we had left everyone who complained behind—the python community would have been happier and healthier for it. Absolute crybabies who wanted to be catered to without caring for how intractable the problems with python2 were—e.g. dealing with unicode was a royal pain in the ass, and the bytes/string divide completely fixed it. IMO, it was the best-executed breaking change I've ever witnessed in a language.
In comparison, e.g. Scala 2 -> Scala 3 was an absolute nightmare—it just didn't have the same vocal wailing from maintainers in the community (or, I suppose, a fraction of Python's popularity to begin with).
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.
Python's interactive interpreter makes it pretty useful as a shell, for iterative development, and crucially useful in a Jupyter notebook. I've also found CircuitPython's interpreter to be bonkers useful in prototyping embedded projects. (This, on top of the nice datascience, ML, and NN libraries).
Swift just wasn't doing the same things. And even if it did, Swift would compete with other languages that were understood as "a better Python", like Julia. Even then, Swift only came to Linux in 2016, Windows in 2020, and FreeBSD less than a year ago with WWDC 2025.
I think it doesn't help that the mid 2010s saw a burst of Cool and New languages announced or go mainstream. Go, Julia, Rust, TypeScript, Solidity, etc. along with Swift. I think most of us only have space to pick up one or two of these cool-and-new languages every few years.
> 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.
> 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.
It remains to be seen how much Mojo has learnt from that effort.
NVidia, AMD and Intel now have doubled now into giving Python GPU JITs, and Julia, the same capabilities as their CUDA, ROCm, and SYSCL offerings with C++.
With Julia and Python having their 1.0 long behind them.
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.
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.
> Even if the languages started tiny, complexity eventually grows on them.
And then of course the case that proves the opposite, Clojure. Sure, new ideas appear, but core language is more or less unchanged since introduced, rock solid and decades old projects still run just fine, although usually a bit faster.
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)!
>"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.
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.
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 spent last week (with Opus, of course) porting the xv6-riscv teaching operating system to a bunch of different languages. Zig, Nim, LISP, and Swift.
The improvements in embedded Swift have definitely made it one of the most enjoyable/productive languages to work on the OS. I feel like I can build useful abstractions that wrap raw memory access and make the userland code feel very neat.
On the other hand, the compilation times are SO bad, that I'm really focusing on the Nim port anyway.
It's been a long time since I came across Nim. I thought it was really interesting about 12 years ago. What made you land on Nim instead of any of the more obvious alternatives?
I was looking for something that allows easy access to direct memory, with a syntax thats a little easier to explain than C. Frankly, zig was not actually a real viable option based on that syntax requirement but I still wanted to explore it.
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 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.
Overall 6.3 ended up mostly about integration: stdlib, c/c++ (often driven by swift-java interop needs), and builds.
SPM (swift package manager) is slowly reaching out to take over xcode build features (e.g., resources most recently), and they have been inching and hacking their way to a new swift-build engine (now experimental) and "prebuilt" modules for the compiler/IDE macro support. Things Go Wrong all the time when trying to replace parts while driving, and there's very little visibility or control over the interactions between SPM and Xcode.
Conversely to integrations, endogenous language progress seems relatively quiet because there's a lot of behind-the-scenes work extending the initial blush of lifetime controls to iterators, stdlib types, etc. (never mind parameter packs). They're in year 4+ of building out the function-coloring of concurrency and isolation domains (6.2 had an "easy" mode that caused lots of problems), so adding year 2+ dataflow coloring of lifetimes is doubly complicating.
Naturally, diverse support for exciting new features results in quite a spread in the third-party library ecosystem of support for various language features. And now with AI entrepreneurs rewriting and porting any project that can score hits and kudos, the usual open-source authorities are losing their steam.
Finally, there's the baseline platform complexity of multiple OS and devices, physical and simulator debugging support, cloud CI...
So: that makes four dimensions of complexity. As a Swift developer you'd have to be very careful to stay on a working path as things shift underneath you.
No mention of compilation speed improvements? Very unfortunate. Compilation times slower than rust really hampers the devx of this otherwise decent language.
I tried Swift a few months ago in a project that made use of a bunch of bigger dependencies and I was instantly shocked by the compilation times. It's quite unimaginable to me using Swift for everyday work because of that. Especially when coming from the fast compile times of Go. But it's really unfortunate because I really enjoyed writing Swift because it feels like a very well made language. But iterating on some code and trying to get quick feedback is pure pain.
> 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).
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.
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
The noncopyable types improvements are the most underrated part of this release. Finally makes it practical to model unique ownership in Swift without fighting the compiler.
How is the toolchain? Does Swift Lint and Swift Format support the newest version. Honestly, the modern program language should have the built-in formatter and recommend lint rules. It is not just shipping a program language, it is a while ecosystem.
i worked with SwiftUI for about two years, and i think it's a really nice language. the compiler is very slow though.
but i think it's too coupled to Apple still. when i tried getting anything running on non-Apple, i had so much trouble i decided then to not even bother.
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.
As of very recently, the entire stdlib (i.e. "Foundation") is open source and available on all platforms Swift targets. For a while, the Linux builds had a much smaller/limited version of Foundation, but it's fully supported now.
did they ever add #define? bridging constants from the build system to swift with static NSString * const kConstValue = @XSTR(CONST_VALUE); is soooo annoying.
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.
Anyone else think the weather in the screen shot at the top of the page is a bit off? Snow in Lisbon (apparently it snowed there once in 2006), rain in Reykjavik at -1°. AI slop?
If you look at the code above, the temperature and weather are selected independently randomly. That alone is not indicative of AI-generated code; a human could write something similar for demo/learning purposes.
Swift truly is one of the languages of all time. I started a mobile app with the UI built in Swift and the core in Rust. The amount of implicit and hidden behaviour, magical fields being generated on objects because of certain annotations, the massive amount of @decorators...it's too much. I'm going to have an LLM generate the SwiftUI and touch as little of it as possible.
It's also strange because before I learned Swift, I heard about how beautiful it is but I find it much noisier than Rust.
This used to be the case around Swift 4, but since then they've added so many features and keywords to the language. Now the simplicity and elegance is gone.
Also it seems like there was a marked change in the culture of Swift. It somehow attracted a lot of the "ackchyually" crowd which resulted in a lot of massively complicated features. I liked to occasionally browse the evolution docs and they got more and more complex over time.
Idk, I don't swift is objectively noisy but there is something about reading it that just hurts my brain. Stuff like
ForEach(vm.sorted(by: \.name)) { user in
row(for: user)
}
\. looks like a syntax error to me, wtf. Also, "in" instead of -> ???
.padding(.vertical, 4)
I also really dislike how you can leave off the type name, meaning you never actually know what that Type is unless you literally inspect the signature of the caller.
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.
> 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?
6 replies →
Python 3 barely managed to dethrone Python.
I'm sorry, that's absolutely bullshit. In fact, I wish we had left everyone who complained behind—the python community would have been happier and healthier for it. Absolute crybabies who wanted to be catered to without caring for how intractable the problems with python2 were—e.g. dealing with unicode was a royal pain in the ass, and the bytes/string divide completely fixed it. IMO, it was the best-executed breaking change I've ever witnessed in a language.
In comparison, e.g. Scala 2 -> Scala 3 was an absolute nightmare—it just didn't have the same vocal wailing from maintainers in the community (or, I suppose, a fraction of Python's popularity to begin with).
2 replies →
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.
1 reply →
Python's interactive interpreter makes it pretty useful as a shell, for iterative development, and crucially useful in a Jupyter notebook. I've also found CircuitPython's interpreter to be bonkers useful in prototyping embedded projects. (This, on top of the nice datascience, ML, and NN libraries).
Swift just wasn't doing the same things. And even if it did, Swift would compete with other languages that were understood as "a better Python", like Julia. Even then, Swift only came to Linux in 2016, Windows in 2020, and FreeBSD less than a year ago with WWDC 2025.
I think it doesn't help that the mid 2010s saw a burst of Cool and New languages announced or go mainstream. Go, Julia, Rust, TypeScript, Solidity, etc. along with Swift. I think most of us only have space to pick up one or two of these cool-and-new languages every few years.
> 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.
> 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.
2 replies →
Maybe Chris Lattner leaving and creating Mojo also didn’t help in that regard.
Swift for TensorFlow was a cool idea in that time …
It remains to be seen how much Mojo has learnt from that effort.
NVidia, AMD and Intel now have doubled now into giving Python GPU JITs, and Julia, the same capabilities as their CUDA, ROCm, and SYSCL offerings with C++.
With Julia and Python having their 1.0 long behind them.
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 ---
4 replies →
> 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.
The thing what people don't get with C++'s complexity is that complexity is unavoidable.
It is also there in Ada, C#, Java, Python, Common Lisp,....
Even if the languages started tiny, complexity eventually grows on them.
C23 + compiler extensions is quite far from where K&R C was.
Scheme R7 is quite far from where Scheme started.
Go's warts are directly related to ignoring history of growing pains from other ecosystems.
> Even if the languages started tiny, complexity eventually grows on them.
And then of course the case that proves the opposite, Clojure. Sure, new ideas appear, but core language is more or less unchanged since introduced, rock solid and decades old projects still run just fine, although usually a bit faster.
7 replies →
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)!
6 replies →
Which keywords would you get rid of and why? You don't have to use all of them!
16 replies →
I felt that too many smart people were getting involved in the evolution of the language. There should have been a benevolent dictator to say NO.
>"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.
> Haven't used it since v3 though.
Since 5.10 it's been worth picking back up if you're on MacOS.
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.
2 replies →
> 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.
1 reply →
> 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.
2 replies →
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.
5 replies →
Dethroned Python? The Apple language, seriously. Where is numpy for swift?
I spent last week (with Opus, of course) porting the xv6-riscv teaching operating system to a bunch of different languages. Zig, Nim, LISP, and Swift.
The improvements in embedded Swift have definitely made it one of the most enjoyable/productive languages to work on the OS. I feel like I can build useful abstractions that wrap raw memory access and make the userland code feel very neat.
On the other hand, the compilation times are SO bad, that I'm really focusing on the Nim port anyway.
It's been a long time since I came across Nim. I thought it was really interesting about 12 years ago. What made you land on Nim instead of any of the more obvious alternatives?
I was looking for something that allows easy access to direct memory, with a syntax thats a little easier to explain than C. Frankly, zig was not actually a real viable option based on that syntax requirement but I still wanted to explore it.
Nim really is clean and simple.
4 replies →
LISP like McCarthy LISP?
> 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.
6 replies →
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.
7 replies →
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.
6 replies →
Beyond the marketing view... here are the (incomplete) changes:
Here are the evolution proposals that landed in 6.3:
Overall 6.3 ended up mostly about integration: stdlib, c/c++ (often driven by swift-java interop needs), and builds.
SPM (swift package manager) is slowly reaching out to take over xcode build features (e.g., resources most recently), and they have been inching and hacking their way to a new swift-build engine (now experimental) and "prebuilt" modules for the compiler/IDE macro support. Things Go Wrong all the time when trying to replace parts while driving, and there's very little visibility or control over the interactions between SPM and Xcode.
Conversely to integrations, endogenous language progress seems relatively quiet because there's a lot of behind-the-scenes work extending the initial blush of lifetime controls to iterators, stdlib types, etc. (never mind parameter packs). They're in year 4+ of building out the function-coloring of concurrency and isolation domains (6.2 had an "easy" mode that caused lots of problems), so adding year 2+ dataflow coloring of lifetimes is doubly complicating.
Naturally, diverse support for exciting new features results in quite a spread in the third-party library ecosystem of support for various language features. And now with AI entrepreneurs rewriting and porting any project that can score hits and kudos, the usual open-source authorities are losing their steam.
Finally, there's the baseline platform complexity of multiple OS and devices, physical and simulator debugging support, cloud CI...
So: that makes four dimensions of complexity. As a Swift developer you'd have to be very careful to stay on a working path as things shift underneath you.
All for the love of it?
No mention of compilation speed improvements? Very unfortunate. Compilation times slower than rust really hampers the devx of this otherwise decent language.
I tried Swift a few months ago in a project that made use of a bunch of bigger dependencies and I was instantly shocked by the compilation times. It's quite unimaginable to me using Swift for everyday work because of that. Especially when coming from the fast compile times of Go. But it's really unfortunate because I really enjoyed writing Swift because it feels like a very well made language. But iterating on some code and trying to get quick feedback is pure pain.
Tuist is necessary for substantial projects
> 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/
2 replies →
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
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.
3 replies →
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.
5 replies →
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?
[dead]
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
The noncopyable types improvements are the most underrated part of this release. Finally makes it practical to model unique ownership in Swift without fighting the compiler.
How is the toolchain? Does Swift Lint and Swift Format support the newest version. Honestly, the modern program language should have the built-in formatter and recommend lint rules. It is not just shipping a program language, it is a while ecosystem.
Both are apart of the toolchain now, no external dependencies required: `swift format` and `swift format lint` to access them
In an effort to use swift for scripting, without the startup cost:
Swift Caching Compiler - https://github.com/jrz/tools
i worked with SwiftUI for about two years, and i think it's a really nice language. the compiler is very slow though.
but i think it's too coupled to Apple still. when i tried getting anything running on non-Apple, i had so much trouble i decided then to not even bother.
skip.dev helps
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.
> There are still challenges with basics like compression
FWIW, there is an active discussion on this very topic: https://forums.swift.org/t/proposal-compression-library/8541...
As of very recently, the entire stdlib (i.e. "Foundation") is open source and available on all platforms Swift targets. For a while, the Linux builds had a much smaller/limited version of Foundation, but it's fully supported now.
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
And also Android[1]!
[1] https://swiftpackageindex.com/search?query=platform%3Aandroi...
did they ever add #define? bridging constants from the build system to swift with static NSString * const kConstValue = @XSTR(CONST_VALUE); is soooo annoying.
>nocopy for disabling copy-to-clipboard
Im curious how is this used?
It is a markdown thing. It removes the "copy" button from the code block when the markdown is rendered. Search for "nocopy" on this page.
https://docs.instruqt.com/tracks/challenges/using-markdown-e...
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.
Anyone else think the weather in the screen shot at the top of the page is a bit off? Snow in Lisbon (apparently it snowed there once in 2006), rain in Reykjavik at -1°. AI slop?
If you look at the code above, the temperature and weather are selected independently randomly. That alone is not indicative of AI-generated code; a human could write something similar for demo/learning purposes.
My chances of landing at Apple increased when they launched Swift. I am too dumb to learn objective C but swift I can do.
I want to like swift so bad
Swift truly is one of the languages of all time. I started a mobile app with the UI built in Swift and the core in Rust. The amount of implicit and hidden behaviour, magical fields being generated on objects because of certain annotations, the massive amount of @decorators...it's too much. I'm going to have an LLM generate the SwiftUI and touch as little of it as possible.
It's also strange because before I learned Swift, I heard about how beautiful it is but I find it much noisier than Rust.
>I heard about how beautiful it is
This used to be the case around Swift 4, but since then they've added so many features and keywords to the language. Now the simplicity and elegance is gone.
Also it seems like there was a marked change in the culture of Swift. It somehow attracted a lot of the "ackchyually" crowd which resulted in a lot of massively complicated features. I liked to occasionally browse the evolution docs and they got more and more complex over time.
I find rust much noisier, especially at its basics where you write “for item in items” instead of using iter()
Idk, I don't swift is objectively noisy but there is something about reading it that just hurts my brain. Stuff like
\. looks like a syntax error to me, wtf. Also, "in" instead of -> ???
I also really dislike how you can leave off the type name, meaning you never actually know what that Type is unless you literally inspect the signature of the caller.
???
Yeah I fully accept it's just a me problem. But I hate it haha.
What are you using for rust-swift interop?
uniffi
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.
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.
[dead]
[flagged]
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 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.
2 replies →
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.
Nice update, but it's a shame I can't write on it, not because I don't want to, but because it doesn't support it.
but still a good update