> 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.
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.
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.
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++.
>"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.
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.
> 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'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.
Swift has had an interactive interpreter from v1. Even scripting in Swift was supported from the start.
What it really needed back then was ergonomic APIs for this kind of programming.
Why would anyone in 2014 adopt Swift as a quick prototyping/scripting language when you can just do os.path.join() in Python (Swift's path APIs have always defaulted to the NextStep–era stuff), or subprocess.run() (Swift still defaults to NSProcess).
Today, the picture is different; swift-subprocess and swift-system have improved things greatly.
I had a similar journey with F# - the language looked excellent and I really wanted to make it one of my go-to languages, but every time I tried to use it I found bits that would only work on windows (especially around desktop apps). I finally just gave up, though I hear it has gotten better at being truly cross-platform these days.
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.
Yes, exactly. It also allows you to disambiguate overloaded function. e.g. thing.ModuleA::doThing() vs. thing.ModuleB::doThing(), which wasn't possible with the previous syntax.
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.
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.
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
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.
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?
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.
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.
45 comments
[ 2.6 ms ] story [ 61.6 ms ] threadIt's a nice lang for sure, but this will never be true with the way things are. Such wasted opportunity by Apple.
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.
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++.
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.
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 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.
Since 5.10 it's been worth picking back up if you're on MacOS.
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.
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.
Swift has had an interactive interpreter from v1. Even scripting in Swift was supported from the start.
What it really needed back then was ergonomic APIs for this kind of programming.
Why would anyone in 2014 adopt Swift as a quick prototyping/scripting language when you can just do os.path.join() in Python (Swift's path APIs have always defaulted to the NextStep–era stuff), or subprocess.run() (Swift still defaults to NSProcess).
Today, the picture is different; swift-subprocess and swift-system have improved things greatly.
Python powered by C++ libraries comes from HPC folks, places like CERN and Fermilab, they would hardly touched Swift instead.
Reminds me of "In case you forgot, Swift has 217 keywords now" https://x.com/jacobtechtavern/status/1841251621004538183
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.
Im curious how is this used?
https://docs.instruqt.com/tracks/challenges/using-markdown-e...
Swift Caching Compiler - https://github.com/jrz/tools
It's a shame but it for sure needs BigTech for it to be used anywhere else.
It's also strange because before I learned Swift, I heard about how beautiful it is but I find it much noisier than Rust.