There’s definitely areas where I agree Swift is more ergonomic.
Parameter defaults, and null short circuiting are two of them.
I find writing Swift is faster for me, and it’s easier to learn for people than Rust. Also Swift interop with other languages is much simpler.
Though there are way fewer resources to learn Swift, and cargo is superior to SPM. And of course rust is better cross platform today, but Swift is closing the gap.
I think they feel like very similar languages overall, and they both influence each other.
killingtime74
Even if it's the same (faster horse?) I would rather use Rust for the fact it's development is not tied to a big tech company which could abandon it if they liked. Yes it could continue on as a fork but it's development velocity would suffer.
threatofrain
If we're going to be concerned about any language languishing due to a lack of support... like, I don't think people are going to put "Apple dropping support" as anywhere near their shortlist. Rust has a higher risk of losing support.
nomel
First sentence of the wiki page [1]:
> Swift is a high-level general-purpose, multi-paradigm, compiled programming language created by Chris Lattner in 2010 for Apple Inc. and maintained by the open-source community.
A lot of Apple's software is written in Swift now. It's probably not in their interest to abandon the language.
rvz
> I would rather use Rust for the fact it's development is not tied to a big tech company which could abandon it if they liked.
Go's development is tied to Google Inc. and is widely used at Google. Same with Microsoft's C# with .NET and Swift isn't very different to this as long as it is open source.
So this really is a moot point.
IshKebab
Interesting. I'm not totally sold - still seems like Swift is quite niche and Apple-specific - but I might take another look.
Also you might want to rework the `Box` example because you don't actually need to use `Box` in that case - the `Vec` already provides indirection.
xannabelle
I was surprised how similar their approach was to memory management. The creator is doing the same thing for Python as they did for Objective-C, making way for a new wave of Swift and Mojo, although we'll have to see if the latter grows to the same success.
SkiFire13
> Consider an enum that represents a tree. Since, it is a recursive type, Rust will force you to use something like Box<> for referencing a type within itself.
>
> enum TreeNode<T> {
> Leaf(T),
> Branch(Vec<Box<TreeNode<T>>>),
> }
>
> (You could also us Box<Vec<TreeNode<T>>> instead)
This is wrong, you don't need a `Box` here. The Rust compiler forces you to have a layer of indirection, but `Vec` already does that.
JackYoustra
Adding on, its also a bit much to say that Swift has a good level of sugar and reference an enum of all things. Swift's union type story is so poor that, instead of properly modeling state, people to this day still use masses of optional types in their views rather than an enum because actually using swift enums and protocols is so painful.
YmiYugy
I don't think that is true.
Testing with rust 1.92
enum Tree<T> {
Lead(T),
Branch(Vec<Tree<T>>),
}
works just fine, no superfluous Box needed.
LukaD
You don't need Box here because Vec<T> is already a fixed size handle to heap data.
tialaramex
In one sense the places where the Rust is wrong don't trouble me because I already know Rust well, but in the end they do trouble me because it seems reasonable to assume the Swift is equally wrong but I don't know where and how.
For example "In fact, Swift treats enums as more than just types and lets you put methods directly on it" seems to assume that "just types" don't have methods, which I guess is what you might assume coming from say, C++ but Rust isn't C++ and so of course all of its types, including not only user-defined enums, structures and indeed unions can have methods - but also the built-in primitive types all have methods too.
'F'.to_digit(16).unwrap() // is the 32-bit unsigned integer constant 15
Or maybe an even closer to the metal example: Rust's pointer provenance APIs get to provide a method on raw pointers which takes a closure to do stuff like hide boolean flag bits at the bottom of an aligned pointer. The fact that you're ultimately going to lower to an XOR on a CPU address register doesn't mean you shouldn't get method syntax, it's the 21st century.
saghm
You're not wrong, but I think there's a subtle way people still might get confused about `Vec` versus `Box` with the way you've phrased it. I'd argue the important characteristic of `Vec` here isn't that it's indirection but specifically that it's sized at compile time. Compared to a `Box`, it does not provide meaningful indirection around types that are themselves not sized at compile time (e.g. dyn trait objects), and storing them inside a `Vec` itself will require a `Box` or something similar.
JackYoustra
Broadly agree but, as is most things, the devil is in the details!
- Xcode. A really rough ide that has a hard time at scale, choking on package refreshes, many targets, and more. It has a special entitlement so you can't even binary patch it if you want to fix it!
- Build systems. Cargo is _much_ easier to work with than SPM.
- Macros support, codegen is still largely done outside of the macro system, which should indicate its use.
- Linter / format support. Yeah, it exists, last I checked it's just a good bit worse.
- Performance. There are MANY performance cliffs in Swift; most can be fixed by a sufficiently determined compiler developer, but at this point we've kinda departed talking about the language as-is.
- Type inference time. Swift's bidirectional type inference causes a ton of choking on complex expressions, which is a real problem with its number one use case, SwiftUI.
- An exacerbating factor on the above, imports are all implicitly module-scoped, meaning that changing a single file means recomputing the types for all files in the module. And because SPM and Xcode have such a rough time with multiple targets, that usually means that a single change can lead to recompiling all Swift files.
- Weirdness around classes and structs? I understand that they had to do it for objc compatibility, but I would've found it much cleaner if they'd just from the start had something replacing class, like a fully-sugared `final class Box<T>` that replaces all uses of class.
I agree that for the most part it _could_ be an easier rust, but between including bidirectional type inference without a cut operator and poor tooling I struggle to find where it's actually easier in cases that you can't just use typescript and dodge all the non-typecheck compilation headaches entirely.
fragmede
And the licensing agreement. How do I do it on Linux with no Mac or iOS?
dfabulich
If you're not developing an iOS/macOS app, you can skip Xcode completely and just use the `swift` CLI, which is perfectly cromulent. (It works great on Linux and Windows.)
stackghost
FWIW I have written a complete macOS cocoa+swift app in emacs alone without XCode, just using Makefiles. You don't strictly need it.
mrcwinn
Totally agree. Xcode is awful. I’m sure that team has a lot to deal with but they’ve produced since really trash software.
blueprint
I know Xcode might struggle every now and then with some of the things you're talking about and I'm not saying that I don't have any feedback for Apple, but Xcode is one of the most powerful and well designed development and instrumentation environments I've ever used.
hedora
My one experience with swift involved calling a macos api not written in swift, but that had ergonomic swift bindings from Apple.
My code was data race free, but the underlying OS primitive wasn’t, so my program crashed out about 10% of the time.
This isn’t really a criticism of swift as a language, but I haven’t had this sort of problem with the rust ecosystem.
jtrueb
Yes! I’m not sure how many people arguing for one or the other have tried both, but it is clear that you know the pain.
atombender
I've made a tiny SwiftUI app. It was really difficult to figure out the memory leaks. In fact, I have leaks that I still haven't been able to find. For some reason the heap is fine, but the app continues to allocate virtual memory.
I've thrown Claude and Gemini at the app to try to analyze the code, had them use vmmap and Instruments, asked them run all of the code in a loop to reproduce the leakage — and still it leaks, slowly, tens of megabytes per day.
I'm sure it's something simple starting me in the face. But the fact remains that Swift's sort-of-automatic-but-not-quite memory model still makes it much harder to reason about memory than Rust or even Go.
willtemperley
Most Swift compilation slowness can be avoided by componentizing using packages, plus a few tricks like being explicit with types rather than relying on type inference.
I’m not sure why you’re having so much trouble with SPM though, most people seem to get on well with it.
frizlab
I still don’t understand the Xcode rant. Using Swift can be done in any LSP-compatible text editor (VSCode, which even has a first-party extension for Swift, but also zed, Sublime Text, etc.)
Unless you’re doing Apple-specific development, you don’t need Xcode.
crowbahr
I do think xcode is the worst IDE I've ever worked in, bar none. Even Eclipse from 2010 was better than xcode from 2025
latexr
> Xcode
You don’t need it to program in Swift. I write a lot of it and never open Xcode, my terminal editor with LSP support is fantastic at it.
geooff_
Xcode truly is terrible.
ks2048
I’m curious about SPM vs Cargo - are there basic design decisions that make Cargo better or just particularities of thier current states?
amelius
> Swift is better for writing UI and servers and some parts of compilers and operating systems.
For UI, why would anyone choose a language that has no automatic GC that can handle cycles?
keyle
Look up the language and ARC.
mh2266
weak delegates seem to work fine...?
OrangeDelonge
I generally like Swift, but async is a mess, it feels like they come up with a new async library every release
suddenlybananas
I don't really see the advantage of switch statements over match statements.
beshrkayali
Writing Swift is really fun! Last year I built a game and a macOS app (now working on another app) to get some proper hands on experience and I was very impressed. Wrote about it here[1].
I'd love for the experience outside of Xcode to get better (even on a mac, developing for macOS/iOS) but I have to say that I didn't find Xcode to be _that_ aweful. I've certainly used worse IDEs, which is partly why I dislike IDEs altogether.
I personally never seen anything as bad as XCode, but granted, I haven't used really old IDEs (always preferred just editors). Last year I built a few small apps using both XCode/Swift and Visual Studio/C# and using MS stack felt like you are living in the future, despite WinUI having a very dated UI syntax.
gary17the
If you want more convenience from Rust and do not want to mess with Rust borrow checker, you do not really have to switch to Swift: you can rely on Rust reference counting. Use 1.) Rust reference-counted smart pointers[1] for shareable immutable references, and 2.) Rust internal mutability[2] for non-shareable mutable references checked at runtime instead of compile time. Effectively, you will be writing kind of verbose Golang, but keep Rust expressiveness.
Also, you get the ability to use Rc (non-atomic refcount) as long as you’re not in a multithreaded env. The atomic version is Arc, similar to C++ shared_ptr.
And there are no footguns - i.e. you cannot mistakenly use a Rc across threads - because the compiler will ensure that you aren’t doing this via the Send marker trait.
mogoh
> There is a perception that Swift is only a good language for Apple platforms. While this was once true, this is no longer the case and Swift is becoming increasingly a good cross-platform language.
How good is the developer experience on a non-Apple platform really? Linux is my primary platform and my perception is, that allmost all of the swift eco system is for Apple. Libraries, tools, documentation, IDEs, tutorials, etc. all assume, that you use an Apple.
Can someone tell me who does not use an Apple-device and uses swift?
rcarmo
I tried doing compiling a few of my Mac CLI tools to Linux. These days, it's faster to run them through an LLM and get quite excellent Go at the other end, and _that_ is much easier to cross-compile.
I have been looking at the new Android support (don't have the link handy) and it's tempting, but I know Kotlin and always developed for Android with a bare Makefile and the JDK, so I don't need any fancy tooling...
WD-42
It’s not. The Apple devs will tell you it’s a great time on Linux, just like the MS people will tell you the same for C#.
Rust wasn’t designed for any specific platform and you can tell. The ecosystem on Linux especially is fantastic.
frizlab
Swift has swiftly to manage the Swift compilers to use (equivalent of rustup) and LSP works pretty well. Most of the (open-source) libs that Apple does are cross-platform. I personally take care to make sure my personal libs work on all platforms as well, including Windows(!) (anecdotal, I know…).
All in all it’s not perfect yet, but it’s getting better, with intent to continue in that direction.
willhbr
My experience is that it is very frustrating. Apple's documentation makes no mention of what works on Linux and its limitations, so you just have to guess or work it out with trial and error.
Yes, in my experience the Apple bias exists in all the articles and how-tos you read in a way that can trip you up.
It’s been years now but I wanted to create a Set with weak memory in its keys. Everything I read said “oh just use NSHashTable” and I dutifully did (it’s in Foundation) and then when I tried to cross compile it didn’t exist outside of Apple platforms. It’s not as if the import made it clear I wouldn’t be able to use it, but I couldn’t.
isodev
Until you get to the Swift concurrency stuff, or you try to use Swift on a backend or non-Apple system - then it’s hot garbage.
If Rust is too low level for you, you can write Go or Kotlin or even something new and fresh like Gleam.
frizlab
Except I did and it was good. When did you last try?
drcongo
This article made me actually interested in learning Swift. Anyone recommend a good place to start?
Riiiiight. No. I'm a Mac user for decades, former Obj-C hacker, have tried and tried again and again to use Swift (and I have quite a few CLI apps written in it), but the thing has been a clusterfuck of paper cuts and very minor but significant changes over the years, and I gave up waiting for it to settle.
And it's not a more convenient Rust. I'd rather use Zig or Go (neither of which are worthy in the eyes of true Crustaceans, but which just get the job done).
drnick1
No thanks, too tied to Apple and closed source development models.
usamoi
I really don't understand what's the point of such comparisons. Swift uses subtyping, while Rust uses typeclasses. Even looking only at their type systems, the two are completely different. You can't assume they are similar just because they both use the Latin alphabet.
slavapestov
> Swift uses subtyping, while Rust uses typeclasses. Even looking only at their type systems, the two are completely different.
What does it mean to “use” subtyping vs typeclasses? Swift protocols are essentially typeclasses with associated types, just like Rust traits.
java-man
What is "clone-on-right"?
lucsky
A misspelling of "copy-on-write".
jdalsgaard
I would tend to disagree; fundamental to Rust is the concept of zero-cost abstraction. Swift does not do that.
I my view, and I might be wrong, many features of Rust are chosen specifically to have the language comply to the zero-cost rule. Such as the ownership model.
isodev
The explicit ownership model in Rust also protects one from the footguns of actors and Tasks in Swift. Rust also makes most mistakes in that area a build time error which is not only a huge time saver but also helps one learn and improve in these areas.
Really interesting results, not sure how well it is written but works. I was quite found of Rust syntax; it certainly is not as convoluted as C++ (in my opinion).
Then I read this article. Since I was already eye-balling Swift for some time, I decided to give it a try and port to it, using Rust implementation as reference, and this time, without much of A. I. assistance, if I could help it.
Unsupported Linux platform
Debian GNU/Linux 13 (trixie) is not an officially supported platform, but the toolchains for another platform may still work on it.
Please select the platform to use for toolchain downloads:
0) Cancel
1) Ubuntu 24.04
2) Ubuntu 22.04
3) Ubuntu 20.04
4) Ubuntu 18.04
5) Fedora Linux 39
6) RHEL 9
7) Amazon Linux 2
8) Debian GNU/Linux 12
Pick one of the available selections [0-8] :
8
Installing swiftly in /home/debby/.local/share/swiftly/bin/swiftly...
Creating shell environment file for the user...
Updating profile...
Fetching the latest stable Swift release...
Installing Swift 6.2.3
Downloading Swift 6.2.3
100% [========================================================]
Downloaded 947.6 MiB of 947.6 MiB
Verifying toolchain signature...
Extracting toolchain...
The file `/home/debby/ent/agateteper/.swift-version` has been set to `Swift 6.2.3`
The global default toolchain has been set to `Swift 6.2.3`
Swift 6.2.3 is installed successfully!
There are some dependencies that should be installed before using this toolchain.
You can run the following script as the system administrator (e.g. root) to prepare
your system:
apt-get -y install libicu-dev libcurl4-openssl-dev libedit-dev libsqlite3-dev
libncurses-dev libpython3-dev libxml2-dev pkg-config uuid-dev libstdc++-12-dev
947.6 MiB ! I wonder why is that...
rednafi
Swift is a neat language, but it’s a hard sell for server-side software. The ecosystem is tiny, and there’s nothing you gain from using it instead of Go or Rust for infra / distsys.
Also, it works okay at best with VS Code, and you couldn’t pay me to use Xcode.
Kotlin tried doing similar things to gain adoption on the server side. But server-side programming is a crowded space, and people just don’t like writing distsys code in another JVM language. Swift’s story is a little better on that front.
If you want a quick-and-dirty language, Python and TypeScript do the job. For perf-sensitive, highly concurrent environments, Go is hard to compete against. A lot of ops tooling and infra code is written in Go. For systems programming and embedded code, Rust is a better choice.
So while it’s fun to think about what language X gives you in terms of syntax, in practice it’s rarely enough to pick a language like Swift for your next non-toy backend distsys work.
Also, Apple. Given their stance against free and open source software, I wouldn't be too thrilled to pick a language that works better in their walled garden.
myko
I have been using Swift Vapor for personal projects for awhile and it's great. I kind of regret it now on some projects since I use a lot of Go too and I miss the speed of compiling/testing when I'm using agentic coding (where my goal is to put the agent into virtuous loops leading to a success state) - it just takes longer in Swift.
> Rust invented the concept of ownership as a solution memory management issues without resorting to something slower like Garbage Collection or Reference Counting.
This is plain wrong, and it undermines the credibility of the author and the rest of the piece. Rust did not invent ownership in the abstract; it relies on plain RAII, a model that predates Rust by decades and was popularized by C++. What Rust adds is a compile-time borrow checker that enforces ownership and lifetime rules statically, not a fundamentally new memory-management paradigm.
frizlab
Thank you for saying that. It makes me crazy every time I read that rust invented the concept of ownership…
zenlot
[dead]
Alex_L_Wood
One of the Swift’s worst parts is how Apple keeps putting features in there just for the sake of SwiftUI.
MarginalGainz
[dead]
worik
I am unconvinced
I have used Swift (stopped about two years ago) and use Rust extensively these days.
People commenting here have mentioned the dreadful Xcode. But if you want to build systems on Apple, without investing a lot in setup, you are stuck with Xcode.
To be clear it's failures as an editor or build system are not the main problems with Xcode (albethey very frustrating when the intermittent problems show up) it is the abject failure of the tooling.
We never got the profiler to produce anything intelligible after days of trying, spread over several weeks.
SwiftUI is not part of the conversation here, and I limit the amount of UI building I do, but it shares all the problems of declarative UI frameworks - mainly "where is the code?". Debugging logic problems is nigh impossible in code you're unfamiliar with
The very worst part of Swift were the thread control. Trivial to overwrite shared memory, "DispatchQueus" (?IIRC?) are a thin wrap of fork, and do nothing but add complications
Swift is probably better than Objective C, the latter being from the 1980s, and things have moved on, if your target is iOS and friends, and you are sure you never want to port, then obeying Apple is a wise business decision. Other than that stay away from it. Use Go for most things, and Rust when you must
airstrike
I can relate so much to this comment I need to check my house's CO2 level to make sure I didn't write it
Well, the only difference is I'm allergic to Go and just use Rust 99% of the time these days
frizlab
I’m sorry but reading your comment, you have not understood much about Swift (and GCD).
In particular “"DispatchQueus" (?IIRC?) are a thin wrap of fork, and do nothing but add complications”, in addition to having typo, is as wrong as it can get.
> if you want to build systems on Apple, without investing a lot in setup, you are stuck with Xcode.
If you want to do in Swift the same type of dev you do in go/rust/whatever, Xcode is more than not mandatory, it is generally recommended to use something else, including in the Swift community. Also, you can build native apps in Swift using something else than Xcode (if it is possible to do that in rust for macOS, it is obviously possible with Swift).
> We never got the profiler to produce anything intelligible after days of trying
You mean Instruments? That app is incredibly good, I fail to see how you failed to get anything out of it.
> The very worst part of Swift were the thread control
Already talked about that one, but Swift has async/await now, also.
nixpulvis
> Swift takes Rust’s ideas and hides them in C-like syntax.
This example doesn't show me any meaningful difference, and Rust also let's you attach functionality to enums.
isodev
Swift tends to overuse enums, for example people would use them instead of namespaces or when they want a function but don’t want to create a class or a struct which in my opinion has always felt like a work-around for language deficiencies.
kibwen
It also assumes that "C-like syntax" is a desirable thing. Many of the worst parts of Rust syntax (and Swift syntax, and Java syntax, and Javascript syntax, and...) are things it took from C.
mirekrusin
MoonBit lang is better "better Rust" than Swift.
heavyset_go
Are Core Foundation and Foundation Kit still macOS-only?
thomassmith65
I lived and breathed Swift for the first five or six years of its existence. When people compliment it, I assume they haven't used it long enough to hate it.
Swift is a mix of great features, miserable features, and... every other feature that someone on Evolution dreamt up (with the exception of those that would fix the miserable features)
Swift is unique among high-level languages in that the mental effort required to do many simple things rivals that of a low-level language.
ks2048
I think you have to give some examples.
kibwen
> Swift on Windows is being used by The Browser Company to share code and bring the Arc browser to windows.
Swift has little to no toolchain support for less-common platforms like more recent MIPS, LA and alike. I frequently work and develop on such platforms, so sadly this is the major nay for me to use it.
Larrikin
Kotlin and Swift came in to popularity around the same time. They felt extremely similar at the beginning
Kotlin put a lot of work into proving itself as something more than just a language for Android development, starting first with backend.
It seems like once KMP became viable Swift is just trying catch back up.
cosmic_cheese
Opinions on this will vary, but for me Kotlin’s ties to the JVM and associated tooling is like a ball and chain. The language itself is mostly fine (though it has some weird design hangups compared to Swift), but I really do not enjoy the tooling at all. Gradle for example has me banging my head against the wall way too often.
politelemon
I can trust the community behind Rust. I cannot trust the company behind swift. They hold a stance that is against open source, and this stance can affect swift at any time, so I wouldn't want to invest into something that could be affected at a whim. It is certainly not convenient.
Zak
> Except this switch statement is actually not a switch statement at all. It’s an expression. It doesn’t “fallthrough”. It does pattern matching. It’s just a match expression with a different name and syntax.
Giving a familiar name to a concept which behaves in familiar ways some of the time and surprising ways other times seems like a dirty trick to me, not a convenience.
g947o
"The compiler is unable to type-check this expression in reasonable time; try breaking up the expression into distinct sub-expressions" doesn't feel convenient to me.
Validark
> Swift doesn’t have a match statement or expression. It has a switch statement that developers are already familiar with. Except this switch statement is actually not a switch statement at all. It’s an expression. It doesn’t “fallthrough”. It does pattern matching. It’s just a match expression with a different name and syntax.
Are there people who see a "match" statement, smash both hands on the table, and shout, "WHAT THE ___ is a ------- MATCH STATEMENT?!!! THIS IS SO $%^&@*#%& CONFUSING!! I DON'T KNOW THAT WORD!! I ONLY KNOW SWITCH!!"
dzonga
I once wrote a swift server app - hell even did a show hn over here
last time when I used Swift was v3 - and transition from v2 was a little rough.
the language kept adding features becoming a baby C++
if they had invested in bringing outside parties early on - not just iOS etc - swift would've replaced python
cosmic_cheese
To me a big ding on Rust is no native imperative UI toolkit. Last I knew all Rust UI toolkits are declarative, which I’ve found to scale poorly past things like terminals, text editors, some mobile apps, and somewhat simplistic utilities. The more complex your UI gets, the more awkward and ill-suited declarative UI becomes. For something like a replacement for Photoshop or Word or even just Firefox you’re better off with something like AppKit.
How about Rust is Rust. Swift doesn't really appeal to me as a high level programer. C#, JS and Python largely pay my bills.
The non apple ecosystem just isn't there, and it was never built to be cross platform. If I need to build something I'd probably lean on the languages I already know.
A few times a close friend has wanted an app built and I went with Flutter/Dart + Firebase.
I'm using Godot for games.
Learning a new language, even a similar one is a time investment. In fact I just want better tooling for the languages I already know. Word to UV for Python.
Mawr
> without resorting to something slower like Garbage Collection or Reference Counting
Hah! But RC is GC! [1]
> Again, this is just deception for those developers coming from C-like languages. Swift’s error handling works exactly like Rust’s behind the scenes, but it is hidden in a clever, familiar syntax.
But the indent heavy syntax is one of the worst parts of exceptions?
Rust:
fn value_in_cents(coin: Coin) -> u8 {
Swift:
func valueInCents(coin: Coin) -> Int {
Well, that settles it — it is known languages that use snake_case are superior.
> This is because Rust is fast by default, and lets you be slow, while Swift is easy by default and lets you be fast.
Good, good, you're onto something here.
> There is a perception that Swift is only a good language for Apple platforms. While this was once true, this is no longer the case and Swift is becoming increasingly a good cross-platform language.
Sigh. But you just said defaults matter, come on. Let me paraphrase: "This is because Swift is for Apple platforms by default, while Rust is cross-platform by default."
> to do reference counting and “clone-on-right” in your code
Was this article vibe dictated?
morshu9001
I used Swift in versions 1-4, so idk if it's better now, but the syntax seemed fancy and complicated for no reason. So many different ways to do simple things like loops. Infuriating strings lib. Kinda believe the entire language was designed around emojis. And Xcode was a liability.
Rust is more complicated than C but has good reasons for everything it does. It's lower level too, which is fine. If I want high level, I look to JS and not Swift.
bigyabai
Glad to see "Swift is good now" taking the place of "year of the Linux desktop" in a post-Steam Deck world.
There’s definitely areas where I agree Swift is more ergonomic.
Parameter defaults, and null short circuiting are two of them.
I find writing Swift is faster for me, and it’s easier to learn for people than Rust. Also Swift interop with other languages is much simpler.
Though there are way fewer resources to learn Swift, and cargo is superior to SPM. And of course rust is better cross platform today, but Swift is closing the gap.
I think they feel like very similar languages overall, and they both influence each other.
killingtime74
Even if it's the same (faster horse?) I would rather use Rust for the fact it's development is not tied to a big tech company which could abandon it if they liked. Yes it could continue on as a fork but it's development velocity would suffer.
threatofrain
If we're going to be concerned about any language languishing due to a lack of support... like, I don't think people are going to put "Apple dropping support" as anywhere near their shortlist. Rust has a higher risk of losing support.
nomel
First sentence of the wiki page [1]:
> Swift is a high-level general-purpose, multi-paradigm, compiled programming language created by Chris Lattner in 2010 for Apple Inc. and maintained by the open-source community.
A lot of Apple's software is written in Swift now. It's probably not in their interest to abandon the language.
rvz
> I would rather use Rust for the fact it's development is not tied to a big tech company which could abandon it if they liked.
Go's development is tied to Google Inc. and is widely used at Google. Same with Microsoft's C# with .NET and Swift isn't very different to this as long as it is open source.
So this really is a moot point.
IshKebab
Interesting. I'm not totally sold - still seems like Swift is quite niche and Apple-specific - but I might take another look.
Also you might want to rework the `Box` example because you don't actually need to use `Box` in that case - the `Vec` already provides indirection.
xannabelle
I was surprised how similar their approach was to memory management. The creator is doing the same thing for Python as they did for Objective-C, making way for a new wave of Swift and Mojo, although we'll have to see if the latter grows to the same success.
SkiFire13
> Consider an enum that represents a tree. Since, it is a recursive type, Rust will force you to use something like Box<> for referencing a type within itself.
>
> enum TreeNode<T> {
> Leaf(T),
> Branch(Vec<Box<TreeNode<T>>>),
> }
>
> (You could also us Box<Vec<TreeNode<T>>> instead)
This is wrong, you don't need a `Box` here. The Rust compiler forces you to have a layer of indirection, but `Vec` already does that.
JackYoustra
Adding on, its also a bit much to say that Swift has a good level of sugar and reference an enum of all things. Swift's union type story is so poor that, instead of properly modeling state, people to this day still use masses of optional types in their views rather than an enum because actually using swift enums and protocols is so painful.
YmiYugy
I don't think that is true.
Testing with rust 1.92
enum Tree<T> {
Lead(T),
Branch(Vec<Tree<T>>),
}
works just fine, no superfluous Box needed.
LukaD
You don't need Box here because Vec<T> is already a fixed size handle to heap data.
tialaramex
In one sense the places where the Rust is wrong don't trouble me because I already know Rust well, but in the end they do trouble me because it seems reasonable to assume the Swift is equally wrong but I don't know where and how.
For example "In fact, Swift treats enums as more than just types and lets you put methods directly on it" seems to assume that "just types" don't have methods, which I guess is what you might assume coming from say, C++ but Rust isn't C++ and so of course all of its types, including not only user-defined enums, structures and indeed unions can have methods - but also the built-in primitive types all have methods too.
'F'.to_digit(16).unwrap() // is the 32-bit unsigned integer constant 15
Or maybe an even closer to the metal example: Rust's pointer provenance APIs get to provide a method on raw pointers which takes a closure to do stuff like hide boolean flag bits at the bottom of an aligned pointer. The fact that you're ultimately going to lower to an XOR on a CPU address register doesn't mean you shouldn't get method syntax, it's the 21st century.
saghm
You're not wrong, but I think there's a subtle way people still might get confused about `Vec` versus `Box` with the way you've phrased it. I'd argue the important characteristic of `Vec` here isn't that it's indirection but specifically that it's sized at compile time. Compared to a `Box`, it does not provide meaningful indirection around types that are themselves not sized at compile time (e.g. dyn trait objects), and storing them inside a `Vec` itself will require a `Box` or something similar.
JackYoustra
Broadly agree but, as is most things, the devil is in the details!
- Xcode. A really rough ide that has a hard time at scale, choking on package refreshes, many targets, and more. It has a special entitlement so you can't even binary patch it if you want to fix it!
- Build systems. Cargo is _much_ easier to work with than SPM.
- Macros support, codegen is still largely done outside of the macro system, which should indicate its use.
- Linter / format support. Yeah, it exists, last I checked it's just a good bit worse.
- Performance. There are MANY performance cliffs in Swift; most can be fixed by a sufficiently determined compiler developer, but at this point we've kinda departed talking about the language as-is.
- Type inference time. Swift's bidirectional type inference causes a ton of choking on complex expressions, which is a real problem with its number one use case, SwiftUI.
- An exacerbating factor on the above, imports are all implicitly module-scoped, meaning that changing a single file means recomputing the types for all files in the module. And because SPM and Xcode have such a rough time with multiple targets, that usually means that a single change can lead to recompiling all Swift files.
- Weirdness around classes and structs? I understand that they had to do it for objc compatibility, but I would've found it much cleaner if they'd just from the start had something replacing class, like a fully-sugared `final class Box<T>` that replaces all uses of class.
I agree that for the most part it _could_ be an easier rust, but between including bidirectional type inference without a cut operator and poor tooling I struggle to find where it's actually easier in cases that you can't just use typescript and dodge all the non-typecheck compilation headaches entirely.
fragmede
And the licensing agreement. How do I do it on Linux with no Mac or iOS?
dfabulich
If you're not developing an iOS/macOS app, you can skip Xcode completely and just use the `swift` CLI, which is perfectly cromulent. (It works great on Linux and Windows.)
stackghost
FWIW I have written a complete macOS cocoa+swift app in emacs alone without XCode, just using Makefiles. You don't strictly need it.
mrcwinn
Totally agree. Xcode is awful. I’m sure that team has a lot to deal with but they’ve produced since really trash software.
blueprint
I know Xcode might struggle every now and then with some of the things you're talking about and I'm not saying that I don't have any feedback for Apple, but Xcode is one of the most powerful and well designed development and instrumentation environments I've ever used.
hedora
My one experience with swift involved calling a macos api not written in swift, but that had ergonomic swift bindings from Apple.
My code was data race free, but the underlying OS primitive wasn’t, so my program crashed out about 10% of the time.
This isn’t really a criticism of swift as a language, but I haven’t had this sort of problem with the rust ecosystem.
jtrueb
Yes! I’m not sure how many people arguing for one or the other have tried both, but it is clear that you know the pain.
atombender
I've made a tiny SwiftUI app. It was really difficult to figure out the memory leaks. In fact, I have leaks that I still haven't been able to find. For some reason the heap is fine, but the app continues to allocate virtual memory.
I've thrown Claude and Gemini at the app to try to analyze the code, had them use vmmap and Instruments, asked them run all of the code in a loop to reproduce the leakage — and still it leaks, slowly, tens of megabytes per day.
I'm sure it's something simple starting me in the face. But the fact remains that Swift's sort-of-automatic-but-not-quite memory model still makes it much harder to reason about memory than Rust or even Go.
willtemperley
Most Swift compilation slowness can be avoided by componentizing using packages, plus a few tricks like being explicit with types rather than relying on type inference.
I’m not sure why you’re having so much trouble with SPM though, most people seem to get on well with it.
frizlab
I still don’t understand the Xcode rant. Using Swift can be done in any LSP-compatible text editor (VSCode, which even has a first-party extension for Swift, but also zed, Sublime Text, etc.)
Unless you’re doing Apple-specific development, you don’t need Xcode.
crowbahr
I do think xcode is the worst IDE I've ever worked in, bar none. Even Eclipse from 2010 was better than xcode from 2025
latexr
> Xcode
You don’t need it to program in Swift. I write a lot of it and never open Xcode, my terminal editor with LSP support is fantastic at it.
geooff_
Xcode truly is terrible.
ks2048
I’m curious about SPM vs Cargo - are there basic design decisions that make Cargo better or just particularities of thier current states?
amelius
> Swift is better for writing UI and servers and some parts of compilers and operating systems.
For UI, why would anyone choose a language that has no automatic GC that can handle cycles?
keyle
Look up the language and ARC.
mh2266
weak delegates seem to work fine...?
OrangeDelonge
I generally like Swift, but async is a mess, it feels like they come up with a new async library every release
suddenlybananas
I don't really see the advantage of switch statements over match statements.
beshrkayali
Writing Swift is really fun! Last year I built a game and a macOS app (now working on another app) to get some proper hands on experience and I was very impressed. Wrote about it here[1].
I'd love for the experience outside of Xcode to get better (even on a mac, developing for macOS/iOS) but I have to say that I didn't find Xcode to be _that_ aweful. I've certainly used worse IDEs, which is partly why I dislike IDEs altogether.
I personally never seen anything as bad as XCode, but granted, I haven't used really old IDEs (always preferred just editors). Last year I built a few small apps using both XCode/Swift and Visual Studio/C# and using MS stack felt like you are living in the future, despite WinUI having a very dated UI syntax.
gary17the
If you want more convenience from Rust and do not want to mess with Rust borrow checker, you do not really have to switch to Swift: you can rely on Rust reference counting. Use 1.) Rust reference-counted smart pointers[1] for shareable immutable references, and 2.) Rust internal mutability[2] for non-shareable mutable references checked at runtime instead of compile time. Effectively, you will be writing kind of verbose Golang, but keep Rust expressiveness.
Also, you get the ability to use Rc (non-atomic refcount) as long as you’re not in a multithreaded env. The atomic version is Arc, similar to C++ shared_ptr.
And there are no footguns - i.e. you cannot mistakenly use a Rc across threads - because the compiler will ensure that you aren’t doing this via the Send marker trait.
mogoh
> There is a perception that Swift is only a good language for Apple platforms. While this was once true, this is no longer the case and Swift is becoming increasingly a good cross-platform language.
How good is the developer experience on a non-Apple platform really? Linux is my primary platform and my perception is, that allmost all of the swift eco system is for Apple. Libraries, tools, documentation, IDEs, tutorials, etc. all assume, that you use an Apple.
Can someone tell me who does not use an Apple-device and uses swift?
rcarmo
I tried doing compiling a few of my Mac CLI tools to Linux. These days, it's faster to run them through an LLM and get quite excellent Go at the other end, and _that_ is much easier to cross-compile.
I have been looking at the new Android support (don't have the link handy) and it's tempting, but I know Kotlin and always developed for Android with a bare Makefile and the JDK, so I don't need any fancy tooling...
WD-42
It’s not. The Apple devs will tell you it’s a great time on Linux, just like the MS people will tell you the same for C#.
Rust wasn’t designed for any specific platform and you can tell. The ecosystem on Linux especially is fantastic.
frizlab
Swift has swiftly to manage the Swift compilers to use (equivalent of rustup) and LSP works pretty well. Most of the (open-source) libs that Apple does are cross-platform. I personally take care to make sure my personal libs work on all platforms as well, including Windows(!) (anecdotal, I know…).
All in all it’s not perfect yet, but it’s getting better, with intent to continue in that direction.
willhbr
My experience is that it is very frustrating. Apple's documentation makes no mention of what works on Linux and its limitations, so you just have to guess or work it out with trial and error.
Yes, in my experience the Apple bias exists in all the articles and how-tos you read in a way that can trip you up.
It’s been years now but I wanted to create a Set with weak memory in its keys. Everything I read said “oh just use NSHashTable” and I dutifully did (it’s in Foundation) and then when I tried to cross compile it didn’t exist outside of Apple platforms. It’s not as if the import made it clear I wouldn’t be able to use it, but I couldn’t.
isodev
Until you get to the Swift concurrency stuff, or you try to use Swift on a backend or non-Apple system - then it’s hot garbage.
If Rust is too low level for you, you can write Go or Kotlin or even something new and fresh like Gleam.
frizlab
Except I did and it was good. When did you last try?
drcongo
This article made me actually interested in learning Swift. Anyone recommend a good place to start?
Riiiiight. No. I'm a Mac user for decades, former Obj-C hacker, have tried and tried again and again to use Swift (and I have quite a few CLI apps written in it), but the thing has been a clusterfuck of paper cuts and very minor but significant changes over the years, and I gave up waiting for it to settle.
And it's not a more convenient Rust. I'd rather use Zig or Go (neither of which are worthy in the eyes of true Crustaceans, but which just get the job done).
drnick1
No thanks, too tied to Apple and closed source development models.
usamoi
I really don't understand what's the point of such comparisons. Swift uses subtyping, while Rust uses typeclasses. Even looking only at their type systems, the two are completely different. You can't assume they are similar just because they both use the Latin alphabet.
slavapestov
> Swift uses subtyping, while Rust uses typeclasses. Even looking only at their type systems, the two are completely different.
What does it mean to “use” subtyping vs typeclasses? Swift protocols are essentially typeclasses with associated types, just like Rust traits.
java-man
What is "clone-on-right"?
lucsky
A misspelling of "copy-on-write".
jdalsgaard
I would tend to disagree; fundamental to Rust is the concept of zero-cost abstraction. Swift does not do that.
I my view, and I might be wrong, many features of Rust are chosen specifically to have the language comply to the zero-cost rule. Such as the ownership model.
isodev
The explicit ownership model in Rust also protects one from the footguns of actors and Tasks in Swift. Rust also makes most mistakes in that area a build time error which is not only a huge time saver but also helps one learn and improve in these areas.
Really interesting results, not sure how well it is written but works. I was quite found of Rust syntax; it certainly is not as convoluted as C++ (in my opinion).
Then I read this article. Since I was already eye-balling Swift for some time, I decided to give it a try and port to it, using Rust implementation as reference, and this time, without much of A. I. assistance, if I could help it.
Unsupported Linux platform
Debian GNU/Linux 13 (trixie) is not an officially supported platform, but the toolchains for another platform may still work on it.
Please select the platform to use for toolchain downloads:
0) Cancel
1) Ubuntu 24.04
2) Ubuntu 22.04
3) Ubuntu 20.04
4) Ubuntu 18.04
5) Fedora Linux 39
6) RHEL 9
7) Amazon Linux 2
8) Debian GNU/Linux 12
Pick one of the available selections [0-8] :
8
Installing swiftly in /home/debby/.local/share/swiftly/bin/swiftly...
Creating shell environment file for the user...
Updating profile...
Fetching the latest stable Swift release...
Installing Swift 6.2.3
Downloading Swift 6.2.3
100% [========================================================]
Downloaded 947.6 MiB of 947.6 MiB
Verifying toolchain signature...
Extracting toolchain...
The file `/home/debby/ent/agateteper/.swift-version` has been set to `Swift 6.2.3`
The global default toolchain has been set to `Swift 6.2.3`
Swift 6.2.3 is installed successfully!
There are some dependencies that should be installed before using this toolchain.
You can run the following script as the system administrator (e.g. root) to prepare
your system:
apt-get -y install libicu-dev libcurl4-openssl-dev libedit-dev libsqlite3-dev
libncurses-dev libpython3-dev libxml2-dev pkg-config uuid-dev libstdc++-12-dev
947.6 MiB ! I wonder why is that...
rednafi
Swift is a neat language, but it’s a hard sell for server-side software. The ecosystem is tiny, and there’s nothing you gain from using it instead of Go or Rust for infra / distsys.
Also, it works okay at best with VS Code, and you couldn’t pay me to use Xcode.
Kotlin tried doing similar things to gain adoption on the server side. But server-side programming is a crowded space, and people just don’t like writing distsys code in another JVM language. Swift’s story is a little better on that front.
If you want a quick-and-dirty language, Python and TypeScript do the job. For perf-sensitive, highly concurrent environments, Go is hard to compete against. A lot of ops tooling and infra code is written in Go. For systems programming and embedded code, Rust is a better choice.
So while it’s fun to think about what language X gives you in terms of syntax, in practice it’s rarely enough to pick a language like Swift for your next non-toy backend distsys work.
Also, Apple. Given their stance against free and open source software, I wouldn't be too thrilled to pick a language that works better in their walled garden.
myko
I have been using Swift Vapor for personal projects for awhile and it's great. I kind of regret it now on some projects since I use a lot of Go too and I miss the speed of compiling/testing when I'm using agentic coding (where my goal is to put the agent into virtuous loops leading to a success state) - it just takes longer in Swift.
> Rust invented the concept of ownership as a solution memory management issues without resorting to something slower like Garbage Collection or Reference Counting.
This is plain wrong, and it undermines the credibility of the author and the rest of the piece. Rust did not invent ownership in the abstract; it relies on plain RAII, a model that predates Rust by decades and was popularized by C++. What Rust adds is a compile-time borrow checker that enforces ownership and lifetime rules statically, not a fundamentally new memory-management paradigm.
frizlab
Thank you for saying that. It makes me crazy every time I read that rust invented the concept of ownership…
zenlot
[dead]
Alex_L_Wood
One of the Swift’s worst parts is how Apple keeps putting features in there just for the sake of SwiftUI.
MarginalGainz
[dead]
worik
I am unconvinced
I have used Swift (stopped about two years ago) and use Rust extensively these days.
People commenting here have mentioned the dreadful Xcode. But if you want to build systems on Apple, without investing a lot in setup, you are stuck with Xcode.
To be clear it's failures as an editor or build system are not the main problems with Xcode (albethey very frustrating when the intermittent problems show up) it is the abject failure of the tooling.
We never got the profiler to produce anything intelligible after days of trying, spread over several weeks.
SwiftUI is not part of the conversation here, and I limit the amount of UI building I do, but it shares all the problems of declarative UI frameworks - mainly "where is the code?". Debugging logic problems is nigh impossible in code you're unfamiliar with
The very worst part of Swift were the thread control. Trivial to overwrite shared memory, "DispatchQueus" (?IIRC?) are a thin wrap of fork, and do nothing but add complications
Swift is probably better than Objective C, the latter being from the 1980s, and things have moved on, if your target is iOS and friends, and you are sure you never want to port, then obeying Apple is a wise business decision. Other than that stay away from it. Use Go for most things, and Rust when you must
airstrike
I can relate so much to this comment I need to check my house's CO2 level to make sure I didn't write it
Well, the only difference is I'm allergic to Go and just use Rust 99% of the time these days
frizlab
I’m sorry but reading your comment, you have not understood much about Swift (and GCD).
In particular “"DispatchQueus" (?IIRC?) are a thin wrap of fork, and do nothing but add complications”, in addition to having typo, is as wrong as it can get.
> if you want to build systems on Apple, without investing a lot in setup, you are stuck with Xcode.
If you want to do in Swift the same type of dev you do in go/rust/whatever, Xcode is more than not mandatory, it is generally recommended to use something else, including in the Swift community. Also, you can build native apps in Swift using something else than Xcode (if it is possible to do that in rust for macOS, it is obviously possible with Swift).
> We never got the profiler to produce anything intelligible after days of trying
You mean Instruments? That app is incredibly good, I fail to see how you failed to get anything out of it.
> The very worst part of Swift were the thread control
Already talked about that one, but Swift has async/await now, also.
nixpulvis
> Swift takes Rust’s ideas and hides them in C-like syntax.
This example doesn't show me any meaningful difference, and Rust also let's you attach functionality to enums.
isodev
Swift tends to overuse enums, for example people would use them instead of namespaces or when they want a function but don’t want to create a class or a struct which in my opinion has always felt like a work-around for language deficiencies.
kibwen
It also assumes that "C-like syntax" is a desirable thing. Many of the worst parts of Rust syntax (and Swift syntax, and Java syntax, and Javascript syntax, and...) are things it took from C.
mirekrusin
MoonBit lang is better "better Rust" than Swift.
heavyset_go
Are Core Foundation and Foundation Kit still macOS-only?
thomassmith65
I lived and breathed Swift for the first five or six years of its existence. When people compliment it, I assume they haven't used it long enough to hate it.
Swift is a mix of great features, miserable features, and... every other feature that someone on Evolution dreamt up (with the exception of those that would fix the miserable features)
Swift is unique among high-level languages in that the mental effort required to do many simple things rivals that of a low-level language.
ks2048
I think you have to give some examples.
kibwen
> Swift on Windows is being used by The Browser Company to share code and bring the Arc browser to windows.
Swift has little to no toolchain support for less-common platforms like more recent MIPS, LA and alike. I frequently work and develop on such platforms, so sadly this is the major nay for me to use it.
Larrikin
Kotlin and Swift came in to popularity around the same time. They felt extremely similar at the beginning
Kotlin put a lot of work into proving itself as something more than just a language for Android development, starting first with backend.
It seems like once KMP became viable Swift is just trying catch back up.
cosmic_cheese
Opinions on this will vary, but for me Kotlin’s ties to the JVM and associated tooling is like a ball and chain. The language itself is mostly fine (though it has some weird design hangups compared to Swift), but I really do not enjoy the tooling at all. Gradle for example has me banging my head against the wall way too often.
politelemon
I can trust the community behind Rust. I cannot trust the company behind swift. They hold a stance that is against open source, and this stance can affect swift at any time, so I wouldn't want to invest into something that could be affected at a whim. It is certainly not convenient.
Zak
> Except this switch statement is actually not a switch statement at all. It’s an expression. It doesn’t “fallthrough”. It does pattern matching. It’s just a match expression with a different name and syntax.
Giving a familiar name to a concept which behaves in familiar ways some of the time and surprising ways other times seems like a dirty trick to me, not a convenience.
g947o
"The compiler is unable to type-check this expression in reasonable time; try breaking up the expression into distinct sub-expressions" doesn't feel convenient to me.
Validark
> Swift doesn’t have a match statement or expression. It has a switch statement that developers are already familiar with. Except this switch statement is actually not a switch statement at all. It’s an expression. It doesn’t “fallthrough”. It does pattern matching. It’s just a match expression with a different name and syntax.
Are there people who see a "match" statement, smash both hands on the table, and shout, "WHAT THE ___ is a ------- MATCH STATEMENT?!!! THIS IS SO $%^&@*#%& CONFUSING!! I DON'T KNOW THAT WORD!! I ONLY KNOW SWITCH!!"
dzonga
I once wrote a swift server app - hell even did a show hn over here
last time when I used Swift was v3 - and transition from v2 was a little rough.
the language kept adding features becoming a baby C++
if they had invested in bringing outside parties early on - not just iOS etc - swift would've replaced python
cosmic_cheese
To me a big ding on Rust is no native imperative UI toolkit. Last I knew all Rust UI toolkits are declarative, which I’ve found to scale poorly past things like terminals, text editors, some mobile apps, and somewhat simplistic utilities. The more complex your UI gets, the more awkward and ill-suited declarative UI becomes. For something like a replacement for Photoshop or Word or even just Firefox you’re better off with something like AppKit.
How about Rust is Rust. Swift doesn't really appeal to me as a high level programer. C#, JS and Python largely pay my bills.
The non apple ecosystem just isn't there, and it was never built to be cross platform. If I need to build something I'd probably lean on the languages I already know.
A few times a close friend has wanted an app built and I went with Flutter/Dart + Firebase.
I'm using Godot for games.
Learning a new language, even a similar one is a time investment. In fact I just want better tooling for the languages I already know. Word to UV for Python.
Mawr
> without resorting to something slower like Garbage Collection or Reference Counting
Hah! But RC is GC! [1]
> Again, this is just deception for those developers coming from C-like languages. Swift’s error handling works exactly like Rust’s behind the scenes, but it is hidden in a clever, familiar syntax.
But the indent heavy syntax is one of the worst parts of exceptions?
Rust:
fn value_in_cents(coin: Coin) -> u8 {
Swift:
func valueInCents(coin: Coin) -> Int {
Well, that settles it — it is known languages that use snake_case are superior.
> This is because Rust is fast by default, and lets you be slow, while Swift is easy by default and lets you be fast.
Good, good, you're onto something here.
> There is a perception that Swift is only a good language for Apple platforms. While this was once true, this is no longer the case and Swift is becoming increasingly a good cross-platform language.
Sigh. But you just said defaults matter, come on. Let me paraphrase: "This is because Swift is for Apple platforms by default, while Rust is cross-platform by default."
> to do reference counting and “clone-on-right” in your code
Was this article vibe dictated?
morshu9001
I used Swift in versions 1-4, so idk if it's better now, but the syntax seemed fancy and complicated for no reason. So many different ways to do simple things like loops. Infuriating strings lib. Kinda believe the entire language was designed around emojis. And Xcode was a liability.
Rust is more complicated than C but has good reasons for everything it does. It's lower level too, which is fine. If I want high level, I look to JS and not Swift.
Glad to see "Swift is good now" taking the place of "year of the Linux desktop" in a post-Steam Deck world.
>Swift is more convenient Rust
Nah.
... Literally ruined
https://youtube.com/clip/UgkxFZA4XXnXzHyNso0OQ28XU60U1-jdR13...
There’s definitely areas where I agree Swift is more ergonomic.
Parameter defaults, and null short circuiting are two of them.
I find writing Swift is faster for me, and it’s easier to learn for people than Rust. Also Swift interop with other languages is much simpler.
Though there are way fewer resources to learn Swift, and cargo is superior to SPM. And of course rust is better cross platform today, but Swift is closing the gap.
I think they feel like very similar languages overall, and they both influence each other.
Even if it's the same (faster horse?) I would rather use Rust for the fact it's development is not tied to a big tech company which could abandon it if they liked. Yes it could continue on as a fork but it's development velocity would suffer.
If we're going to be concerned about any language languishing due to a lack of support... like, I don't think people are going to put "Apple dropping support" as anywhere near their shortlist. Rust has a higher risk of losing support.
First sentence of the wiki page [1]:
> Swift is a high-level general-purpose, multi-paradigm, compiled programming language created by Chris Lattner in 2010 for Apple Inc. and maintained by the open-source community.
As the article repeats, it is not Apple specific.
[1] https://en.wikipedia.org/wiki/Swift_(programming_language)
A lot of Apple's software is written in Swift now. It's probably not in their interest to abandon the language.
> I would rather use Rust for the fact it's development is not tied to a big tech company which could abandon it if they liked.
Go's development is tied to Google Inc. and is widely used at Google. Same with Microsoft's C# with .NET and Swift isn't very different to this as long as it is open source.
So this really is a moot point.
Interesting. I'm not totally sold - still seems like Swift is quite niche and Apple-specific - but I might take another look.
Also you might want to rework the `Box` example because you don't actually need to use `Box` in that case - the `Vec` already provides indirection.
I was surprised how similar their approach was to memory management. The creator is doing the same thing for Python as they did for Objective-C, making way for a new wave of Swift and Mojo, although we'll have to see if the latter grows to the same success.
> Consider an enum that represents a tree. Since, it is a recursive type, Rust will force you to use something like Box<> for referencing a type within itself. > > enum TreeNode<T> { > Leaf(T), > Branch(Vec<Box<TreeNode<T>>>), > } > > (You could also us Box<Vec<TreeNode<T>>> instead)
This is wrong, you don't need a `Box` here. The Rust compiler forces you to have a layer of indirection, but `Vec` already does that.
Adding on, its also a bit much to say that Swift has a good level of sugar and reference an enum of all things. Swift's union type story is so poor that, instead of properly modeling state, people to this day still use masses of optional types in their views rather than an enum because actually using swift enums and protocols is so painful.
I don't think that is true. Testing with rust 1.92
enum Tree<T> {
Branch(Vec<Tree<T>>), }works just fine, no superfluous Box needed.
You don't need Box here because Vec<T> is already a fixed size handle to heap data.
In one sense the places where the Rust is wrong don't trouble me because I already know Rust well, but in the end they do trouble me because it seems reasonable to assume the Swift is equally wrong but I don't know where and how.
For example "In fact, Swift treats enums as more than just types and lets you put methods directly on it" seems to assume that "just types" don't have methods, which I guess is what you might assume coming from say, C++ but Rust isn't C++ and so of course all of its types, including not only user-defined enums, structures and indeed unions can have methods - but also the built-in primitive types all have methods too.
Or maybe an even closer to the metal example: Rust's pointer provenance APIs get to provide a method on raw pointers which takes a closure to do stuff like hide boolean flag bits at the bottom of an aligned pointer. The fact that you're ultimately going to lower to an XOR on a CPU address register doesn't mean you shouldn't get method syntax, it's the 21st century.You're not wrong, but I think there's a subtle way people still might get confused about `Vec` versus `Box` with the way you've phrased it. I'd argue the important characteristic of `Vec` here isn't that it's indirection but specifically that it's sized at compile time. Compared to a `Box`, it does not provide meaningful indirection around types that are themselves not sized at compile time (e.g. dyn trait objects), and storing them inside a `Vec` itself will require a `Box` or something similar.
Broadly agree but, as is most things, the devil is in the details!
- Xcode. A really rough ide that has a hard time at scale, choking on package refreshes, many targets, and more. It has a special entitlement so you can't even binary patch it if you want to fix it!
- Build systems. Cargo is _much_ easier to work with than SPM.
- Macros support, codegen is still largely done outside of the macro system, which should indicate its use.
- Linter / format support. Yeah, it exists, last I checked it's just a good bit worse.
- Performance. There are MANY performance cliffs in Swift; most can be fixed by a sufficiently determined compiler developer, but at this point we've kinda departed talking about the language as-is.
- Type inference time. Swift's bidirectional type inference causes a ton of choking on complex expressions, which is a real problem with its number one use case, SwiftUI.
- An exacerbating factor on the above, imports are all implicitly module-scoped, meaning that changing a single file means recomputing the types for all files in the module. And because SPM and Xcode have such a rough time with multiple targets, that usually means that a single change can lead to recompiling all Swift files.
- Weirdness around classes and structs? I understand that they had to do it for objc compatibility, but I would've found it much cleaner if they'd just from the start had something replacing class, like a fully-sugared `final class Box<T>` that replaces all uses of class.
I agree that for the most part it _could_ be an easier rust, but between including bidirectional type inference without a cut operator and poor tooling I struggle to find where it's actually easier in cases that you can't just use typescript and dodge all the non-typecheck compilation headaches entirely.
And the licensing agreement. How do I do it on Linux with no Mac or iOS?
If you're not developing an iOS/macOS app, you can skip Xcode completely and just use the `swift` CLI, which is perfectly cromulent. (It works great on Linux and Windows.)
FWIW I have written a complete macOS cocoa+swift app in emacs alone without XCode, just using Makefiles. You don't strictly need it.
Totally agree. Xcode is awful. I’m sure that team has a lot to deal with but they’ve produced since really trash software.
I know Xcode might struggle every now and then with some of the things you're talking about and I'm not saying that I don't have any feedback for Apple, but Xcode is one of the most powerful and well designed development and instrumentation environments I've ever used.
My one experience with swift involved calling a macos api not written in swift, but that had ergonomic swift bindings from Apple.
My code was data race free, but the underlying OS primitive wasn’t, so my program crashed out about 10% of the time.
This isn’t really a criticism of swift as a language, but I haven’t had this sort of problem with the rust ecosystem.
Yes! I’m not sure how many people arguing for one or the other have tried both, but it is clear that you know the pain.
I've made a tiny SwiftUI app. It was really difficult to figure out the memory leaks. In fact, I have leaks that I still haven't been able to find. For some reason the heap is fine, but the app continues to allocate virtual memory.
I've thrown Claude and Gemini at the app to try to analyze the code, had them use vmmap and Instruments, asked them run all of the code in a loop to reproduce the leakage — and still it leaks, slowly, tens of megabytes per day.
I'm sure it's something simple starting me in the face. But the fact remains that Swift's sort-of-automatic-but-not-quite memory model still makes it much harder to reason about memory than Rust or even Go.
Most Swift compilation slowness can be avoided by componentizing using packages, plus a few tricks like being explicit with types rather than relying on type inference.
I’m not sure why you’re having so much trouble with SPM though, most people seem to get on well with it.
I still don’t understand the Xcode rant. Using Swift can be done in any LSP-compatible text editor (VSCode, which even has a first-party extension for Swift, but also zed, Sublime Text, etc.)
Unless you’re doing Apple-specific development, you don’t need Xcode.
I do think xcode is the worst IDE I've ever worked in, bar none. Even Eclipse from 2010 was better than xcode from 2025
> Xcode
You don’t need it to program in Swift. I write a lot of it and never open Xcode, my terminal editor with LSP support is fantastic at it.
Xcode truly is terrible.
I’m curious about SPM vs Cargo - are there basic design decisions that make Cargo better or just particularities of thier current states?
> Swift is better for writing UI and servers and some parts of compilers and operating systems.
For UI, why would anyone choose a language that has no automatic GC that can handle cycles?
Look up the language and ARC.
weak delegates seem to work fine...?
I generally like Swift, but async is a mess, it feels like they come up with a new async library every release
I don't really see the advantage of switch statements over match statements.
Writing Swift is really fun! Last year I built a game and a macOS app (now working on another app) to get some proper hands on experience and I was very impressed. Wrote about it here[1].
I'd love for the experience outside of Xcode to get better (even on a mac, developing for macOS/iOS) but I have to say that I didn't find Xcode to be _that_ aweful. I've certainly used worse IDEs, which is partly why I dislike IDEs altogether.
1: https://log.beshr.com/notes-on-swift-from-building-an-ios-ga...
I personally never seen anything as bad as XCode, but granted, I haven't used really old IDEs (always preferred just editors). Last year I built a few small apps using both XCode/Swift and Visual Studio/C# and using MS stack felt like you are living in the future, despite WinUI having a very dated UI syntax.
If you want more convenience from Rust and do not want to mess with Rust borrow checker, you do not really have to switch to Swift: you can rely on Rust reference counting. Use 1.) Rust reference-counted smart pointers[1] for shareable immutable references, and 2.) Rust internal mutability[2] for non-shareable mutable references checked at runtime instead of compile time. Effectively, you will be writing kind of verbose Golang, but keep Rust expressiveness.
[1] https://doc.rust-lang.org/book/ch15-04-rc.html
[2] https://doc.rust-lang.org/book/ch15-05-interior-mutability.h...
It gets really verbose though!
Also, you get the ability to use Rc (non-atomic refcount) as long as you’re not in a multithreaded env. The atomic version is Arc, similar to C++ shared_ptr.
And there are no footguns - i.e. you cannot mistakenly use a Rc across threads - because the compiler will ensure that you aren’t doing this via the Send marker trait.
> There is a perception that Swift is only a good language for Apple platforms. While this was once true, this is no longer the case and Swift is becoming increasingly a good cross-platform language.
How good is the developer experience on a non-Apple platform really? Linux is my primary platform and my perception is, that allmost all of the swift eco system is for Apple. Libraries, tools, documentation, IDEs, tutorials, etc. all assume, that you use an Apple.
Can someone tell me who does not use an Apple-device and uses swift?
I tried doing compiling a few of my Mac CLI tools to Linux. These days, it's faster to run them through an LLM and get quite excellent Go at the other end, and _that_ is much easier to cross-compile.
I have been looking at the new Android support (don't have the link handy) and it's tempting, but I know Kotlin and always developed for Android with a bare Makefile and the JDK, so I don't need any fancy tooling...
It’s not. The Apple devs will tell you it’s a great time on Linux, just like the MS people will tell you the same for C#.
Rust wasn’t designed for any specific platform and you can tell. The ecosystem on Linux especially is fantastic.
Swift has swiftly to manage the Swift compilers to use (equivalent of rustup) and LSP works pretty well. Most of the (open-source) libs that Apple does are cross-platform. I personally take care to make sure my personal libs work on all platforms as well, including Windows(!) (anecdotal, I know…).
All in all it’s not perfect yet, but it’s getting better, with intent to continue in that direction.
My experience is that it is very frustrating. Apple's documentation makes no mention of what works on Linux and its limitations, so you just have to guess or work it out with trial and error.
I tried to write a websocket client: https://willhbr.net/2023/08/23/the-five-stages-of-swift-on-l... Then tried again 2 years later: https://willhbr.net/2025/10/13/the-6-2nd-stage-of-swift-on-l...
Yes, in my experience the Apple bias exists in all the articles and how-tos you read in a way that can trip you up.
It’s been years now but I wanted to create a Set with weak memory in its keys. Everything I read said “oh just use NSHashTable” and I dutifully did (it’s in Foundation) and then when I tried to cross compile it didn’t exist outside of Apple platforms. It’s not as if the import made it clear I wouldn’t be able to use it, but I couldn’t.
Until you get to the Swift concurrency stuff, or you try to use Swift on a backend or non-Apple system - then it’s hot garbage.
If Rust is too low level for you, you can write Go or Kotlin or even something new and fresh like Gleam.
Except I did and it was good. When did you last try?
This article made me actually interested in learning Swift. Anyone recommend a good place to start?
The Swift Book is good for this:
https://docs.swift.org/swift-book/documentation/the-swift-pr...
Riiiiight. No. I'm a Mac user for decades, former Obj-C hacker, have tried and tried again and again to use Swift (and I have quite a few CLI apps written in it), but the thing has been a clusterfuck of paper cuts and very minor but significant changes over the years, and I gave up waiting for it to settle.
And it's not a more convenient Rust. I'd rather use Zig or Go (neither of which are worthy in the eyes of true Crustaceans, but which just get the job done).
No thanks, too tied to Apple and closed source development models.
I really don't understand what's the point of such comparisons. Swift uses subtyping, while Rust uses typeclasses. Even looking only at their type systems, the two are completely different. You can't assume they are similar just because they both use the Latin alphabet.
> Swift uses subtyping, while Rust uses typeclasses. Even looking only at their type systems, the two are completely different.
What does it mean to “use” subtyping vs typeclasses? Swift protocols are essentially typeclasses with associated types, just like Rust traits.
What is "clone-on-right"?
A misspelling of "copy-on-write".
I would tend to disagree; fundamental to Rust is the concept of zero-cost abstraction. Swift does not do that.
I my view, and I might be wrong, many features of Rust are chosen specifically to have the language comply to the zero-cost rule. Such as the ownership model.
The explicit ownership model in Rust also protects one from the footguns of actors and Tasks in Swift. Rust also makes most mistakes in that area a build time error which is not only a huge time saver but also helps one learn and improve in these areas.
Swift also supports the ownership model.
Toady I used GLM 4.7 to port a C++ project of mine to Rust, so I could read and toy with it, to get into the language: https://codeberg.org/RickStanley/agatetepe-rs.
Really interesting results, not sure how well it is written but works. I was quite found of Rust syntax; it certainly is not as convoluted as C++ (in my opinion).
Then I read this article. Since I was already eye-balling Swift for some time, I decided to give it a try and port to it, using Rust implementation as reference, and this time, without much of A. I. assistance, if I could help it.
I'm using an qcow2 Debian trixie arm image in UTM as playground. I found out that there is no packaging for Debian at the time of this writing: https://github.com/swiftlang/swift/issues/60690. No problem! They have a script for installing: https://www.swift.org/install/linux/
But, god damn, the size is huge, 947.6 MiB ! I wonder why is that...Swift is a neat language, but it’s a hard sell for server-side software. The ecosystem is tiny, and there’s nothing you gain from using it instead of Go or Rust for infra / distsys.
Also, it works okay at best with VS Code, and you couldn’t pay me to use Xcode.
Kotlin tried doing similar things to gain adoption on the server side. But server-side programming is a crowded space, and people just don’t like writing distsys code in another JVM language. Swift’s story is a little better on that front.
If you want a quick-and-dirty language, Python and TypeScript do the job. For perf-sensitive, highly concurrent environments, Go is hard to compete against. A lot of ops tooling and infra code is written in Go. For systems programming and embedded code, Rust is a better choice.
So while it’s fun to think about what language X gives you in terms of syntax, in practice it’s rarely enough to pick a language like Swift for your next non-toy backend distsys work.
Also, Apple. Given their stance against free and open source software, I wouldn't be too thrilled to pick a language that works better in their walled garden.
I have been using Swift Vapor for personal projects for awhile and it's great. I kind of regret it now on some projects since I use a lot of Go too and I miss the speed of compiling/testing when I'm using agentic coding (where my goal is to put the agent into virtuous loops leading to a success state) - it just takes longer in Swift.
"Convenience" here basically means giving up semantic precision https://www.alilleybrinker.com/mini/rusts-culture-of-semanti... It's not clear that this is genuinely desirable.
> Rust invented the concept of ownership as a solution memory management issues without resorting to something slower like Garbage Collection or Reference Counting.
This is plain wrong, and it undermines the credibility of the author and the rest of the piece. Rust did not invent ownership in the abstract; it relies on plain RAII, a model that predates Rust by decades and was popularized by C++. What Rust adds is a compile-time borrow checker that enforces ownership and lifetime rules statically, not a fundamentally new memory-management paradigm.
Thank you for saying that. It makes me crazy every time I read that rust invented the concept of ownership…
[dead]
One of the Swift’s worst parts is how Apple keeps putting features in there just for the sake of SwiftUI.
[dead]
I am unconvinced
I have used Swift (stopped about two years ago) and use Rust extensively these days.
People commenting here have mentioned the dreadful Xcode. But if you want to build systems on Apple, without investing a lot in setup, you are stuck with Xcode.
To be clear it's failures as an editor or build system are not the main problems with Xcode (albethey very frustrating when the intermittent problems show up) it is the abject failure of the tooling.
We never got the profiler to produce anything intelligible after days of trying, spread over several weeks.
SwiftUI is not part of the conversation here, and I limit the amount of UI building I do, but it shares all the problems of declarative UI frameworks - mainly "where is the code?". Debugging logic problems is nigh impossible in code you're unfamiliar with
The very worst part of Swift were the thread control. Trivial to overwrite shared memory, "DispatchQueus" (?IIRC?) are a thin wrap of fork, and do nothing but add complications
Swift is probably better than Objective C, the latter being from the 1980s, and things have moved on, if your target is iOS and friends, and you are sure you never want to port, then obeying Apple is a wise business decision. Other than that stay away from it. Use Go for most things, and Rust when you must
I can relate so much to this comment I need to check my house's CO2 level to make sure I didn't write it
Well, the only difference is I'm allergic to Go and just use Rust 99% of the time these days
I’m sorry but reading your comment, you have not understood much about Swift (and GCD).
In particular “"DispatchQueus" (?IIRC?) are a thin wrap of fork, and do nothing but add complications”, in addition to having typo, is as wrong as it can get.
> if you want to build systems on Apple, without investing a lot in setup, you are stuck with Xcode.
If you want to do in Swift the same type of dev you do in go/rust/whatever, Xcode is more than not mandatory, it is generally recommended to use something else, including in the Swift community. Also, you can build native apps in Swift using something else than Xcode (if it is possible to do that in rust for macOS, it is obviously possible with Swift).
> We never got the profiler to produce anything intelligible after days of trying
You mean Instruments? That app is incredibly good, I fail to see how you failed to get anything out of it.
> The very worst part of Swift were the thread control
Already talked about that one, but Swift has async/await now, also.
> Swift takes Rust’s ideas and hides them in C-like syntax.
This example doesn't show me any meaningful difference, and Rust also let's you attach functionality to enums.
Swift tends to overuse enums, for example people would use them instead of namespaces or when they want a function but don’t want to create a class or a struct which in my opinion has always felt like a work-around for language deficiencies.
It also assumes that "C-like syntax" is a desirable thing. Many of the worst parts of Rust syntax (and Swift syntax, and Java syntax, and Javascript syntax, and...) are things it took from C.
MoonBit lang is better "better Rust" than Swift.
Are Core Foundation and Foundation Kit still macOS-only?
I lived and breathed Swift for the first five or six years of its existence. When people compliment it, I assume they haven't used it long enough to hate it.
Swift is a mix of great features, miserable features, and... every other feature that someone on Evolution dreamt up (with the exception of those that would fix the miserable features)
Swift is unique among high-level languages in that the mental effort required to do many simple things rivals that of a low-level language.
I think you have to give some examples.
> Swift on Windows is being used by The Browser Company to share code and bring the Arc browser to windows.
Arc is no longer being developed ( http://www.newswarner.com/2025/05/27/the-browser-company-exp... ) and AFAICT their efforts to port Swift to Windows for its sake have been cancelled.
FWIW, Swift for Windows is a thing (https://www.swift.org/install/windows/), and there's a new Windows-specific workgroup: https://www.swift.org/blog/announcing-windows-workgroup/
Swift has little to no toolchain support for less-common platforms like more recent MIPS, LA and alike. I frequently work and develop on such platforms, so sadly this is the major nay for me to use it.
Kotlin and Swift came in to popularity around the same time. They felt extremely similar at the beginning
Kotlin put a lot of work into proving itself as something more than just a language for Android development, starting first with backend.
It seems like once KMP became viable Swift is just trying catch back up.
Opinions on this will vary, but for me Kotlin’s ties to the JVM and associated tooling is like a ball and chain. The language itself is mostly fine (though it has some weird design hangups compared to Swift), but I really do not enjoy the tooling at all. Gradle for example has me banging my head against the wall way too often.
I can trust the community behind Rust. I cannot trust the company behind swift. They hold a stance that is against open source, and this stance can affect swift at any time, so I wouldn't want to invest into something that could be affected at a whim. It is certainly not convenient.
> Except this switch statement is actually not a switch statement at all. It’s an expression. It doesn’t “fallthrough”. It does pattern matching. It’s just a match expression with a different name and syntax.
Giving a familiar name to a concept which behaves in familiar ways some of the time and surprising ways other times seems like a dirty trick to me, not a convenience.
"The compiler is unable to type-check this expression in reasonable time; try breaking up the expression into distinct sub-expressions" doesn't feel convenient to me.
> Swift doesn’t have a match statement or expression. It has a switch statement that developers are already familiar with. Except this switch statement is actually not a switch statement at all. It’s an expression. It doesn’t “fallthrough”. It does pattern matching. It’s just a match expression with a different name and syntax.
Are there people who see a "match" statement, smash both hands on the table, and shout, "WHAT THE ___ is a ------- MATCH STATEMENT?!!! THIS IS SO $%^&@*#%& CONFUSING!! I DON'T KNOW THAT WORD!! I ONLY KNOW SWITCH!!"
I once wrote a swift server app - hell even did a show hn over here
last time when I used Swift was v3 - and transition from v2 was a little rough.
the language kept adding features becoming a baby C++
if they had invested in bringing outside parties early on - not just iOS etc - swift would've replaced python
To me a big ding on Rust is no native imperative UI toolkit. Last I knew all Rust UI toolkits are declarative, which I’ve found to scale poorly past things like terminals, text editors, some mobile apps, and somewhat simplistic utilities. The more complex your UI gets, the more awkward and ill-suited declarative UI becomes. For something like a replacement for Photoshop or Word or even just Firefox you’re better off with something like AppKit.
Immediate mode GUIs like egui are imperative: https://www.egui.rs/
[dead]
Hmm.
How about Rust is Rust. Swift doesn't really appeal to me as a high level programer. C#, JS and Python largely pay my bills.
The non apple ecosystem just isn't there, and it was never built to be cross platform. If I need to build something I'd probably lean on the languages I already know.
A few times a close friend has wanted an app built and I went with Flutter/Dart + Firebase.
I'm using Godot for games.
Learning a new language, even a similar one is a time investment. In fact I just want better tooling for the languages I already know. Word to UV for Python.
> without resorting to something slower like Garbage Collection or Reference Counting
Hah! But RC is GC! [1]
> Again, this is just deception for those developers coming from C-like languages. Swift’s error handling works exactly like Rust’s behind the scenes, but it is hidden in a clever, familiar syntax.
But the indent heavy syntax is one of the worst parts of exceptions?
Well, that settles it — it is known languages that use snake_case are superior.> This is because Rust is fast by default, and lets you be slow, while Swift is easy by default and lets you be fast.
Good, good, you're onto something here.
> There is a perception that Swift is only a good language for Apple platforms. While this was once true, this is no longer the case and Swift is becoming increasingly a good cross-platform language.
Sigh. But you just said defaults matter, come on. Let me paraphrase: "This is because Swift is for Apple platforms by default, while Rust is cross-platform by default."
[1]: https://www.youtube.com/watch?v=NdREEcfaihg
[dead]
> to do reference counting and “clone-on-right” in your code
Was this article vibe dictated?
I used Swift in versions 1-4, so idk if it's better now, but the syntax seemed fancy and complicated for no reason. So many different ways to do simple things like loops. Infuriating strings lib. Kinda believe the entire language was designed around emojis. And Xcode was a liability.
Rust is more complicated than C but has good reasons for everything it does. It's lower level too, which is fine. If I want high level, I look to JS and not Swift.
Glad to see "Swift is good now" taking the place of "year of the Linux desktop" in a post-Steam Deck world.
>Swift is more convenient Rust
Nah.
... Literally ruined
https://youtube.com/clip/UgkxFZA4XXnXzHyNso0OQ28XU60U1-jdR13...
There’s definitely areas where I agree Swift is more ergonomic.
Parameter defaults, and null short circuiting are two of them.
I find writing Swift is faster for me, and it’s easier to learn for people than Rust. Also Swift interop with other languages is much simpler.
Though there are way fewer resources to learn Swift, and cargo is superior to SPM. And of course rust is better cross platform today, but Swift is closing the gap.
I think they feel like very similar languages overall, and they both influence each other.
Even if it's the same (faster horse?) I would rather use Rust for the fact it's development is not tied to a big tech company which could abandon it if they liked. Yes it could continue on as a fork but it's development velocity would suffer.
If we're going to be concerned about any language languishing due to a lack of support... like, I don't think people are going to put "Apple dropping support" as anywhere near their shortlist. Rust has a higher risk of losing support.
First sentence of the wiki page [1]:
> Swift is a high-level general-purpose, multi-paradigm, compiled programming language created by Chris Lattner in 2010 for Apple Inc. and maintained by the open-source community.
As the article repeats, it is not Apple specific.
[1] https://en.wikipedia.org/wiki/Swift_(programming_language)
A lot of Apple's software is written in Swift now. It's probably not in their interest to abandon the language.
> I would rather use Rust for the fact it's development is not tied to a big tech company which could abandon it if they liked.
Go's development is tied to Google Inc. and is widely used at Google. Same with Microsoft's C# with .NET and Swift isn't very different to this as long as it is open source.
So this really is a moot point.
Interesting. I'm not totally sold - still seems like Swift is quite niche and Apple-specific - but I might take another look.
Also you might want to rework the `Box` example because you don't actually need to use `Box` in that case - the `Vec` already provides indirection.
I was surprised how similar their approach was to memory management. The creator is doing the same thing for Python as they did for Objective-C, making way for a new wave of Swift and Mojo, although we'll have to see if the latter grows to the same success.
> Consider an enum that represents a tree. Since, it is a recursive type, Rust will force you to use something like Box<> for referencing a type within itself. > > enum TreeNode<T> { > Leaf(T), > Branch(Vec<Box<TreeNode<T>>>), > } > > (You could also us Box<Vec<TreeNode<T>>> instead)
This is wrong, you don't need a `Box` here. The Rust compiler forces you to have a layer of indirection, but `Vec` already does that.
Adding on, its also a bit much to say that Swift has a good level of sugar and reference an enum of all things. Swift's union type story is so poor that, instead of properly modeling state, people to this day still use masses of optional types in their views rather than an enum because actually using swift enums and protocols is so painful.
I don't think that is true. Testing with rust 1.92
enum Tree<T> {
Branch(Vec<Tree<T>>), }works just fine, no superfluous Box needed.
You don't need Box here because Vec<T> is already a fixed size handle to heap data.
In one sense the places where the Rust is wrong don't trouble me because I already know Rust well, but in the end they do trouble me because it seems reasonable to assume the Swift is equally wrong but I don't know where and how.
For example "In fact, Swift treats enums as more than just types and lets you put methods directly on it" seems to assume that "just types" don't have methods, which I guess is what you might assume coming from say, C++ but Rust isn't C++ and so of course all of its types, including not only user-defined enums, structures and indeed unions can have methods - but also the built-in primitive types all have methods too.
Or maybe an even closer to the metal example: Rust's pointer provenance APIs get to provide a method on raw pointers which takes a closure to do stuff like hide boolean flag bits at the bottom of an aligned pointer. The fact that you're ultimately going to lower to an XOR on a CPU address register doesn't mean you shouldn't get method syntax, it's the 21st century.You're not wrong, but I think there's a subtle way people still might get confused about `Vec` versus `Box` with the way you've phrased it. I'd argue the important characteristic of `Vec` here isn't that it's indirection but specifically that it's sized at compile time. Compared to a `Box`, it does not provide meaningful indirection around types that are themselves not sized at compile time (e.g. dyn trait objects), and storing them inside a `Vec` itself will require a `Box` or something similar.
Broadly agree but, as is most things, the devil is in the details!
- Xcode. A really rough ide that has a hard time at scale, choking on package refreshes, many targets, and more. It has a special entitlement so you can't even binary patch it if you want to fix it!
- Build systems. Cargo is _much_ easier to work with than SPM.
- Macros support, codegen is still largely done outside of the macro system, which should indicate its use.
- Linter / format support. Yeah, it exists, last I checked it's just a good bit worse.
- Performance. There are MANY performance cliffs in Swift; most can be fixed by a sufficiently determined compiler developer, but at this point we've kinda departed talking about the language as-is.
- Type inference time. Swift's bidirectional type inference causes a ton of choking on complex expressions, which is a real problem with its number one use case, SwiftUI.
- An exacerbating factor on the above, imports are all implicitly module-scoped, meaning that changing a single file means recomputing the types for all files in the module. And because SPM and Xcode have such a rough time with multiple targets, that usually means that a single change can lead to recompiling all Swift files.
- Weirdness around classes and structs? I understand that they had to do it for objc compatibility, but I would've found it much cleaner if they'd just from the start had something replacing class, like a fully-sugared `final class Box<T>` that replaces all uses of class.
I agree that for the most part it _could_ be an easier rust, but between including bidirectional type inference without a cut operator and poor tooling I struggle to find where it's actually easier in cases that you can't just use typescript and dodge all the non-typecheck compilation headaches entirely.
And the licensing agreement. How do I do it on Linux with no Mac or iOS?
If you're not developing an iOS/macOS app, you can skip Xcode completely and just use the `swift` CLI, which is perfectly cromulent. (It works great on Linux and Windows.)
FWIW I have written a complete macOS cocoa+swift app in emacs alone without XCode, just using Makefiles. You don't strictly need it.
Totally agree. Xcode is awful. I’m sure that team has a lot to deal with but they’ve produced since really trash software.
I know Xcode might struggle every now and then with some of the things you're talking about and I'm not saying that I don't have any feedback for Apple, but Xcode is one of the most powerful and well designed development and instrumentation environments I've ever used.
My one experience with swift involved calling a macos api not written in swift, but that had ergonomic swift bindings from Apple.
My code was data race free, but the underlying OS primitive wasn’t, so my program crashed out about 10% of the time.
This isn’t really a criticism of swift as a language, but I haven’t had this sort of problem with the rust ecosystem.
Yes! I’m not sure how many people arguing for one or the other have tried both, but it is clear that you know the pain.
I've made a tiny SwiftUI app. It was really difficult to figure out the memory leaks. In fact, I have leaks that I still haven't been able to find. For some reason the heap is fine, but the app continues to allocate virtual memory.
I've thrown Claude and Gemini at the app to try to analyze the code, had them use vmmap and Instruments, asked them run all of the code in a loop to reproduce the leakage — and still it leaks, slowly, tens of megabytes per day.
I'm sure it's something simple starting me in the face. But the fact remains that Swift's sort-of-automatic-but-not-quite memory model still makes it much harder to reason about memory than Rust or even Go.
Most Swift compilation slowness can be avoided by componentizing using packages, plus a few tricks like being explicit with types rather than relying on type inference.
I’m not sure why you’re having so much trouble with SPM though, most people seem to get on well with it.
I still don’t understand the Xcode rant. Using Swift can be done in any LSP-compatible text editor (VSCode, which even has a first-party extension for Swift, but also zed, Sublime Text, etc.)
Unless you’re doing Apple-specific development, you don’t need Xcode.
I do think xcode is the worst IDE I've ever worked in, bar none. Even Eclipse from 2010 was better than xcode from 2025
> Xcode
You don’t need it to program in Swift. I write a lot of it and never open Xcode, my terminal editor with LSP support is fantastic at it.
Xcode truly is terrible.
I’m curious about SPM vs Cargo - are there basic design decisions that make Cargo better or just particularities of thier current states?
> Swift is better for writing UI and servers and some parts of compilers and operating systems.
For UI, why would anyone choose a language that has no automatic GC that can handle cycles?
Look up the language and ARC.
weak delegates seem to work fine...?
I generally like Swift, but async is a mess, it feels like they come up with a new async library every release
I don't really see the advantage of switch statements over match statements.
Writing Swift is really fun! Last year I built a game and a macOS app (now working on another app) to get some proper hands on experience and I was very impressed. Wrote about it here[1].
I'd love for the experience outside of Xcode to get better (even on a mac, developing for macOS/iOS) but I have to say that I didn't find Xcode to be _that_ aweful. I've certainly used worse IDEs, which is partly why I dislike IDEs altogether.
1: https://log.beshr.com/notes-on-swift-from-building-an-ios-ga...
I personally never seen anything as bad as XCode, but granted, I haven't used really old IDEs (always preferred just editors). Last year I built a few small apps using both XCode/Swift and Visual Studio/C# and using MS stack felt like you are living in the future, despite WinUI having a very dated UI syntax.
If you want more convenience from Rust and do not want to mess with Rust borrow checker, you do not really have to switch to Swift: you can rely on Rust reference counting. Use 1.) Rust reference-counted smart pointers[1] for shareable immutable references, and 2.) Rust internal mutability[2] for non-shareable mutable references checked at runtime instead of compile time. Effectively, you will be writing kind of verbose Golang, but keep Rust expressiveness.
[1] https://doc.rust-lang.org/book/ch15-04-rc.html
[2] https://doc.rust-lang.org/book/ch15-05-interior-mutability.h...
It gets really verbose though!
Also, you get the ability to use Rc (non-atomic refcount) as long as you’re not in a multithreaded env. The atomic version is Arc, similar to C++ shared_ptr.
And there are no footguns - i.e. you cannot mistakenly use a Rc across threads - because the compiler will ensure that you aren’t doing this via the Send marker trait.
> There is a perception that Swift is only a good language for Apple platforms. While this was once true, this is no longer the case and Swift is becoming increasingly a good cross-platform language.
How good is the developer experience on a non-Apple platform really? Linux is my primary platform and my perception is, that allmost all of the swift eco system is for Apple. Libraries, tools, documentation, IDEs, tutorials, etc. all assume, that you use an Apple.
Can someone tell me who does not use an Apple-device and uses swift?
I tried doing compiling a few of my Mac CLI tools to Linux. These days, it's faster to run them through an LLM and get quite excellent Go at the other end, and _that_ is much easier to cross-compile.
I have been looking at the new Android support (don't have the link handy) and it's tempting, but I know Kotlin and always developed for Android with a bare Makefile and the JDK, so I don't need any fancy tooling...
It’s not. The Apple devs will tell you it’s a great time on Linux, just like the MS people will tell you the same for C#.
Rust wasn’t designed for any specific platform and you can tell. The ecosystem on Linux especially is fantastic.
Swift has swiftly to manage the Swift compilers to use (equivalent of rustup) and LSP works pretty well. Most of the (open-source) libs that Apple does are cross-platform. I personally take care to make sure my personal libs work on all platforms as well, including Windows(!) (anecdotal, I know…).
All in all it’s not perfect yet, but it’s getting better, with intent to continue in that direction.
My experience is that it is very frustrating. Apple's documentation makes no mention of what works on Linux and its limitations, so you just have to guess or work it out with trial and error.
I tried to write a websocket client: https://willhbr.net/2023/08/23/the-five-stages-of-swift-on-l... Then tried again 2 years later: https://willhbr.net/2025/10/13/the-6-2nd-stage-of-swift-on-l...
Yes, in my experience the Apple bias exists in all the articles and how-tos you read in a way that can trip you up.
It’s been years now but I wanted to create a Set with weak memory in its keys. Everything I read said “oh just use NSHashTable” and I dutifully did (it’s in Foundation) and then when I tried to cross compile it didn’t exist outside of Apple platforms. It’s not as if the import made it clear I wouldn’t be able to use it, but I couldn’t.
Until you get to the Swift concurrency stuff, or you try to use Swift on a backend or non-Apple system - then it’s hot garbage.
If Rust is too low level for you, you can write Go or Kotlin or even something new and fresh like Gleam.
Except I did and it was good. When did you last try?
This article made me actually interested in learning Swift. Anyone recommend a good place to start?
The Swift Book is good for this:
https://docs.swift.org/swift-book/documentation/the-swift-pr...
Riiiiight. No. I'm a Mac user for decades, former Obj-C hacker, have tried and tried again and again to use Swift (and I have quite a few CLI apps written in it), but the thing has been a clusterfuck of paper cuts and very minor but significant changes over the years, and I gave up waiting for it to settle.
And it's not a more convenient Rust. I'd rather use Zig or Go (neither of which are worthy in the eyes of true Crustaceans, but which just get the job done).
No thanks, too tied to Apple and closed source development models.
I really don't understand what's the point of such comparisons. Swift uses subtyping, while Rust uses typeclasses. Even looking only at their type systems, the two are completely different. You can't assume they are similar just because they both use the Latin alphabet.
> Swift uses subtyping, while Rust uses typeclasses. Even looking only at their type systems, the two are completely different.
What does it mean to “use” subtyping vs typeclasses? Swift protocols are essentially typeclasses with associated types, just like Rust traits.
What is "clone-on-right"?
A misspelling of "copy-on-write".
I would tend to disagree; fundamental to Rust is the concept of zero-cost abstraction. Swift does not do that.
I my view, and I might be wrong, many features of Rust are chosen specifically to have the language comply to the zero-cost rule. Such as the ownership model.
The explicit ownership model in Rust also protects one from the footguns of actors and Tasks in Swift. Rust also makes most mistakes in that area a build time error which is not only a huge time saver but also helps one learn and improve in these areas.
Swift also supports the ownership model.
Toady I used GLM 4.7 to port a C++ project of mine to Rust, so I could read and toy with it, to get into the language: https://codeberg.org/RickStanley/agatetepe-rs.
Really interesting results, not sure how well it is written but works. I was quite found of Rust syntax; it certainly is not as convoluted as C++ (in my opinion).
Then I read this article. Since I was already eye-balling Swift for some time, I decided to give it a try and port to it, using Rust implementation as reference, and this time, without much of A. I. assistance, if I could help it.
I'm using an qcow2 Debian trixie arm image in UTM as playground. I found out that there is no packaging for Debian at the time of this writing: https://github.com/swiftlang/swift/issues/60690. No problem! They have a script for installing: https://www.swift.org/install/linux/
But, god damn, the size is huge, 947.6 MiB ! I wonder why is that...Swift is a neat language, but it’s a hard sell for server-side software. The ecosystem is tiny, and there’s nothing you gain from using it instead of Go or Rust for infra / distsys.
Also, it works okay at best with VS Code, and you couldn’t pay me to use Xcode.
Kotlin tried doing similar things to gain adoption on the server side. But server-side programming is a crowded space, and people just don’t like writing distsys code in another JVM language. Swift’s story is a little better on that front.
If you want a quick-and-dirty language, Python and TypeScript do the job. For perf-sensitive, highly concurrent environments, Go is hard to compete against. A lot of ops tooling and infra code is written in Go. For systems programming and embedded code, Rust is a better choice.
So while it’s fun to think about what language X gives you in terms of syntax, in practice it’s rarely enough to pick a language like Swift for your next non-toy backend distsys work.
Also, Apple. Given their stance against free and open source software, I wouldn't be too thrilled to pick a language that works better in their walled garden.
I have been using Swift Vapor for personal projects for awhile and it's great. I kind of regret it now on some projects since I use a lot of Go too and I miss the speed of compiling/testing when I'm using agentic coding (where my goal is to put the agent into virtuous loops leading to a success state) - it just takes longer in Swift.
"Convenience" here basically means giving up semantic precision https://www.alilleybrinker.com/mini/rusts-culture-of-semanti... It's not clear that this is genuinely desirable.
> Rust invented the concept of ownership as a solution memory management issues without resorting to something slower like Garbage Collection or Reference Counting.
This is plain wrong, and it undermines the credibility of the author and the rest of the piece. Rust did not invent ownership in the abstract; it relies on plain RAII, a model that predates Rust by decades and was popularized by C++. What Rust adds is a compile-time borrow checker that enforces ownership and lifetime rules statically, not a fundamentally new memory-management paradigm.
Thank you for saying that. It makes me crazy every time I read that rust invented the concept of ownership…
[dead]
One of the Swift’s worst parts is how Apple keeps putting features in there just for the sake of SwiftUI.
[dead]
I am unconvinced
I have used Swift (stopped about two years ago) and use Rust extensively these days.
People commenting here have mentioned the dreadful Xcode. But if you want to build systems on Apple, without investing a lot in setup, you are stuck with Xcode.
To be clear it's failures as an editor or build system are not the main problems with Xcode (albethey very frustrating when the intermittent problems show up) it is the abject failure of the tooling.
We never got the profiler to produce anything intelligible after days of trying, spread over several weeks.
SwiftUI is not part of the conversation here, and I limit the amount of UI building I do, but it shares all the problems of declarative UI frameworks - mainly "where is the code?". Debugging logic problems is nigh impossible in code you're unfamiliar with
The very worst part of Swift were the thread control. Trivial to overwrite shared memory, "DispatchQueus" (?IIRC?) are a thin wrap of fork, and do nothing but add complications
Swift is probably better than Objective C, the latter being from the 1980s, and things have moved on, if your target is iOS and friends, and you are sure you never want to port, then obeying Apple is a wise business decision. Other than that stay away from it. Use Go for most things, and Rust when you must
I can relate so much to this comment I need to check my house's CO2 level to make sure I didn't write it
Well, the only difference is I'm allergic to Go and just use Rust 99% of the time these days
I’m sorry but reading your comment, you have not understood much about Swift (and GCD).
In particular “"DispatchQueus" (?IIRC?) are a thin wrap of fork, and do nothing but add complications”, in addition to having typo, is as wrong as it can get.
> if you want to build systems on Apple, without investing a lot in setup, you are stuck with Xcode.
If you want to do in Swift the same type of dev you do in go/rust/whatever, Xcode is more than not mandatory, it is generally recommended to use something else, including in the Swift community. Also, you can build native apps in Swift using something else than Xcode (if it is possible to do that in rust for macOS, it is obviously possible with Swift).
> We never got the profiler to produce anything intelligible after days of trying
You mean Instruments? That app is incredibly good, I fail to see how you failed to get anything out of it.
> The very worst part of Swift were the thread control
Already talked about that one, but Swift has async/await now, also.
> Swift takes Rust’s ideas and hides them in C-like syntax.
This example doesn't show me any meaningful difference, and Rust also let's you attach functionality to enums.
Swift tends to overuse enums, for example people would use them instead of namespaces or when they want a function but don’t want to create a class or a struct which in my opinion has always felt like a work-around for language deficiencies.
It also assumes that "C-like syntax" is a desirable thing. Many of the worst parts of Rust syntax (and Swift syntax, and Java syntax, and Javascript syntax, and...) are things it took from C.
MoonBit lang is better "better Rust" than Swift.
Are Core Foundation and Foundation Kit still macOS-only?
I lived and breathed Swift for the first five or six years of its existence. When people compliment it, I assume they haven't used it long enough to hate it.
Swift is a mix of great features, miserable features, and... every other feature that someone on Evolution dreamt up (with the exception of those that would fix the miserable features)
Swift is unique among high-level languages in that the mental effort required to do many simple things rivals that of a low-level language.
I think you have to give some examples.
> Swift on Windows is being used by The Browser Company to share code and bring the Arc browser to windows.
Arc is no longer being developed ( http://www.newswarner.com/2025/05/27/the-browser-company-exp... ) and AFAICT their efforts to port Swift to Windows for its sake have been cancelled.
FWIW, Swift for Windows is a thing (https://www.swift.org/install/windows/), and there's a new Windows-specific workgroup: https://www.swift.org/blog/announcing-windows-workgroup/
Swift has little to no toolchain support for less-common platforms like more recent MIPS, LA and alike. I frequently work and develop on such platforms, so sadly this is the major nay for me to use it.
Kotlin and Swift came in to popularity around the same time. They felt extremely similar at the beginning
Kotlin put a lot of work into proving itself as something more than just a language for Android development, starting first with backend.
It seems like once KMP became viable Swift is just trying catch back up.
Opinions on this will vary, but for me Kotlin’s ties to the JVM and associated tooling is like a ball and chain. The language itself is mostly fine (though it has some weird design hangups compared to Swift), but I really do not enjoy the tooling at all. Gradle for example has me banging my head against the wall way too often.
I can trust the community behind Rust. I cannot trust the company behind swift. They hold a stance that is against open source, and this stance can affect swift at any time, so I wouldn't want to invest into something that could be affected at a whim. It is certainly not convenient.
> Except this switch statement is actually not a switch statement at all. It’s an expression. It doesn’t “fallthrough”. It does pattern matching. It’s just a match expression with a different name and syntax.
Giving a familiar name to a concept which behaves in familiar ways some of the time and surprising ways other times seems like a dirty trick to me, not a convenience.
"The compiler is unable to type-check this expression in reasonable time; try breaking up the expression into distinct sub-expressions" doesn't feel convenient to me.
> Swift doesn’t have a match statement or expression. It has a switch statement that developers are already familiar with. Except this switch statement is actually not a switch statement at all. It’s an expression. It doesn’t “fallthrough”. It does pattern matching. It’s just a match expression with a different name and syntax.
Are there people who see a "match" statement, smash both hands on the table, and shout, "WHAT THE ___ is a ------- MATCH STATEMENT?!!! THIS IS SO $%^&@*#%& CONFUSING!! I DON'T KNOW THAT WORD!! I ONLY KNOW SWITCH!!"
I once wrote a swift server app - hell even did a show hn over here
last time when I used Swift was v3 - and transition from v2 was a little rough.
the language kept adding features becoming a baby C++
if they had invested in bringing outside parties early on - not just iOS etc - swift would've replaced python
To me a big ding on Rust is no native imperative UI toolkit. Last I knew all Rust UI toolkits are declarative, which I’ve found to scale poorly past things like terminals, text editors, some mobile apps, and somewhat simplistic utilities. The more complex your UI gets, the more awkward and ill-suited declarative UI becomes. For something like a replacement for Photoshop or Word or even just Firefox you’re better off with something like AppKit.
Immediate mode GUIs like egui are imperative: https://www.egui.rs/
[dead]
Hmm.
How about Rust is Rust. Swift doesn't really appeal to me as a high level programer. C#, JS and Python largely pay my bills.
The non apple ecosystem just isn't there, and it was never built to be cross platform. If I need to build something I'd probably lean on the languages I already know.
A few times a close friend has wanted an app built and I went with Flutter/Dart + Firebase.
I'm using Godot for games.
Learning a new language, even a similar one is a time investment. In fact I just want better tooling for the languages I already know. Word to UV for Python.
> without resorting to something slower like Garbage Collection or Reference Counting
Hah! But RC is GC! [1]
> Again, this is just deception for those developers coming from C-like languages. Swift’s error handling works exactly like Rust’s behind the scenes, but it is hidden in a clever, familiar syntax.
But the indent heavy syntax is one of the worst parts of exceptions?
Well, that settles it — it is known languages that use snake_case are superior.> This is because Rust is fast by default, and lets you be slow, while Swift is easy by default and lets you be fast.
Good, good, you're onto something here.
> There is a perception that Swift is only a good language for Apple platforms. While this was once true, this is no longer the case and Swift is becoming increasingly a good cross-platform language.
Sigh. But you just said defaults matter, come on. Let me paraphrase: "This is because Swift is for Apple platforms by default, while Rust is cross-platform by default."
[1]: https://www.youtube.com/watch?v=NdREEcfaihg
[dead]
> to do reference counting and “clone-on-right” in your code
Was this article vibe dictated?
I used Swift in versions 1-4, so idk if it's better now, but the syntax seemed fancy and complicated for no reason. So many different ways to do simple things like loops. Infuriating strings lib. Kinda believe the entire language was designed around emojis. And Xcode was a liability.
Rust is more complicated than C but has good reasons for everything it does. It's lower level too, which is fine. If I want high level, I look to JS and not Swift.