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.
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.)
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.
The main problem I have with the language is compile times. Rust is good at many things, but not that.
Xcode is optional, though its primacy has meant less adoption of Swift's first party LSP and VS Code extension.
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.
> imports are all implicitly module-scoped, meaning that changing a single file means recomputing the types for all files in the module
i've noticed this too... i wonder if doing scoped importing helps with this for example: import struct MyModule.MyStructMost 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.
> 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.
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
I’m curious about SPM vs Cargo - are there basic design decisions that make Cargo better or just particularities of thier current states?
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.
Not mentioning the fact that Swift is nonexistent outside of the Apple ecosystem, and worse, Apple is explicitly not supporting it outside of the Apple operating systems.
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.
Xcode truly is terrible.
And the licensing agreement. How do I do it on Linux with no Mac or iOS?
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.
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.