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.
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.
I agree, but I think that it's difficult to spot memory leaks in SwiftUI because it's such a high-level abstraction framework. When working with the Cocoa and Cocoa Touch libraries, it's so much easier to find.
And of course, Apple's UI frameworks != Swift the language itself.
hunting dangling references in a reference counted system is like that.... that's all I can guess is going on here. Good hunting! I wonder if there's a resource debugger? So far when I have really had to look, xcode was suffiicent... but there's likely better out there for finding this kind of thing.
I experienced a similar problem, and upon further investigation, I discovered that it occurred in the parts of the code where Swift and Objective-C are bridged. The problem seemed to stem from either the bridging or an issue within the Objective-C code itself
Perhaps try again and analyze for reference cycles between objects. I agree that ARC has painful subtleties. It existed prior to Swift, being introduced in Objective-C, and is definitely not a perfect memory model.
Personally I avoid using SwiftUI except in bite size chunks like collection view cells. It’s great for that kind of use case but doesn’t scale up well.
I wasn’t of the mind that AppKit/UIKit really needed replacing in the first place, though…
I'm sorry but what exactly are you doing? This is the first time I've ever heard any of this type of reasoning, and well, the fact that you're using AI makes me think you have no clue what you're actually talking about.
If its a reference cycle, instruments will find it. If it is a leak, instruments will find it. However, you seem to be worried about an implementation detail on how you get memory from your CPU which the mach kernel handles for you, and is something you don't quite grasp.
please don't reply with "I asked stupid generator", seriously, what is the actual issue you have?
I mean, even if valgrind ran on MacOS, it may still not give anything meaningful because the debug symbols are probably not going to be the same as that generated by GCC, and even if they were the same, there's still gonna be a bunch of symbols "missing" because of internal swift name-mangling, and even if that wasn't the case, the emitted code might just not be ABI compatible with C anyway.
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.)
There'a great indie app called Notepad.exe [1] for developing iOS and macOS apps using macOS. You can also write and test Swift apps for Linux easily [2]. It also supports Python and JavaScript.
If you hate Xcode, this is definitely worth a look.
Even if you're developing for macOS you can skip xcode. I've had a great time developing a menubar app for macOS and not once did I need to open xcode.
I would avoid it for Linux and Windows. Even if they are "technically supported", Apple's focus is clearly macOS and iOS. Being a second- (or even third-) class citizen often introduces lots of issues in practice ("oh, nobody teenaged that functionality on 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.
Why would you bother using Swift if you're not targeting Apple? I can imagine wanting to use it for something cross-platform that is primarily an ios/macos thing.
But if you don't want to include those I wouldn't pick a language that's under control of a company I don't use.
It's a bit like using c# or powershell on Linux. Yes it can be done and it's helpful for cross platform with windows but I wouldn't consider it a first class citizen.
Agreed. People use any thread mentioning swift to dunk on Apple for X number of reasons with vague details and regurgitated dogma. I get Xcode has quirks I use it everyday believe me I know but it's not that bad that it's unusable.
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'm also wondering how big their programs are that the compile times are an issue. I'm seeing fantastic build times with Xcode 16 and Xcode 26.2 with swift 6.2 it's even better. SPM is also better with the newer version. Most issues can be solved or exposed by closing the window and reopening or going to the package with issues and pressing cmd+s.
Trying to make a .xcframework from SPM is "fun". And getting the Objective-C that are generated, but treated as intermediary artifacts discarded is a bit of a pain.
But I guess the issue here is that .xcframework is an Apple thing, not a Swift thing.
The whole "won’t build if the product / target has the same name as one of its classes" is absolutely ridiculous on the other hand.
Experience with SPM might vary depending on how many dependencies you’ve got. A lot of Apple platform apps are quite thin on third party library use, in which case SPM is probably not a large source of trouble.
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.
I can't say you hear a lot of folks on other OSes with other IDEs saying "I wish I had Xcode". There was a minute when MonoDevelop was trying to emulate Xcode but that must be over a decade ago.
Personally speaking I don’t get the hubbub around Jetbrains and MS IDEs. Like they’re not bad by any means but they have their own sets of idiosyncrasies and bugs… it just depends on which set you happen to run up against most often in your day to day.
+1 I went out of my way to set up a skeleton project that just uses shell scripts to build an app bundle. I really dislike Xcode but Swift itself is actually fun to write.
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 also wish to ask given that uv from Python learnt from cargo,npm and other things. Can it be possible for SPM to have an alternative similar to how uv got made for python too?
(I am not familiar with swift which is why I am asking this question if there's a really big difference between Swift package manager and cargo in the first place to warrant a uv like thing for swift ecosystem. I think someone recently posted a uv alternative for ruby)
SwiftUI is straight up the worst thing Apple has ever shipped. Absolute fucking pile of dogshit. They should be ashamed of themselves. Steve would have fired everyone and I mean that.
It remains the only UI framework I've prototyped something in where I've had to respond to a well paying client with a list of what it (still!) can't do, doesn't do well, and a long list of documentation that does not match the code. I have a sense of integrity so I do this work honestly. There are plenty of devs out there that will happily tell you xyz can be done just so that they're paid to make something they know will be subpar.
You can develop Swift without it. I assume you mean SwiftUI / apple's sdk, which is what most people assume (a note, I'd say, to advocates of Swift who wish not to address SwiftUI: it's the biggest target, and its poor performance on it should speak volumes about the language).
Swift is available for Linux, license is Apache 2.0. There's even swift bindings for some linux ecosystem libraries, e.g. adwaita-swift for writing gnome apps and qt bindings for writing kde apps.
> 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.
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.
> In fact, Swift treats enums as more than just types and lets you put methods directly on it
This section was fairly disappointing, that Rust requires you to put "} impl {" between the `enum` and its methods is... not really an interesting point.
I think the title of the article is... basically correct, and the high-level point that they're both languages with modern type systems, sum types, pattern matching, and so on is good, but too many of the examples were weak.
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 which Swift developers you are talking to, but let the record know I don’t and use enum quite a lot. And I don’t find it particularly painful though a bit verbose at times.
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.
Similarly, the ‘indirect’ keyword can be omitted from Swift example in the blog post, for the same reason. A Swift Array stores its elements out of line, so an enum case payload can be an array type whose element contains the same enum, without any additional indirection.
A vector of boxes is beneficial if you need to move objects around. If each T is 1000B or something, you really don’t want to copy or even do true moves in memory.
Hell, even if you’re not moving things around explicitly, don’t forget that vectors resize themselves. If you use Box, then these resizes will be less painful with large objects.
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.
This makes me think you haven't really tried it ever? Sure writing a hello world is something but, one of the best features of Swift on the server side is that it seamlessly interopts with anything C (and nowadays C++, though that is after my time).
I wrote an entire, well performing backend in Swift because I could just directly plug in to already existing libraries without having ot provide a whole bunch of "FFI" glue.
All the other languages you suggest is something that Swift excels at while staying performant (also none of those have an IDE like Xcode so idk why you even bring it up). Though for actual systems programming I don't think Rust can be beaten by Swift, simply because of its more explicit (and therefore confronting) nature.
We use server side Swift extensively since about 2016 for decent production load and it's easily one of the worst decisions I've ever made.
- C/C++ interop is great but if we wanted to use C/C++ libraries why use Swift at all? It's annoying to interop with them even if there is no FFI and still requires a lot of glue code for memory management etc…
- The stdlib (Foundation) is not identical on all platforms even today. This has been a major thorn as releases constantly have discrepancies and subtle bugs that are hard to diagnose and track down. Even Swift 6.1 broke non UTF-8 string encodings by just returning "nil" on Linux and took until Swift 6.2 to be fixed (nearly a year).
- The compile times are awful, with a large Swift codebase it takes us ~10-20 minutes to compile our backend Docker container and thus deployments to dev take that long and it's only going to keep getting longer as Apple seemingly has no interest in making the Swift toolchain much faster and Swift has a fatal flaw in it's design around bi-directional type inference that ensure it can never be compiled fast.
- Talent is impossible to find. Yes lots of people know Swift for iOS apps but nobody knows Swift for server code and a backend dev is a very different skillset than an app dev.
We chose it because it allowed us to share some domain code between our flagship iOS product and the server with a custom built sync engine but as our platform has grown it's just gotten harder and harder to justify keeping Swift on the server which is why we're actively migrating off it.
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.
In agentic workflows, Go’s fast compiler and simple syntax make things so much easier.
I no longer write Python or JavaScript, even for trivial scripts. Why suffer sluggish performance or tooling nightmares when choosing a typed language no longer costs much?
As for Swift, it’s a harder sell. The docs aren’t there. The libraries aren’t that great. Apple-ism scares away a ton of folks, and the alternatives create less friction.
The target group for server-side software are iOS and macOS developers that also need a server component, thus like the JS folks, they get to use the same programming lanugage.
> 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?
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 suspect that Mozilla being the primary developer and sponsor for many years actually meant that compatibility with all major platforms was prioritised; Mozilla obviously care about stuff working on Windows, and run lots of builds on Windows + I imagine a number of Firefox developers (if not drive) at least own a Windows machine for testing Windows-specific stuff!
I call out Windows because I think generally software people go for Mac > Linux > Windows (although Mac > Linux may be slowly changing due to liquid glass).
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...
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.
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.
This!
Also, for new APIs Apple reduces (or does not provide) Objective-C documentation.
I really tried to love Swift, but in the end I ended up with 1 project using Swift/SwiftUI, and all the other apps I started to write, I rewrote in Zig or Rust, because the Swift compiler kept giving me vague error messages with no hint which Swift file was the culprit or/and which line/column the error was.
> 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!!"
TL;DR — it seems to me that it is less anger from devs at being confused over a Case construct and more an attempt to preemptively soothe any ruffled feathers for devs wanting a traditional Switch.
I think your comment was probably rhetorical, but does address/raise a fairly common issue in designing programming languages. My position on this is that it is less like "WHAT THE ___ is a ------- MATCH STATEMENT?!!! THIS IS SO $%^&@*#%& CONFUSING!! I DON'T KNOW THAT WORD!! I ONLY KNOW SWITCH!!" and instead more like the following (from the language designers POV):
Okay, we want a Case construct in the language, but programmers coming from or preferring imperative syntax and semantics may not like the Case concept. But, they often like Switch, or at least are familiar with it appearing in code, sooooooo: first, we will alter the syntax of the tradition Switch to allow a more comfortable transition to using this functional inspired construct; then second, we wholesale replace the semantics of that Switch with the semantics of a Case. This is underpinned by the assumption the the syntax change is small enough that devs won’t recoil from the new construct, then the larger divergence of semantics will hopefully not produce issues because it is just a small semantic change coated in an most familiar syntax.
Interestingly, the author of TFA seems to be operating under the assumption that the Case construct is an unqualified positive change and sneaking the corresponding semantics into that unfortunate imperative code is a wholly positive goal for the language design.
Without taking a position on the above positivity, I think the maneuvers language designers take while designing syntax and semantics (as exhibited in Swift’s Switch syntax for a Case Expression) is motivated by divergent, and often times strange, priorities and prior assumptions. So, from the 10,000’ view, does enshrining priorities and assumptions, and others like it, as a hard coded facet of the language the right path for languages generally? Should a language seek to be an overall more general framework for programming, leaving a vast majority of the syntax and higher-level semantics to be chosen and instantiated by devs where fit-for-purpose and pros/cons direct its inclusion? Or is the goal for opinionated languages, with or without accompanying sugar to help smooth over differences from other languages, the better path? Is there a ‘happy’ medium where:
1) design goals and forward thinking or experimental syntax/semantics get put in the language as an ‘it’s for your own good’ method for advancing the field as a whole and advancing/optimizing a single dev’s programs in particular;
2) the default position of a language should be as generalized as possible, but with abilities and options for users to specify what advanced, uncommon, or divergent syntax/semantics are utilized in a given program?
We're talking about fallthrough happening by default or not by default. You could call it a "map" construct or a "choose" statement for all I care.
Whether or not you have to write the "case" keyword 10 times is an aesthetic choice.
I don't think this has anything to do with program optimization. On all non-theoretical ISA's I'm aware of, you don't need a JUMP instruction to go to the next instruction. We're debating names.
I'm a Ziguana so my answer to the programming philosophy questions would be that we need a language where the complexity emerges in the code, not in the language itself, and we generally want a shared language that can be read and used by anyone, anywhere. If everyone has their own subset of the language (like C++) then it's not really just one language in practice. If every project contains its own domain specific language, it may be harder for others to read because they have to learn custom languages. That's not to say you should never roll your own domain specific language, or that you should never write a program that generates textual source code, but the vast, vast majority of use cases shouldn't require that.
And, yes, be opinionated. I'm fine with some syntactic sugar that makes common or difficult things have shortcuts to make them easier, but again, if I learned a language, I should generally be able to go read someone's code in that language.
What do you consider "advancing the field as a whole"?
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.
Defaults matter. Owned types are the default in Rust and opt-in in Swift. As a consequence, by default it's safe to assume that any Swift code you fine in the wild isn't making use of owned types.
Yes, it supports it. But is fundamentally not based on the idea of zero-cost abstraction from where I see a lot of Rust features being derived from. So crates I pull in must obey it too - it's not optional (you do have unsafe to watch out for, but that's an easy grep).
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.
Oh god, I hope I read this wrong. I thought Rust finally fixed C/C++'s worst issue which is aliasing, which means that if you pass a struct by pointer to a function, since any number of other mutable references might exist to it, the only correct way to treat it, is to reload/save it to memory every time you access it.
This is obviously unacceptable from a performance point, so compilers have resorted to heavy static analysis, and a bunch of hacks to prove nobody else is actually writing to that memory.
These hacks were brittle, leading to buggy or slow code, which is why C introduced the __restrict__ keyword, that allowed the programmer to tell the compiler that nobody is going to write to said variable, which meant it was now the programmer's responsibility to enforce that. High-perf code is littered with it.
I thought Rust's ownership system prevented mutable aliases, thus it allowed the compiler to automatically tag every pointer with __restrict__ , but if what the article says is right, Rust is bad as C/C++, because there are 1% exceptions to the general rule the compiler enforces.
Rust tags every &mut T and every &T with the equivalent of restrict except for when the T transitively contains an UnsafeCell<T>. Types like Arc<T> and Rc<T> are built on top of UnsafeCell<T>.
Don’t use shared ownership? You get the semantics you want. It’s the norm for the vast majority of things.
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, which is similar to C++ shared_ptr.
And there are no footguns to using Rc. More specifically, you cannot mistakenly use a Rc across threads, because the compiler will ensure that you aren’t doing this thanks to the Send marker trait.
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.
Apple was the primary and only major sponsor of Objective-C, used it as the core foundation of their entire platform, and dropped it like a stone with little warning or ceremony. Yes, being tied so closely to Apple is an existential risk for Swift. One need only look at the quality and trajectory of MacOS to see that Apple isn't a software company, let alone a company that cares about developer experience (Xcode, anyone?). As far as modern Apple is concerned, the primary benefit of Swift is that it produces a tiny bit extra lock-in for iOS apps, by making cross-platform development more difficult.
Rust of all languages, now that it's been majorly adopted by many companies big and small, has a higher risk of losing support over a language developed exclusively by one corporation? I sincerely doubt that.
> 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.
Swift being maintained by the open source community is an illusion. The community was very against function builders. Apple went ahead and did it anyway because they needed it for SwiftUI. The open source community just provides discussion, and Apple gets its way either way.
I know Swift is technically not Apple specific, but it says right there in your quote that it was created for Apple and Apple is the giant weight behind it.
I doubt Apple is in danger of dropping Swift, but if they did it would create a devastating vacuum in the Swift ecosystem.
> 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.
Go has a critical mass that Swift clearly doesn't (i.e. there are many, many companies who have net profits of >$1bn and write most of their server software in Go).
Additionally Google isn't selling Go as a product in the same way as Apple does Swift (and where Google does publish public Go APIs it also tends to use them in the same way as their users do, so the interests are more aligned)...
I have similar concerns about c# as I do about swift.
I'm less concerned about go, because unlike swift and c# it was designed from the beginning to be cross-platform and if anything Linux is the best supported OS. But barely so. Also, if Google were to discontinue support, or change the license, or do something else disruptive, I have more faith that the ecosystem would create a fork to continue the language.
FWIW, my biggest concern isn't that the language would be completely abandoned, it is that the company would diminish or drop support for tooling on OSes and editors and IDEs that compete with the company's products (Mac OS and Xcode for apple, Windows and Visual Studio for MS).
Objective-C had its own open source source implementations, along with a better cross-platform story than Swift has ever had, and yet Apple's abandonment still managed to reduce it to irrelevance.
IMHO your case for a moot point would be stronger if you also mentioned which company you feel is tied to Rust in the same way as the other languages you've mentioned.
Readit News
- 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.
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.
And of course, Apple's UI frameworks != Swift the language itself.
I wasn’t of the mind that AppKit/UIKit really needed replacing in the first place, though…
If its a reference cycle, instruments will find it. If it is a leak, instruments will find it. However, you seem to be worried about an implementation detail on how you get memory from your CPU which the mach kernel handles for you, and is something you don't quite grasp.
please don't reply with "I asked stupid generator", seriously, what is the actual issue you have?
I mean, even if valgrind ran on MacOS, it may still not give anything meaningful because the debug symbols are probably not going to be the same as that generated by GCC, and even if they were the same, there's still gonna be a bunch of symbols "missing" because of internal swift name-mangling, and even if that wasn't the case, the emitted code might just not be ABI compatible with C anyway.
If you hate Xcode, this is definitely worth a look.
[1]: https://notepadexe.com
[2]: https://notepadexe.com/news/#notepad-14-linux-support
Unless you’re doing Apple-specific development, you don’t need Xcode.
But if you don't want to include those I wouldn't pick a language that's under control of a company I don't use.
It's a bit like using c# or powershell on Linux. Yes it can be done and it's helpful for cross platform with windows but I wouldn't consider it a first class citizen.
I’m not sure why you’re having so much trouble with SPM though, most people seem to get on well with it.
But I guess the issue here is that .xcframework is an Apple thing, not a Swift thing.
The whole "won’t build if the product / target has the same name as one of its classes" is absolutely ridiculous on the other hand.
Being explicit with types is very disruptive when used in SwiftUI or TCA.
Errors everywhere with horrible messages that leave you no idea whats wrong
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.
when you mention terminal editor, I think you are a Neovim user right?
Xcode is optional, though its primacy has meant less adoption of Swift's first party LSP and VS Code extension.
(I am not familiar with swift which is why I am asking this question if there's a really big difference between Swift package manager and cargo in the first place to warrant a uv like thing for swift ecosystem. I think someone recently posted a uv alternative for ruby)
Rv, a new kind of Ruby management tool: https://news.ycombinator.com/item?id=45023730
It remains the only UI framework I've prototyped something in where I've had to respond to a well paying client with a list of what it (still!) can't do, doesn't do well, and a long list of documentation that does not match the code. I have a sense of integrity so I do this work honestly. There are plenty of devs out there that will happily tell you xyz can be done just so that they're paid to make something they know will be subpar.
You can also sometimes avoid xcode, see https://github.com/xtool-org/xtool
although, at this point, just use expo!
The license is pretty much Apache 2.0
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.
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.
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.This section was fairly disappointing, that Rust requires you to put "} impl {" between the `enum` and its methods is... not really an interesting point.
I think the title of the article is... basically correct, and the high-level point that they're both languages with modern type systems, sum types, pattern matching, and so on is good, but too many of the examples were weak.
Let me do this:
Instead of There's an existing proposal for this here:https://forums.swift.org/t/re-proposal-type-only-unions/7270...
In what way? My understanding is they're widely used and encouraged.
enum Tree<T> { Lead(T), Branch(Vec<Tree<T>>), }
works just fine, no superfluous Box needed.
Hell, even if you’re not moving things around explicitly, don’t forget that vectors resize themselves. If you use Box, then these resizes will be less painful with large objects.
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 wrote an entire, well performing backend in Swift because I could just directly plug in to already existing libraries without having ot provide a whole bunch of "FFI" glue.
All the other languages you suggest is something that Swift excels at while staying performant (also none of those have an IDE like Xcode so idk why you even bring it up). Though for actual systems programming I don't think Rust can be beaten by Swift, simply because of its more explicit (and therefore confronting) nature.
- C/C++ interop is great but if we wanted to use C/C++ libraries why use Swift at all? It's annoying to interop with them even if there is no FFI and still requires a lot of glue code for memory management etc…
- The stdlib (Foundation) is not identical on all platforms even today. This has been a major thorn as releases constantly have discrepancies and subtle bugs that are hard to diagnose and track down. Even Swift 6.1 broke non UTF-8 string encodings by just returning "nil" on Linux and took until Swift 6.2 to be fixed (nearly a year).
- The compile times are awful, with a large Swift codebase it takes us ~10-20 minutes to compile our backend Docker container and thus deployments to dev take that long and it's only going to keep getting longer as Apple seemingly has no interest in making the Swift toolchain much faster and Swift has a fatal flaw in it's design around bi-directional type inference that ensure it can never be compiled fast.
- Talent is impossible to find. Yes lots of people know Swift for iOS apps but nobody knows Swift for server code and a backend dev is a very different skillset than an app dev.
We chose it because it allowed us to share some domain code between our flagship iOS product and the server with a custom built sync engine but as our platform has grown it's just gotten harder and harder to justify keeping Swift on the server which is why we're actively migrating off it.
I no longer write Python or JavaScript, even for trivial scripts. Why suffer sluggish performance or tooling nightmares when choosing a typed language no longer costs much?
As for Swift, it’s a harder sell. The docs aren’t there. The libraries aren’t that great. Apple-ism scares away a ton of folks, and the alternatives create less friction.
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 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...
I should spend my time writing actual code and ship stuff, not debugging or finding holes in someone else's product.
Rust wasn’t designed for any specific platform and you can tell. The ecosystem on Linux especially is fantastic.
I suspect that Mozilla being the primary developer and sponsor for many years actually meant that compatibility with all major platforms was prioritised; Mozilla obviously care about stuff working on Windows, and run lots of builds on Windows + I imagine a number of Firefox developers (if not drive) at least own a Windows machine for testing Windows-specific stuff!
I call out Windows because I think generally software people go for Mac > Linux > Windows (although Mac > Linux may be slowly changing due to liquid glass).
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 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.
All in all it’s not perfect yet, but it’s getting better, with intent to continue in that direction.
I really tried to love Swift, but in the end I ended up with 1 project using Swift/SwiftUI, and all the other apps I started to write, I rewrote in Zig or Rust, because the Swift compiler kept giving me vague error messages with no hint which Swift file was the culprit or/and which line/column the error was.
YMMV
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 think your comment was probably rhetorical, but does address/raise a fairly common issue in designing programming languages. My position on this is that it is less like "WHAT THE ___ is a ------- MATCH STATEMENT?!!! THIS IS SO $%^&@*#%& CONFUSING!! I DON'T KNOW THAT WORD!! I ONLY KNOW SWITCH!!" and instead more like the following (from the language designers POV):
Okay, we want a Case construct in the language, but programmers coming from or preferring imperative syntax and semantics may not like the Case concept. But, they often like Switch, or at least are familiar with it appearing in code, sooooooo: first, we will alter the syntax of the tradition Switch to allow a more comfortable transition to using this functional inspired construct; then second, we wholesale replace the semantics of that Switch with the semantics of a Case. This is underpinned by the assumption the the syntax change is small enough that devs won’t recoil from the new construct, then the larger divergence of semantics will hopefully not produce issues because it is just a small semantic change coated in an most familiar syntax.
Interestingly, the author of TFA seems to be operating under the assumption that the Case construct is an unqualified positive change and sneaking the corresponding semantics into that unfortunate imperative code is a wholly positive goal for the language design.
Without taking a position on the above positivity, I think the maneuvers language designers take while designing syntax and semantics (as exhibited in Swift’s Switch syntax for a Case Expression) is motivated by divergent, and often times strange, priorities and prior assumptions. So, from the 10,000’ view, does enshrining priorities and assumptions, and others like it, as a hard coded facet of the language the right path for languages generally? Should a language seek to be an overall more general framework for programming, leaving a vast majority of the syntax and higher-level semantics to be chosen and instantiated by devs where fit-for-purpose and pros/cons direct its inclusion? Or is the goal for opinionated languages, with or without accompanying sugar to help smooth over differences from other languages, the better path? Is there a ‘happy’ medium where:
1) design goals and forward thinking or experimental syntax/semantics get put in the language as an ‘it’s for your own good’ method for advancing the field as a whole and advancing/optimizing a single dev’s programs in particular;
2) the default position of a language should be as generalized as possible, but with abilities and options for users to specify what advanced, uncommon, or divergent syntax/semantics are utilized in a given program?
Whether or not you have to write the "case" keyword 10 times is an aesthetic choice.
I don't think this has anything to do with program optimization. On all non-theoretical ISA's I'm aware of, you don't need a JUMP instruction to go to the next instruction. We're debating names.
I'm a Ziguana so my answer to the programming philosophy questions would be that we need a language where the complexity emerges in the code, not in the language itself, and we generally want a shared language that can be read and used by anyone, anywhere. If everyone has their own subset of the language (like C++) then it's not really just one language in practice. If every project contains its own domain specific language, it may be harder for others to read because they have to learn custom languages. That's not to say you should never roll your own domain specific language, or that you should never write a program that generates textual source code, but the vast, vast majority of use cases shouldn't require that.
And, yes, be opinionated. I'm fine with some syntactic sugar that makes common or difficult things have shortcuts to make them easier, but again, if I learned a language, I should generally be able to go read someone's code in that language.
What do you consider "advancing the field as a whole"?
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.
[1] https://doc.rust-lang.org/book/ch15-04-rc.html
[2] https://doc.rust-lang.org/book/ch15-05-interior-mutability.h...
This is obviously unacceptable from a performance point, so compilers have resorted to heavy static analysis, and a bunch of hacks to prove nobody else is actually writing to that memory.
These hacks were brittle, leading to buggy or slow code, which is why C introduced the __restrict__ keyword, that allowed the programmer to tell the compiler that nobody is going to write to said variable, which meant it was now the programmer's responsibility to enforce that. High-perf code is littered with it.
I thought Rust's ownership system prevented mutable aliases, thus it allowed the compiler to automatically tag every pointer with __restrict__ , but if what the article says is right, Rust is bad as C/C++, because there are 1% exceptions to the general rule the compiler enforces.
Don’t use shared ownership? You get the semantics you want. It’s the norm for the vast majority of things.
Nope, you just use wrapper types (which you should anyway).
And there are no footguns to using Rc. More specifically, you cannot mistakenly use a Rc across threads, because the compiler will ensure that you aren’t doing this thanks to the Send marker trait.
> 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)
I doubt Apple is in danger of dropping Swift, but if they did it would create a devastating vacuum in the Swift ecosystem.
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.
Additionally Google isn't selling Go as a product in the same way as Apple does Swift (and where Google does publish public Go APIs it also tends to use them in the same way as their users do, so the interests are more aligned)...
I'm less concerned about go, because unlike swift and c# it was designed from the beginning to be cross-platform and if anything Linux is the best supported OS. But barely so. Also, if Google were to discontinue support, or change the license, or do something else disruptive, I have more faith that the ecosystem would create a fork to continue the language.
FWIW, my biggest concern isn't that the language would be completely abandoned, it is that the company would diminish or drop support for tooling on OSes and editors and IDEs that compete with the company's products (Mac OS and Xcode for apple, Windows and Visual Studio for MS).