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.
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?
- it adds locking to almost every line of code using classes
- anytime you start holding complex references to classes you get cycles which will not be released
- it’s extremely hard to debug. You have to capture memgraphs at runtime and track dependencies
- it coexists with old systems like auto release pools so resources are still not released when all references go away
Try to implement a linked list in swift and you’ll get a sense of how absurd this is. And remember linked lists are a special case of graphs.
It does not count under private memory, so I assume mapped but unused. The last time I asked Claude, it said confidently it was a bug in Swift's networking stack, which I doubt.
That’s the great thing about indiscriminately scraping the internet for knowledge.
I’ll bet Claude was channeling some Reddit guru dripping with swagger born from knowing their understanding of coding is far more advanced than most big-shots in the field— especially impressive because they only wandered into /r/LearnProgramming for the first time several months prior.
Awesome, can you also grab a memgraph or something when it’s leaked a bunch of memory (and maybe put it in a GitHub issue)? I can try it but I don’t really use CircleCI so I’m not confident I can reproduce the issue.
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.
I'm working on Valgrind on macOS, integrating Louis Brunner's work and trying to add a few more fixes. In 2025 support for macOS Intel 10.14, 10.15 11 and 12 was added. Intel macOS 13 is a bit harder of a nut to crack. And I have lots of issues with ARM, particularly building and testing on anything older that macOS 15.
Swift name-mangling will be an issue. Valgrind's name demangler comes from GNU binutils libiberty which does not support Swift AFAIK.
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.)
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.
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.
So wait this thing is real? Calling it notepad.exe gave me the impression that it's just an elaborate joke about how you can code any program in Notepad...
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.
I was talking about this at a party this afternoon (yes, I do go to the most interesting parties, thanks) and while Scheme is acceptable the Common Lisp is not because it's not OK to go without boolean primitives. Types are a good idea, if you have types the simplest is clearly the boolean, so start there.
I believe firmly that there should be a single true value, which we might reasonably name true, and a single false value, false, other values aren't booleans, so it's no more reasonable to ask whether an empty string is false, than to just forget to close the quote marks on a string. What we wrote isn't a correct program.
Common Lisp is actually a great language. The SBCL implementation has a good compiler that produce reasonably fast code, and it's under active development.
The only real drawback to common lisp is the fact that the library ecosystem is practically non-existent.
>I t's a bit like using c# or powershell on Linux… but I wouldn't consider it a first class citizen.
C# is very very much a first class citizen on Linux. It may not be native, but you can run binaries on Linux without needing the runtime when you compile it to target the platform.
I wrote a couple of monoservices on my Mac using c# which ran perfectly on my Microk8s cluster on Linux.
I have nearly a decade of experience building .NET C# solutions on Linux and lately also on Mac, with almost everything hosted on Linux via Docker. I’m not sure what’s still missing for it to be accepted into the "first class citizen" club by the Linux elite.
> What company is using Swift outside of Apple-specific development?
Skip allows to "Build truly native iPhone and Android apps with Skip" so technically skip runs swift on android which is outside of Apple-specific development.
They also recently got open source from their closed source model prior from what I can tell
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.
> I get Xcode has quirks I use it everyday believe me I know but it's not that bad that it's unusable.
It's not unusable, but it's not that great either. When I have a project that requires Xcode I certainly don't look forward to it the way I do such as wehn I have a project that doesn't need any specific IDE.
As a sidenote; I recently (1 year ago, maybe?) did a C project in Eclipse, and was blown away but just how snappy, quick and, utlimately, enjoyable it was compared to VS Code.
Yeah, so I tried XCode with a couple of years ago. Within 2 hours of working on my very first project, it somehow corrupted either my project's metadata and/or its own internal preferences so badly that it would no longer launch - it would just crash to Desktop instantly. Literally the most unusable application I've used in recent memory!
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.
As your app scales, you're going to want to break out different parts into their own packages in order to keep compile times in check, so you're gonna be forced to go through SPM unless you use tuist or bazel.
My problem with it is that I want to use C libraries. And I would (like) it to handle that as much as possible. But SPM can't use vcpkg packages or call CMake stuff (at least, not trivially), so it's extremely hard to use on non-Apple platforms. Which honestly is it's killer for me. It's still so, so Apple focused.
What is a CMake-built swift package to begin with? You're mixing build systems and expecting them to co-exist or what is the exact problem? I've done a lot of weird swift things so might be able to point you in the right direction.
E.g.: referencing a vcpkg-built package (without pkgconfig because not all packages have those files). Or telling SPM "Hey, I have this package which uses the cmake build system, and I want you to link to it and auto-generate module maps for it, and get the include directories from cmake". Things like that. So for me anyway it makes using swift painful. The same thing goes in reverse: using SPM packages from cmake (although this is more a cmake issue).
I'm just talking about having some mechanical sympathy for the compiler such as understanding where the constraint solving problem space gets very large.
I wasn't saying use explicit types everywhere, but giving the compiler a hint every now and then to make things faster just makes sense. The Swift compiler is very complex and of course there are edge cases where it struggles with legal syntax, such as large expressions with many operators.
With SwiftUI it's arguably more important because view builders already put a lot of strain on the compiler.
You can't really easily use explicit types in much of idiomatic SwiftUI. The expression that the compiler is trying to solve is really complicated, I agree, but the solution to that is either changing how SwiftUI is architected or restricting how the language built on SwiftUI infers types.
It's been a while since I've Swifted but it was mostly with combinations of nested generics, lambdas, and literals. Annotating the type of the variable those were assigned to could improve performance a lot.
You don't need to add an annotation on `let foo = bar()` where bar is a function that returns `String` or whatever.
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.
How many of those people who spend their time using other IDEs on other OSs (where Xcode doesn't run) spend any amount of time using Xcode and therefore have the requisite experience to be able to know that it's generally excellent?
And when you say "you hear", you really mean "you", not "me". I hear it a lot.
I mostly work in games where Xcode is an all too common chore to pick up from time to time because Apple changed the rules on something or other to get an iOS build out. Usually I find that xcode isn't helpful at all in solving these problems. You need to dig through guis because it will not just trivially point you to the text file like VS or Jetbrains would.
It's certainly not a pleasant treat to pick the short straw.
Beyond that, I work with plenty of folks who have dabbled in xcode for mobile or on the side and it's just not seen in that great a light.
Meanwhile, I find that people who love xcode are all in and don't really give alternatives a chance at all (because when you have to use xcode, there isn't an alternative).
Even in this comment chain, we're rejecting other's opinions outright instead of talking about killer features xcode has that others fail at.
Hasn't everybody at least tried everything significant just because? Even the most non-apple developer must have at least checked it out on a friends laptop or something just to be informed of the state of their own business.
If there are developers who are that incurious, all I can say is I don't understand them.
> Hasn't everybody at least tried everything significant just because?
No, not in the slightest. I would call this one the most dangerous and unfortunate fallacies that so many intelligent people have ever accepted and been cheated by. If it were true, you'd know everything important there is to know, and be a master of philosophy, and would have many answers to some basic questions which most people have been told have no good or concrete or verifiable answers.
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.
What version did you use? What errors did you see? Don't get me wrong, I've spent 20 years with it, and there was a learning curve - but isn't that the case with many good tools? Again, don't get me wrong, I have some feedback for Apple, and there's a reason why we affectionately call it a harsh mistress. But that doesn't mean it's somehow not one of the best designed, best functioning, and most powerful suites for programming with certain other incidentally very well engineered SDKs etc. And yes, things may have gone downhill a little bit, especially at the scale they're at now. If we could talk about Xcode of, say, 2014, it'd be a less ambiguous conversation.
+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.
The funny thing about the low effort parent comments is the truth - wikipedia lists that there are more release builds of swift of linux than for macOS. Granted they were bug fixes but still.
> 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.
I think Swift enums are really well designed, but SwiftData doesn't really support them unfortunately and Observable has problems with reactivity and enums (works on iOS not macOS I've found).
So lots of optionals might well be the better path here.
It's worth pointing out that the two examples that you're writing are actually strictly different, and not just "better syntax for the same thing". (This is assuming `String | Int` works as in Python, and the second example works as in Rust.)
To understand the difference, `String | String` is just `String`. It's a union, not a sum type. There's no tag or identifier, so you cannot distinguish whether it's the first or the second string.
If this sounds pedantic, this has pretty important ramifications, especially once generics get involved.
To provide a concrete example, this bit me in a typescript codebase:
type Option<T> = T | undefined
function f<T>(value: T): Option<T> { ... }
let thing: string | undefined = undefined;
let result = f(thing);
Now imagine the definition of Option is in some library or other file and you don't realize how it works. You are thinking of the Option as its own structure and expect f to return Option<string | undefined>. But Option<string | undefined> = string | undefined | undefined = string | undefined = Option<string>.
The mistake here is in how Option is defined, but it's a footgun you need to be aware of.
I guess I just want to be able to do something like this in Swift:
let x: String | Int
switch x {
case let value as String:
// handle String value here
case let value as Int:
// handle Int value here
}
There's one more thing about TypeScript-style union types: string literals. I think it's great to be able to do
type Options = "option_1" | "option_2" ... "option_n"
And subsequently I could use
let t: Options
switch t {
case "option_1":
// handle `"option_1"` case here
...
case "option_n":
// handle `"option_n"` case here
}
I think this is more programmer friendly than requiring an out-of-line definition of a new `enum`. Sometimes you just want to write some code, you know?
Hijacking your comment because this is a common point that's made on the superiority of Swift syntax against the union syntax.
At least with |, you're attempting to model the state space. You're saying "this is one of these things." You might get the exhaustiveness wrong, but you're in the right ballpark.
As it's normally done right now, the Swift developer with five optional properties is modeling state as "maybe this, maybe that, maybe both, who knows, good luck." which is just worse than a bar. If you need to discriminate explicitly, add a `__kind` field!
So long as you have structurally typed structs (as TypeScript does), you can do stuff like {foo: string} | {bar: string} to the same effect as type constructors if and when you actually need it.
At the same time, how often do you really need (Just (Just (Just ...)))?
If you look at most swiftui views, there will be a mass of optionals, rather than enum cases for every possible state that the view can occupy and a state machine transitioning between each state.
If you actually try and write it all out (like go full-on and use TCA to model all the states and actions such that all and only valid states can be represented in the state types) the compiler is going to have a hard time, you're going to write masses of boilerplate, and just in general it's much rougher than zustand and expo.
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.
> - 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).
sad, I was doing server side around v4/5 and this was the biggest issue at the time for me (lots of stuff was not implemented and you only found out at runtime). that this is still a problem is very disappointing...
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).
Is liquid glass really that bad? I left Mac years ago due to other annoyances. It was my daily driver for a decade and change. But I couldn't get used to the iOSification and the dependence on apple cloud services for most new features. When I started with macOS jaguar it was just a really good commercial UNIX. It got even better with Tiger and leopard.
But the later years I spent every release looking at new fancy features I couldn't use because I don't use apple exclusively (and I don't use iOS at all, too closed for me). So almost no features that appealed to me while usually breaking some parts of the workflow I did use.
While I did hate the 'flat' redesign after Mavericks that on its own was not really a deal-breaker though. Just an annoyance.
I'm kinda surprised liquid glass is so bad people actually leave for it. Or is it more like the last drop?
No, but every release of MacOS has a noisy minority declaring it, or some features of it, as the end of Macs. Some people will genuinely hate it in the way that nothing can be universally loved, some people will abandon Macs over it, most people don't feel strongly about it at all.
Maybe there's some people out there that love it, even.
I can barely tell the difference between the Mac I use that's been upgraded, and the Mac that hasn't due to its age, because I'm not spending my time at the computers staring at the decor. The contents of the application windows is the same.
I don’t like it, but I think the claims of mass exodus are unlikely.
It feels a lot like the situation when Reddit started charging for their API: Everywhere you looked you could find claims that it was the end of Reddit, but in the end it was just a vocal minority. Reddit’s traffic patterns didn’t decline at all.
Liquid Glass really is that bad. Not because the visual design is especially bad (not my cup of tea but it's okay); but because all of macOS is now incredibly janky. Even Spotlight is a janky mess now with lots of broken animations.
It's unfinished. For example, the more rounded windows would require that scrollbars or other widgets are more inset and things like that. The system doesn't seem to handle this automatically, so many apps look broken, even Apple's first party ones.
This. We ported a huge component, an ASP.NET server hosted Windows to Linux (/w Docker). We did the initial migration in a couple of days, and only after a couple of months, we basically managed to bring all production installs to Linux.
It only took a year, and everyone works exclusively with devcontainers, and we allow devs to experimentally pick Linux and Mac laptops.
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.
Thanks for the answer, that sounds reassuring. I have another question, from what you said, it sounds like you remove restrict from the whol argument, but technically, afaict, the Rust borrow rules still prevent anything inside those structs getting aliased, with the exception of the stuff inside UnsafeCell<> (even with Rc<> the underlying value cannot be aliased, only the reference counter).
Does Rust/LLVM track aliasing to this degree, or is it all or nothing, like if you have a UnsafeCell anywhere, the whole type is excluded from restrict?
I am not sure off the top of my head, to be honest. https://news.ycombinator.com/item?id=46616616 was a thread where I was talking about this sort of thing previously, you could probably adapt those code examples and get an answer.
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.
People still write applications in Objective-C (e.g., see Transmission [1]), and the language is still maintained to support the latest OS. If anything, Apple being the largest sponsor of Objective-C would suggest that you get greater vendor lock-in out of it than Swift, since you can at least use the latter outside of Apple platforms (e.g., on a server).
Although the only framework that was developed in Objective-C after Swift got introduced was Metal, anything else is mostly maintenance and incremental improvements.
"and dropped it like a stone with little warning or ceremony"
What?! This is complete nonsense. Swift was introduced 11 (!) years ago and it was clear from day one that it was going to be the future. Every single year since the introduction there were clear messages and hints in documentation and WWDC that Swift is in and Objective-C will _eventually_ be out.
Little warning? Maybe if you kept your eyes closed the past 11 years.
And do not forget that today you can still write apps in Objective-C.
Whether or not Apple still has legacy pieces in Objective-C or still allows you to write apps in it is not the issue. The point here is that Apple shadow-dropped Swift and shifted essentially all of its development priority away from Objective-C in a matter of months.
I'm old enough to remember when Objective-C was a real and thriving (if niche) language. I remember all the buzz when automatic reference counting was the next big thing, pushed heavily by Apple and taking center stage at WWDC. And since the year Swift came out, Objective-C has joined Cobol in the category of zombie languages: the living dead with plenty of entrenced codebases but with nothing to look forward to but a continued slide into technological irrelevance.
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.
> The community was very against function builders.
Scanning the multiple review threads, that doesn't appear to be the case. According to the acceptance post, the community was overall positive about the feature but expressed concerns over the attribute naming, which was renamed in response.
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)...
> Additionally Google isn't selling Go as a product in the same way as Apple does Swift
Hmm, Apple isn't selling Swift as a product either; it's literally what they needed for their own platform, much like how GOOG needed Go for their server works.
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).
> 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
No it wasn’t. There were so many foot guns for windows and in fact to this day you cant use CGO with MSVC (insane to me).
I can’t even say with a straight face today that Windows is the best supported OS for C#, because it’s not true
Microsoft’s market position is reliant on Linux and access to Linux development to keep Azure competitive. Cross-platform capabilities on the .Net VM are critical to compete with the JVM and associated databases. C# has been windows-first for a while, but the core cross-platform capabilities are not going to disappear, the tooling is all CLI based/capable now, the entanglements tend to be platform and service based.
That said, F# was years ahead of C# in features C# is still chasing, and is driven mostly by the open source community. That community is more in academic and finance areas where Linux-first is common. The language is standardized and plugged into VM improvements over time.
Frankly, I see the lesser degree of entanglement with MS corporate interests as a boon for the language and its ecosystems long-term utility.
From what I understand, LSP support for c# isn't very good, and is from third parties, not MS themselves, because they want you to us Visual Studio on Windows.
The problem is that it's closed source, and its license specifically prohibits its use with anything other than VSCode. Unfortunately, this is becoming the usual modus operandi for first-party Microsoft extensions for VSCode for all the talk about how they "love open source".
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.
That's progress over where it was a year ago. But the almost complete absence of packages that run on Windows makes the progress made so far more of a curiosity than a usable option--alas. I'd use Swift in a heartbeat if it had even a semblance of a decent ecosystem on Windows.
I’ve done both Swift and rust for Linux applications (symbolic analysis tools and compilers, not web stuff or other server apps). I have to say, I’m torn after building a couple moderate (10-30k SLOC) scale tools in both. I prefer swift since I feel like I’m working at the abstraction level I prefer and letting the ARC stuff take care of memory for me. Rust isn’t so bad, but it does make me think more about things that I don’t when I’m in Ocaml or Swift. Rust has better tooling: the LSP support makes life nice in emacs. Compiler feedback and clippy : super useful. Not a fan of the high usage of crates (I’m in the paranoid about supply chain camp). Swift felt like it shipped with more batteries included. I think the main factor is the people side: however much I like swift, I’m more likely to find rust people in my world. I’m rooting for swift though: the world has room for more than one memory safe C++ successor.
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.
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.
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
Yeah. You can bind C in swift. You can expose C interfaces from Rust. Write non-iOS code in Rust, then bind. Now you have iOS support with common client code in Rust.
You can compile Rust to WASM. You can run Rust on the backend. It's gaining popularity on k8s for memory consumption. You can write music visualizers in Rust. You can pivot to killer drones or embedded in Rust. It has very few foot guns compared to C and all of the advantages of C.
The people who want Swift to succeed off of Apple hardware are basically waiting for someone else to do it. Rust users will just invade Apple from every side. It is very clear which platform is the better investment of anyone's time.
I can't believe I'm even wasting keystrokes thinking about this. I saw a bunch of upvotes and can only imagine this has to be wishful thinking from Swift users.
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.
Not very well known, but Swift has two builtin concurrency systems (in addition to the very well known async/await for parallelism): async let (not very flexible) and task groups (much more so).
Leptos etc. WASM is mature enough to just go for it. Same code sharing arrangement as using TS on the backend but using the backend language on the frontend instead.
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.
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.
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.
It's been a while, but the one I remember with the most horror was dealing with Enums, and Enum payloads. Since Swift is statically-typed, many 'type union' situations end up becoming difficult problems. The question usually boils down to thinking about choosing one of (a) Enum with Payload (b) Generic (c) Type erasure. Nearly anything technically is do-able, but I wasted many hours (ie: repeatedly, not until I figured out the 'right way' for every situation) deliberating over how!
I guess my perspective is that I usually have to plan out my programs regardless of what language they’re in so I don’t really view it as being similar?
I frequently was surprised to find some simple part of a program actually required me to sit and plan for several hours.
It's perfectly normal in programming to encounter domain problems that take longer than one predicted, or to plan ahead with pseudo code, proofs of concept, class diagrams, etc.
What is abnormal is, over and over again, to find oneself utterly stumped on how best to implement something very basic. At least, it's abnormal when using a high-level language.
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.
> 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.
So creating more confusion and losing the devs who are not aware (so would prefer a plainer language) is somehow more convenient and a masterclass in... deception (a positive since when)?
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.
> 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.
"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.
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.
If I were to draw a flow chart for selecting a language for a new project the first question would be "am I targeting only Apple platforms". If the answer is yes then the choice is Swift, if the answer is no then Swift is crossed off the list.
Outside of the Apple ecosystem it's going to be friction all the way. There are better choices.
I was really taken in by this premise a while back so I tried building some side projects with server side swift on my windows machine inside WSL.
I really wanted to like it, but the experience was terrible, from the editing side (with vscode) all the way to the performance of existing frameworks (tried both Vapor and grpc-swift-2).
Just forget everything you've learned about it previously, use 6.2+, non isolated by default and every upcoming feature turned on.
And your intuition will be spot on.
> By default, a Rust program is much faster than a Swift program. This is because Rust is fast by default, and lets you be slow, while Swift is easy by default and lets you be fast.
So what do you need to do to make Swift as fast as Rust?
In the long run https://github.com/google/crubit will very likely solve this for Rust even if it's a bit specific to Google's use cases right now as per readme.
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.
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.
> 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."
I refuse to be locked into a platform, and I dislike languages that obscure memory management (ARC). Thus, Swift isnt on my radar. A couple of iOS apps I developed in the past used c++ for 99% of code (OpenGL GUI), with 2 mm files to link to AppKit. These days I’m on Vulkan and dont bother with iOS (MoltenVK is just a bridge too far for me, and yes I did get a prototype running, but it just takes way too long to start in XCode while debugging).
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 is OK, but with the introduction of SwiftUI, we see some hypocrisy.
We were all told to "prefer structs" over classes in Swift, but structs are always passed by value.
We're also told to maintain "one source of truth" (which I'm sure a lot of us did anyway). But you can't do that when you're copying stuff all over the place.
So now what? I got so sick of trying to figure out how to pass structs into views for modification by the user that I made everything a class. What a relief. Now I could get back to work on functionality instead of constructing absurd gymnastics to get altered data back from a view.
I find the whole "structs are passed by value, classes by reference" thing hokey as hell and poor style. People reading the code don't know if the called function can change the passed-in object or not; they have to go see if it's a class or a struct. Lame.
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.
I mean emojis specifically. Python or JS strings are designed for unicode chars. Swift made it about grapheme clusters, which are possibly a valid edge case for like Arabic emphasis marks but not something they'd be motivated to center the entire strings behavior around if it weren't for emojis.
Weird part is the Swift way was still annoying even in cases where I wanted to manipulate strings with emojis very often. Had to build some custom pre-indexed string (just an array of 1-cluster Swift strings), cause find/replace/split/etc was too cumbersome and inefficient otherwise.
I think Swift made the right choice, though: it’s rare that you’d want to slice a grapheme. Usually you don’t have to build an index if you take a step back and design the algorithm around the indexing model.
That's the thing, there is no indexing model. Every string operation is an O(N) seek. But even if you don't care about performance, it's just cumbersome.
Looking at the SO questions for simple things like finding the position of a substring, it also lacked a lot of typical built ins until Swift 5. But that was like 5 years after GA.
There's definitely an indexing model, it's just that it's similar to that of a linked list. You can do all sorts of useful operations on a linked list. Not everything is O(n) in this world.
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).
> 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.
Swift started out pretty nice but they've added too much Liquid Glass since then, the type system constraint solving madness and forcing actors down everyone's throat come to mind.
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
I am starting a new project, which requires to be GUI primarily for macOS, but also Windows.
Swift is a lovely language, but had to go with C#+Avalonia, which can give me truly multi-platform app. If only SwiftUI was properly supported on Windows, that would be great.
For now, .NET/C# + Avalonia seems the most convenient way to write Desktop apps, well, if you don't want to pay for Delphi ;)
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.
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…
Sorry, I did mean AppKit here!
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?
They said they made a "small swiftUI" app that leaks memory. From their shared link there is no SwiftUI at all. No clue....
The memory management is almost broken. They decided not crashing was better than mashing memory.
Memory management in Swift is almost broken? How so? This is a fascinating assertion, and I’d love to learn more.
- it adds locking to almost every line of code using classes - anytime you start holding complex references to classes you get cycles which will not be released - it’s extremely hard to debug. You have to capture memgraphs at runtime and track dependencies - it coexists with old systems like auto release pools so resources are still not released when all references go away
Try to implement a linked list in swift and you’ll get a sense of how absurd this is. And remember linked lists are a special case of graphs.
What's the issue if it allocates virtual memory?
Having my app consume 300GB of virtual memory after running for a week is not ideal.
Is it actually resident or is it just mapped but unused?
It does not count under private memory, so I assume mapped but unused. The last time I asked Claude, it said confidently it was a bug in Swift's networking stack, which I doubt.
That’s the great thing about indiscriminately scraping the internet for knowledge.
I’ll bet Claude was channeling some Reddit guru dripping with swagger born from knowing their understanding of coding is far more advanced than most big-shots in the field— especially impressive because they only wandered into /r/LearnProgramming for the first time several months prior.
This guru's comment probably started with "I'll bet" too.
I see what you did there.
Mapped but unused memory is imaginary (at least, on modern UNIX systems). It's not actually using any physical RAM.
That is true, but I don't see other applications consuming ever-increasing amounts of virtual memory, so to me it suggests a bug.
Well, depends. Not always zero but in a good implementation not more than a few bytes per allocation, at most (if not zero).
Swift does not really have a networking stack
I've been out of the feature factory loop for a little while, but something tells me reviewing PRs is more entertaining these days.
Is it something you can share the code to?
Sure! It's open source: https://github.com/atombender/cistern.
Awesome, can you also grab a memgraph or something when it’s leaked a bunch of memory (and maybe put it in a GitHub issue)? I can try it but I don’t really use CircleCI so I’m not confident I can reproduce the issue.
There's no valgrind equivalent, I guess?
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.
I'm working on Valgrind on macOS, integrating Louis Brunner's work and trying to add a few more fixes. In 2025 support for macOS Intel 10.14, 10.15 11 and 12 was added. Intel macOS 13 is a bit harder of a nut to crack. And I have lots of issues with ARM, particularly building and testing on anything older that macOS 15.
Swift name-mangling will be an issue. Valgrind's name demangler comes from GNU binutils libiberty which does not support Swift AFAIK.
The Instruments suite, plus sanitizers like ASan, is basically the valgrind equivalent on macOS. It’s not exactly the same, but it comes close.
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.)
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.
curious what you used - I've been looking into making a menubar app and really hate xcode
claude -p "Make a menubar app with AppKit (Cocoa) that does X"
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.
[1]: https://notepadexe.com
[2]: https://notepadexe.com/news/#notepad-14-linux-support
So wait this thing is real? Calling it notepad.exe gave me the impression that it's just an elaborate joke about how you can code any program in Notepad...
It might have a joke name but it costs $80!
That's the real joke...
Or pay $19.99 for a year and be able to run it on 3 devices.
That's a pretty good deal.
It claims “native performance”, which makes me suspect it’s another Electron bloat.
Instead of speculating you could download and see for yourself that it’s not. It’s by Marcin Krzyzanowski who is all about native iOS and macOS apps.
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.
LSP support isn't great. It keeps improving however. Used to get quite a few crashes. And I think background indexing still doesn't work.
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.
> Why would you bother using Swift if you're not targeting Apple?
For the reasons stated in the article.
> I wouldn't pick a language that's under control of a company
Hmm...
TypeScript: Microsoft
Rust: Mozilla
Go: Google
Java: Oracle
By your logic we should be programming in Common Lisp.
==========
Edit:
>... under control of a company I don't use.
You left out an important part of the GP's comment.
>By your logic we should be programming in Common Lisp.
I wish. (Scheme is acceptable too)
I was talking about this at a party this afternoon (yes, I do go to the most interesting parties, thanks) and while Scheme is acceptable the Common Lisp is not because it's not OK to go without boolean primitives. Types are a good idea, if you have types the simplest is clearly the boolean, so start there.
I believe firmly that there should be a single true value, which we might reasonably name true, and a single false value, false, other values aren't booleans, so it's no more reasonable to ask whether an empty string is false, than to just forget to close the quote marks on a string. What we wrote isn't a correct program.
Scheme has a single false value (#f) but everything else is considered true...
Any Lisp w/o image support is no true Lisp in my book. That leaves us with only Common Lisp and Janet.
The others (Scheme, Clojure, etc.) are just Lispy syntax but lack the true "soul" of Lisp-style development.
Racket?
Common Lisp is actually a great language. The SBCL implementation has a good compiler that produce reasonably fast code, and it's under active development.
The only real drawback to common lisp is the fact that the library ecosystem is practically non-existent.
> Rust: Mozilla
Nope. Not anymore, several years maybe?
You forgot the most popular language in the world right now:
Python: The Python Software Foundation
Turns out two of the best languages don't need corporate overlords to steer their development.
Not to mention C, C++, JS, PHP, bash. Hell there are so many great languages not controlled by big companies.
Could that happen today though? I think python started in a very different world then today.
Alot of its current popularity is becasue big companies developed the libraries that make up the foundation of Ai with it.
>I t's a bit like using c# or powershell on Linux… but I wouldn't consider it a first class citizen.
C# is very very much a first class citizen on Linux. It may not be native, but you can run binaries on Linux without needing the runtime when you compile it to target the platform.
I wrote a couple of monoservices on my Mac using c# which ran perfectly on my Microk8s cluster on Linux.
I have nearly a decade of experience building .NET C# solutions on Linux and lately also on Mac, with almost everything hosted on Linux via Docker. I’m not sure what’s still missing for it to be accepted into the "first class citizen" club by the Linux elite.
The goal post must be moved. I constantly hear “there is no GUI story”… well thats not a core part of the language!
There actually is a great GUI story also for Linux today enabled by the excellent Avalonia (https://avaloniaui.net).
What company is using Swift outside of Apple-specific development?
Arc, TBCNY's browser for macOS and Windows uses Swift [1] [2].
Their newer Dia browser which is meant to be cross-platform also uses Swift.
[1]: https://speakinginswift.substack.com/p/swift-tooling-windows...
[2]: "How we're building the Arc Browser Windows app with Swift" -- https://www.youtube.com/watch?v=Xa_fNuaSE_I
> What company is using Swift outside of Apple-specific development?
Skip allows to "Build truly native iPhone and Android apps with Skip" so technically skip runs swift on android which is outside of Apple-specific development.
They also recently got open source from their closed source model prior from what I can tell
https://skip.dev/
Doesn’t affect the validity of your comment whatsoever, but there was the attempt by the Browser Company to implement Arc on Windows in SwiftUI lol
Not a lot, but has absolutely no relation whatsoever to my comment.
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.
> I get Xcode has quirks I use it everyday believe me I know but it's not that bad that it's unusable.
It's not unusable, but it's not that great either. When I have a project that requires Xcode I certainly don't look forward to it the way I do such as wehn I have a project that doesn't need any specific IDE.
As a sidenote; I recently (1 year ago, maybe?) did a C project in Eclipse, and was blown away but just how snappy, quick and, utlimately, enjoyable it was compared to VS Code.
I recently really wanted to use Swift server side because of all the updates to Vapor.
Ran vapor new. Tried to build the project. Laptop spun for minutes and got really hot. Then I gave up and just went back to the usual.
> but it's not that bad that it's unusable
Yeah, so I tried XCode with a couple of years ago. Within 2 hours of working on my very first project, it somehow corrupted either my project's metadata and/or its own internal preferences so badly that it would no longer launch - it would just crash to Desktop instantly. Literally the most unusable application I've used in recent memory!
And the app upload is so broken, Apple released a third party tool to bypass their own IDE...
I only use Xcode rarely, and I'm unfamiliar with its quirks.
That is precisely what makes it such a bad experience compared to my work in JetBrains IDEs or vscode.
Together with an unfamiliar platform I also have to fight that weird IDE.
FWIW I have written a complete macOS cocoa+swift app in emacs alone without XCode, just using Makefiles. You don't strictly need it.
Can you share your configs or link to it? Would love to learn how you did it?
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.
Try xccache
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.
As your app scales, you're going to want to break out different parts into their own packages in order to keep compile times in check, so you're gonna be forced to go through SPM unless you use tuist or bazel.
My problem with it is that I want to use C libraries. And I would (like) it to handle that as much as possible. But SPM can't use vcpkg packages or call CMake stuff (at least, not trivially), so it's extremely hard to use on non-Apple platforms. Which honestly is it's killer for me. It's still so, so Apple focused.
You can build Swift entirely with CMake;
https://github.com/swiftlang/swift-cmake-examples
Sure, but I've never found examples of (say) including other swift packages. Or using CMake-built swift packages in SPM.
What is a CMake-built swift package to begin with? You're mixing build systems and expecting them to co-exist or what is the exact problem? I've done a lot of weird swift things so might be able to point you in the right direction.
E.g.: referencing a vcpkg-built package (without pkgconfig because not all packages have those files). Or telling SPM "Hey, I have this package which uses the cmake build system, and I want you to link to it and auto-generate module maps for it, and get the include directories from cmake". Things like that. So for me anyway it makes using swift painful. The same thing goes in reverse: using SPM packages from cmake (although this is more a cmake issue).
I think cmake very recently got added to spm
Xcode (and as of a couple years ago the vscode spm integration) tends to have difficulty when scaling this solution.
Being explicit with types is very disruptive when used in SwiftUI or TCA.
I'm just talking about having some mechanical sympathy for the compiler such as understanding where the constraint solving problem space gets very large.
I wasn't saying use explicit types everywhere, but giving the compiler a hint every now and then to make things faster just makes sense. The Swift compiler is very complex and of course there are edge cases where it struggles with legal syntax, such as large expressions with many operators.
With SwiftUI it's arguably more important because view builders already put a lot of strain on the compiler.
You can't really easily use explicit types in much of idiomatic SwiftUI. The expression that the compiler is trying to solve is really complicated, I agree, but the solution to that is either changing how SwiftUI is architected or restricting how the language built on SwiftUI infers types.
Using explicit types is less fun though
It even defeats the purpose of type inference.
It's been a while since I've Swifted but it was mostly with combinations of nested generics, lambdas, and literals. Annotating the type of the variable those were assigned to could improve performance a lot.
You don't need to add an annotation on `let foo = bar()` where bar is a function that returns `String` or whatever.
SPM is fine for most Swift and then fully enraging when you have a slightly divergent use case. IME of course.
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.
How many of those people who spend their time using other IDEs on other OSs (where Xcode doesn't run) spend any amount of time using Xcode and therefore have the requisite experience to be able to know that it's generally excellent?
And when you say "you hear", you really mean "you", not "me". I hear it a lot.
What motivated your comment?
I mostly work in games where Xcode is an all too common chore to pick up from time to time because Apple changed the rules on something or other to get an iOS build out. Usually I find that xcode isn't helpful at all in solving these problems. You need to dig through guis because it will not just trivially point you to the text file like VS or Jetbrains would.
It's certainly not a pleasant treat to pick the short straw.
Beyond that, I work with plenty of folks who have dabbled in xcode for mobile or on the side and it's just not seen in that great a light.
Meanwhile, I find that people who love xcode are all in and don't really give alternatives a chance at all (because when you have to use xcode, there isn't an alternative).
Even in this comment chain, we're rejecting other's opinions outright instead of talking about killer features xcode has that others fail at.
Hasn't everybody at least tried everything significant just because? Even the most non-apple developer must have at least checked it out on a friends laptop or something just to be informed of the state of their own business.
If there are developers who are that incurious, all I can say is I don't understand them.
> Hasn't everybody at least tried everything significant just because?
No, not in the slightest. I would call this one the most dangerous and unfortunate fallacies that so many intelligent people have ever accepted and been cheated by. If it were true, you'd know everything important there is to know, and be a master of philosophy, and would have many answers to some basic questions which most people have been told have no good or concrete or verifiable answers.
Hyperbole is rarely useful.
> Hasn't everybody at least tried everything significant just because?
Btw, not defending Xcode. It may be powerful but it is so goddamn sluggish that it is miserable to use.
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.
Weird the little Ive used it I completely hated it.
Errors everywhere with horrible messages that leave you no idea whats wrong
What version did you use? What errors did you see? Don't get me wrong, I've spent 20 years with it, and there was a learning curve - but isn't that the case with many good tools? Again, don't get me wrong, I have some feedback for Apple, and there's a reason why we affectionately call it a harsh mistress. But that doesn't mean it's somehow not one of the best designed, best functioning, and most powerful suites for programming with certain other incidentally very well engineered SDKs etc. And yes, things may have gone downhill a little bit, especially at the scale they're at now. If we could talk about Xcode of, say, 2014, it'd be a less ambiguous conversation.
> If we could talk about Xcode of, say, 2014, it'd be a less ambiguous conversation.
Which be more a problem of Swift and especially SwiftUI.
+1 blows the pants off anything else I’ve touched with zero config fiddling. Great stuff.
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.
Totally agree. Xcode is awful. I’m sure that team has a lot to deal with but they’ve produced since really trash software.
+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.
don't know personally but I'm told bazel shines here.
Hours ago I was setting up Xcode Cloud on Xcode and it kept crashing whenever I edited the workflow. Smh
> 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.
> 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?
Incorrect. I use Helix. But the editor is irrelevant, which is why I left it out.
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
As someone who basically only uses Emacs and Xcode- why is Xcode so bad?
Emacs and Xcode is certainly an interesting mix. Aren't they kind of the polar opposites of each other?
iirc you can't do this for extensions which being a huge amount of compiler constraint resolution time
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.
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.
https://www.swift.org/blog/announcing-windows-workgroup/ https://www.swift.org/blog/exploring-the-swift-sdk-for-andro... ?
I remember that in early Swift, I had a 1-2 line dict/array literal and it caused the file/project build to be 30 minutes.
Well same for typescript
I’m curious about SPM vs Cargo - are there basic design decisions that make Cargo better or just particularities of thier current states?
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)
Rv, a new kind of Ruby management tool: https://news.ycombinator.com/item?id=45023730
Sure but not very many people care about SPM
Xcode truly is terrible.
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.
And the licensing agreement. How do I do it on Linux with no Mac or iOS?
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).
You can also sometimes avoid xcode, see https://github.com/xtool-org/xtool
although, at this point, just use expo!
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.
Swift has builds for Linux: https://www.swift.org/install/linux/
The license is pretty much Apache 2.0
The funny thing about the low effort parent comments is the truth - wikipedia lists that there are more release builds of swift of linux than for macOS. Granted they were bug fixes but still.
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.
> 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.
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.
I think Swift enums are really well designed, but SwiftData doesn't really support them unfortunately and Observable has problems with reactivity and enums (works on iOS not macOS I've found).
So lots of optionals might well be the better path here.
I don't think it's horrible, but I really do wish they would copy TypeScript here.
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...
It's worth pointing out that the two examples that you're writing are actually strictly different, and not just "better syntax for the same thing". (This is assuming `String | Int` works as in Python, and the second example works as in Rust.)
To understand the difference, `String | String` is just `String`. It's a union, not a sum type. There's no tag or identifier, so you cannot distinguish whether it's the first or the second string.
If this sounds pedantic, this has pretty important ramifications, especially once generics get involved.
To provide a concrete example, this bit me in a typescript codebase:
Now imagine the definition of Option is in some library or other file and you don't realize how it works. You are thinking of the Option as its own structure and expect f to return Option<string | undefined>. But Option<string | undefined> = string | undefined | undefined = string | undefined = Option<string>.The mistake here is in how Option is defined, but it's a footgun you need to be aware of.
The mistake here is that you assume that Option is a struct. For TypeScript, this is an idiomatic definition of something that is optional though.
I guess I just want to be able to do something like this in Swift:
There's one more thing about TypeScript-style union types: string literals. I think it's great to be able to do And subsequently I could use I think this is more programmer friendly than requiring an out-of-line definition of a new `enum`. Sometimes you just want to write some code, you know?Hijacking your comment because this is a common point that's made on the superiority of Swift syntax against the union syntax.
At least with |, you're attempting to model the state space. You're saying "this is one of these things." You might get the exhaustiveness wrong, but you're in the right ballpark. As it's normally done right now, the Swift developer with five optional properties is modeling state as "maybe this, maybe that, maybe both, who knows, good luck." which is just worse than a bar. If you need to discriminate explicitly, add a `__kind` field!
So long as you have structurally typed structs (as TypeScript does), you can do stuff like {foo: string} | {bar: string} to the same effect as type constructors if and when you actually need it.
At the same time, how often do you really need (Just (Just (Just ...)))?
Note that union types are not the same thing as sum types, even if they're somewhat similar. https://viralinstruction.com/posts/uniontypes/
> actually using swift enums and protocols is so painful.
In what way? My understanding is they're widely used and encouraged.
If you look at most swiftui views, there will be a mass of optionals, rather than enum cases for every possible state that the view can occupy and a state machine transitioning between each state.
If you actually try and write it all out (like go full-on and use TCA to model all the states and actions such that all and only valid states can be represented in the state types) the compiler is going to have a hard time, you're going to write masses of boilerplate, and just in general it's much rougher than zustand and expo.
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.
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.
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.
You don't need Box here because Vec<T> is already a fixed size handle to heap data.
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.
Of course, the language lets you decide. I think this anti feature is actually a feature.
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.
> - 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).
sad, I was doing server side around v4/5 and this was the biggest issue at the time for me (lots of stuff was not implemented and you only found out at runtime). that this is still a problem is very disappointing...
Outside macOS/iOS devs wanting to share code with server side, I don't see a use case, given the more mature alternatives.
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 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...
Sounds like a language not to waste my time on.
I should spend my time writing actual code and ship stuff, not debugging or finding holes in someone else's product.
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.
> Rust wasn’t designed for any specific platform
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).
Is liquid glass really that bad? I left Mac years ago due to other annoyances. It was my daily driver for a decade and change. But I couldn't get used to the iOSification and the dependence on apple cloud services for most new features. When I started with macOS jaguar it was just a really good commercial UNIX. It got even better with Tiger and leopard.
But the later years I spent every release looking at new fancy features I couldn't use because I don't use apple exclusively (and I don't use iOS at all, too closed for me). So almost no features that appealed to me while usually breaking some parts of the workflow I did use.
While I did hate the 'flat' redesign after Mavericks that on its own was not really a deal-breaker though. Just an annoyance.
I'm kinda surprised liquid glass is so bad people actually leave for it. Or is it more like the last drop?
> Is liquid glass really that bad?
No, but every release of MacOS has a noisy minority declaring it, or some features of it, as the end of Macs. Some people will genuinely hate it in the way that nothing can be universally loved, some people will abandon Macs over it, most people don't feel strongly about it at all.
Maybe there's some people out there that love it, even.
I can barely tell the difference between the Mac I use that's been upgraded, and the Mac that hasn't due to its age, because I'm not spending my time at the computers staring at the decor. The contents of the application windows is the same.
> Is liquid glass really that bad?
I don’t like it, but I think the claims of mass exodus are unlikely.
It feels a lot like the situation when Reddit started charging for their API: Everywhere you looked you could find claims that it was the end of Reddit, but in the end it was just a vocal minority. Reddit’s traffic patterns didn’t decline at all.
Liquid Glass really is that bad. Not because the visual design is especially bad (not my cup of tea but it's okay); but because all of macOS is now incredibly janky. Even Spotlight is a janky mess now with lots of broken animations.
> Is liquid glass really that bad?
It's unfinished. For example, the more rounded windows would require that scrollbars or other widgets are more inset and things like that. The system doesn't seem to handle this automatically, so many apps look broken, even Apple's first party ones.
I ship a lot of .NET on Linux these days, works great
This. We ported a huge component, an ASP.NET server hosted Windows to Linux (/w Docker). We did the initial migration in a couple of days, and only after a couple of months, we basically managed to bring all production installs to Linux.
It only took a year, and everyone works exclusively with devcontainers, and we allow devs to experimentally pick Linux and Mac laptops.
Arguably the dotnet sdk now works better on Linux than Windows. For example, Windows Containers are "supported" only the marketing checkbox sense.
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.
YMMV
> 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.
Swift also supports the ownership model.
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.
[1] https://doc.rust-lang.org/book/ch15-04-rc.html
[2] https://doc.rust-lang.org/book/ch15-05-interior-mutability.h...
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.
Thanks for the answer, that sounds reassuring. I have another question, from what you said, it sounds like you remove restrict from the whol argument, but technically, afaict, the Rust borrow rules still prevent anything inside those structs getting aliased, with the exception of the stuff inside UnsafeCell<> (even with Rc<> the underlying value cannot be aliased, only the reference counter).
Does Rust/LLVM track aliasing to this degree, or is it all or nothing, like if you have a UnsafeCell anywhere, the whole type is excluded from restrict?
I am not sure off the top of my head, to be honest. https://news.ycombinator.com/item?id=46616616 was a thread where I was talking about this sort of thing previously, you could probably adapt those code examples and get an answer.
It gets really verbose though!
> It gets really verbose though!
Nope, you just use wrapper types (which you should anyway).
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.
People still write applications in Objective-C (e.g., see Transmission [1]), and the language is still maintained to support the latest OS. If anything, Apple being the largest sponsor of Objective-C would suggest that you get greater vendor lock-in out of it than Swift, since you can at least use the latter outside of Apple platforms (e.g., on a server).
[1]: https://github.com/transmission/transmission
> Apple being the largest sponsor of Objective-C would suggest that you get greater vendor lock-in out of it than Swift
Fun fact, you can use Objective-C on non-Apple platforms [1] and with Cocoa APIs courtesy of the GNUstep project [2].
[1] https://github.com/gnustep/libobjc2
[2] https://www.gnustep.org/
Yes, but does anyone today really do that? The only value I see out of Objective-C on its own is as a performant and compromising Smalltalk.
Only if you enjoy being stuck in something like Panther and Objective-C 1.x.
Objective-C is as dead because of Swift as C is because of Rust, which is to say, "not very".
Objective-C remains a first-class iOS development language, and there's no sign of that changing for at least another decade.
Although the only framework that was developed in Objective-C after Swift got introduced was Metal, anything else is mostly maintenance and incremental improvements.
"and dropped it like a stone with little warning or ceremony"
What?! This is complete nonsense. Swift was introduced 11 (!) years ago and it was clear from day one that it was going to be the future. Every single year since the introduction there were clear messages and hints in documentation and WWDC that Swift is in and Objective-C will _eventually_ be out.
Little warning? Maybe if you kept your eyes closed the past 11 years.
And do not forget that today you can still write apps in Objective-C.
Whether or not Apple still has legacy pieces in Objective-C or still allows you to write apps in it is not the issue. The point here is that Apple shadow-dropped Swift and shifted essentially all of its development priority away from Objective-C in a matter of months.
I think that is a pretty inaccurate description of what happened the past 11 years.
I'm old enough to remember when Objective-C was a real and thriving (if niche) language. I remember all the buzz when automatic reference counting was the next big thing, pushed heavily by Apple and taking center stage at WWDC. And since the year Swift came out, Objective-C has joined Cobol in the category of zombie languages: the living dead with plenty of entrenced codebases but with nothing to look forward to but a continued slide into technological irrelevance.
Such bullshit, macOS is the best OS for power users.
Power users of Subway Surfers, maybe. Modern macOS is a tragedy: https://eclecticlight.co/2021/08/12/is-apple-keeping-its-pro...
Dude, this is some article from 5 years ago.
They still didn’t fix it, so
MacOS was only the best OS for power users between 1994 and 2008, at which point they shifted to x86.
And it still is the best OS for power users.
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.
A lot of Apple's software is written in Swift now. It's probably not in their interest to abandon the language.
I mean they did switch from objective c. At some point they might switch again if it makes sense.
I mean, after some almost 40 years. If 40 years from now, hell, even 20, Apple abandoned the language I’m not sure I care about the risk.
And that’s not to say they don’t support objective-c still. It just hasn’t been actively developed with new features.
Especially if the promise of coding agents porting between languages is even partially realised it could make it very easy for them to switch.
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)
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.
> The community was very against function builders.
Scanning the multiple review threads, that doesn't appear to be the case. According to the acceptance post, the community was overall positive about the feature but expressed concerns over the attribute naming, which was renamed in response.
Read the thread reviewing the proposal.
Just like Go's dependency and package management, Google also bullied the community into their own solution.
I'd bet a supermajority of Swift commits comes from Apple developers. Pretty sure the rust-lang/rust commit authors would be much less centralized.
Yup just like google doesn’t actually control chromium right
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.
But the fact remains that if Apple abandoned Swift tomorrow the language would almost certainly wither and die.
It's about as maintained by the "open source community" as Android is lol
> 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.
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)...
> Additionally Google isn't selling Go as a product in the same way as Apple does Swift
Hmm, Apple isn't selling Swift as a product either; it's literally what they needed for their own platform, much like how GOOG needed Go for their server works.
Apple is selling Swift as a product - it is their preferred interface for constructing iOS applications!
Kubernetes and Docker, CNCF is full of commercial products.
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).
> 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
No it wasn’t. There were so many foot guns for windows and in fact to this day you cant use CGO with MSVC (insane to me).
I can’t even say with a straight face today that Windows is the best supported OS for C#, because it’s not true
Microsoft’s market position is reliant on Linux and access to Linux development to keep Azure competitive. Cross-platform capabilities on the .Net VM are critical to compete with the JVM and associated databases. C# has been windows-first for a while, but the core cross-platform capabilities are not going to disappear, the tooling is all CLI based/capable now, the entanglements tend to be platform and service based.
That said, F# was years ahead of C# in features C# is still chasing, and is driven mostly by the open source community. That community is more in academic and finance areas where Linux-first is common. The language is standardized and plugged into VM improvements over time.
Frankly, I see the lesser degree of entanglement with MS corporate interests as a boon for the language and its ecosystems long-term utility.
From what I understand, LSP support for c# isn't very good, and is from third parties, not MS themselves, because they want you to us Visual Studio on Windows.
Microsoft provides C# LSP for VSCode (https://marketplace.visualstudio.com/items?itemName=ms-dotne...).
The problem is that it's closed source, and its license specifically prohibits its use with anything other than VSCode. Unfortunately, this is becoming the usual modus operandi for first-party Microsoft extensions for VSCode for all the talk about how they "love open source".
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.
> 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/
That's progress over where it was a year ago. But the almost complete absence of packages that run on Windows makes the progress made so far more of a curiosity than a usable option--alas. I'd use Swift in a heartbeat if it had even a semblance of a decent ecosystem on Windows.
Does Swift not have an automatic bindings generator for C headers?
I’ve done both Swift and rust for Linux applications (symbolic analysis tools and compilers, not web stuff or other server apps). I have to say, I’m torn after building a couple moderate (10-30k SLOC) scale tools in both. I prefer swift since I feel like I’m working at the abstraction level I prefer and letting the ARC stuff take care of memory for me. Rust isn’t so bad, but it does make me think more about things that I don’t when I’m in Ocaml or Swift. Rust has better tooling: the LSP support makes life nice in emacs. Compiler feedback and clippy : super useful. Not a fan of the high usage of crates (I’m in the paranoid about supply chain camp). Swift felt like it shipped with more batteries included. I think the main factor is the people side: however much I like swift, I’m more likely to find rust people in my world. I’m rooting for swift though: the world has room for more than one memory safe C++ successor.
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.
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.
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
Yeah. You can bind C in swift. You can expose C interfaces from Rust. Write non-iOS code in Rust, then bind. Now you have iOS support with common client code in Rust.
You can compile Rust to WASM. You can run Rust on the backend. It's gaining popularity on k8s for memory consumption. You can write music visualizers in Rust. You can pivot to killer drones or embedded in Rust. It has very few foot guns compared to C and all of the advantages of C.
The people who want Swift to succeed off of Apple hardware are basically waiting for someone else to do it. Rust users will just invade Apple from every side. It is very clear which platform is the better investment of anyone's time.
I can't believe I'm even wasting keystrokes thinking about this. I saw a bunch of upvotes and can only imagine this has to be wishful thinking from Swift users.
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.
Async/await is not a solution to poor thread models.
Async/await is cooperative multitasking and is no help at all for cpu bound problems.
For i/o intensive systems it makes non-blocking i/o look like blocking i/o, and people find that helpful.
I do real-time i/o so I need more control and Async/await is unhelpful.
It is a worthy adition to Swift I agree. But they sorely lack Rust's excellent design in this area
I use async/await for my CPU bound problems and it works fine
So long as you "await"
Not really concurrent
Not very well known, but Swift has two builtin concurrency systems (in addition to the very well known async/await for parallelism): async let (not very flexible) and task groups (much more so).
You don’t have to await immediately!
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
> is I'm allergic to Go and just use Rust 99% of the time these days
I confess I have not used Go. I am allergic to Typescript, let alone, Javascript, and Node.js should be deleted.
I do mostly real-time audio, so I too am Rust (job control in Shell). But what decent choices are there for garbage collected systems?
And garbage collection, for most systems, is crucial
Leptos etc. WASM is mature enough to just go for it. Same code sharing arrangement as using TS on the backend but using the backend language on the frontend instead.
I guess you could use OCaml / ReasonML now, the latter especially feels like Rust with a GC.
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.
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.
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.
It's been a while, but the one I remember with the most horror was dealing with Enums, and Enum payloads. Since Swift is statically-typed, many 'type union' situations end up becoming difficult problems. The question usually boils down to thinking about choosing one of (a) Enum with Payload (b) Generic (c) Type erasure. Nearly anything technically is do-able, but I wasted many hours (ie: repeatedly, not until I figured out the 'right way' for every situation) deliberating over how!
I am not sure that I understand you correctly, and I find the subject interesting.
Is it what the enum abstraction can model easily that is the issue?
If so, I believe the Rust community has similar issues regarding error handling. There are multiple libraries like thiserror and anyhow.
https://old.reddit.com/r/rust/comments/1mexsqr/the_way_rust_...
https://old.reddit.com/r/rust/comments/1q3wb3l/stop_forwardi...
Low level languages don’t even have those features.
I didn't mean to suggest they do!
When I used Swift, I frequently was surprised to find some simple part of a program actually required me to sit and plan for several hours.
The exhausting amount of mental energy is the only part that reminds me of coding in Assembly.
I guess my perspective is that I usually have to plan out my programs regardless of what language they’re in so I don’t really view it as being similar?
That is a different issue than this:
It's perfectly normal in programming to encounter domain problems that take longer than one predicted, or to plan ahead with pseudo code, proofs of concept, class diagrams, etc.What is abnormal is, over and over again, to find oneself utterly stumped on how best to implement something very basic. At least, it's abnormal when using a high-level language.
[dead]
> 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.
> 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.
So creating more confusion and losing the devs who are not aware (so would prefer a plainer language) is somehow more convenient and a masterclass in... deception (a positive since when)?
"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.
Not sure "convenience" alone should be the deciding factor when choosing a language for a project/product.
What matters more is the long-term value for what’s being built and maintained.
For portable, high-performance backends, Rust often offers a higher value/friction tradeoff, IMO.
For Apple platform development, Swift is the obvious choice.
Swift’s cross-platform story has improved, but outside the Apple ecosystem the incentives still seem weaker compared to Rust.
So overall, IMO, Rust tends to have a higher net value beyond Apple-specific use cases.
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.
For us grey beards, both are basically Object Pascal/Modula-2/Delphi for new generations.
> 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…
Swift's happy path is pretty good, i.e. when you want to use a recent-ish toolchain to develop IOS applications using APIs that are not too new.
The more you deviate from this, the more cracks there are.
"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.
No thanks, too tied to Apple and closed source development models.
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/
If I were to draw a flow chart for selecting a language for a new project the first question would be "am I targeting only Apple platforms". If the answer is yes then the choice is Swift, if the answer is no then Swift is crossed off the list.
Outside of the Apple ecosystem it's going to be friction all the way. There are better choices.
I was really taken in by this premise a while back so I tried building some side projects with server side swift on my windows machine inside WSL.
I really wanted to like it, but the experience was terrible, from the editing side (with vscode) all the way to the performance of existing frameworks (tried both Vapor and grpc-swift-2).
I generally like Swift, but async is a mess, it feels like they come up with a new async library every release
Just forget everything you've learned about it previously, use 6.2+, non isolated by default and every upcoming feature turned on. And your intuition will be spot on.
Can you explain a bit more on what changed with 6.2+ that is now better?
https://github.com/swiftlang/swift-evolution/blob/main/propo...
https://github.com/swiftlang/swift-evolution/blob/main/propo...
https://github.com/swiftlang/swift-evolution/blob/main/propo...
https://github.com/swiftlang/swift-evolution/blob/main/propo...
All of these changes improve the ergonomics of async/await. Fewer hops and a better alignment of when one would expect a hop to occur.
https://github.com/swiftlang/swift-evolution/blob/main/propo...
async defer is nice too but it's not in the 6.2 public release AFAICT.
Far fewer actor hops by default which usually makes it easier to write correct code
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
> By default, a Rust program is much faster than a Swift program. This is because Rust is fast by default, and lets you be slow, while Swift is easy by default and lets you be fast.
So what do you need to do to make Swift as fast as Rust?
Make it look like Rust mostly
Since then, Swift also grew excellent C++ interop, something Rust doesn't have at all.
In the long run https://github.com/google/crubit will very likely solve this for Rust even if it's a bit specific to Google's use cases right now as per readme.
With swift you get to use it as a scripting language.
This tool will transparently compile if after a while: https://github.com/jrz/tools
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.
Related. Others?
Swift is a more convenient Rust - https://news.ycombinator.com/item?id=41464371 - Sept 2024 (308 comments)
I don't really see the advantage of switch statements over match statements.
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.
> 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
You still lose the benefits of Affine Types in Rust though
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?
It’s what I do, every day. You maybe in need of a broader horizon for comparison
(2023)
Some previous discussion:
2024 https://news.ycombinator.com/item?id=41464371
I refuse to be locked into a platform, and I dislike languages that obscure memory management (ARC). Thus, Swift isnt on my radar. A couple of iOS apps I developed in the past used c++ for 99% of code (OpenGL GUI), with 2 mm files to link to AppKit. These days I’m on Vulkan and dont bother with iOS (MoltenVK is just a bridge too far for me, and yes I did get a prototype running, but it just takes way too long to start in XCode while debugging).
Looks like the post was written in 2023, I wonder how much better did Swift get in crossplatform department these days?
Glad to see "Swift is good now" taking the place of "year of the Linux desktop" in a post-Steam Deck world.
One of the Swift’s worst parts is how Apple keeps putting features in there just for the sake of SwiftUI.
You can just not use them
First, op should mention which ones but they won't.
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...
After that, things like:
https://www.hackingwithswift.com/learn
https://www.hackingwithswift.com/quick-start/swiftui/
https://sosumi.ai/
What is "clone-on-right"?
A misspelling of "copy-on-write".
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.
Swift is OK, but with the introduction of SwiftUI, we see some hypocrisy.
We were all told to "prefer structs" over classes in Swift, but structs are always passed by value.
We're also told to maintain "one source of truth" (which I'm sure a lot of us did anyway). But you can't do that when you're copying stuff all over the place.
So now what? I got so sick of trying to figure out how to pass structs into views for modification by the user that I made everything a class. What a relief. Now I could get back to work on functionality instead of constructing absurd gymnastics to get altered data back from a view.
I find the whole "structs are passed by value, classes by reference" thing hokey as hell and poor style. People reading the code don't know if the called function can change the passed-in object or not; they have to go see if it's a class or a struct. Lame.
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.
> Infuriating strings lib. Kinda believe the entire language was designed around emojis.
Unicode but yes
I mean emojis specifically. Python or JS strings are designed for unicode chars. Swift made it about grapheme clusters, which are possibly a valid edge case for like Arabic emphasis marks but not something they'd be motivated to center the entire strings behavior around if it weren't for emojis.
Weird part is the Swift way was still annoying even in cases where I wanted to manipulate strings with emojis very often. Had to build some custom pre-indexed string (just an array of 1-cluster Swift strings), cause find/replace/split/etc was too cumbersome and inefficient otherwise.
I think Swift made the right choice, though: it’s rare that you’d want to slice a grapheme. Usually you don’t have to build an index if you take a step back and design the algorithm around the indexing model.
That's the thing, there is no indexing model. Every string operation is an O(N) seek. But even if you don't care about performance, it's just cumbersome.
Looking at the SO questions for simple things like finding the position of a substring, it also lacked a lot of typical built ins until Swift 5. But that was like 5 years after GA.
There's definitely an indexing model, it's just that it's similar to that of a linked list. You can do all sorts of useful operations on a linked list. Not everything is O(n) in this world.
You can't do any linked list operations on this other than "get next" which is still kinda different
Maybe it would be helpful if you have an example that you’re having trouble with.
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).
> 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.
Nope.
Swift started out pretty nice but they've added too much Liquid Glass since then, the type system constraint solving madness and forcing actors down everyone's throat come to mind.
I don't touch it unless forced to these days.
MoonBit lang is better "better Rust" than Swift.
I think this title is doing more harm than good.
Both are great languages
Are Core Foundation and Foundation Kit still macOS-only?
Foundation has a Linux implementation.
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...[dead]
I am starting a new project, which requires to be GUI primarily for macOS, but also Windows.
Swift is a lovely language, but had to go with C#+Avalonia, which can give me truly multi-platform app. If only SwiftUI was properly supported on Windows, that would be great.
For now, .NET/C# + Avalonia seems the most convenient way to write Desktop apps, well, if you don't want to pay for Delphi ;)
[dead]
[dead]
> to do reference counting and “clone-on-right” in your code
Was this article vibe dictated?
>Swift is more convenient Rust
Nah.
... Literally ruined
https://youtube.com/clip/UgkxFZA4XXnXzHyNso0OQ28XU60U1-jdR13...
> 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?
weak delegates seem to work fine...?
Look up the language and ARC.
ARC doesn't do cycles, but it is deterministic and more power efficient than GC.
So use a language that supports both.
That would only have the disadvantages of both.
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.