10 ms·

Swift is a more convenient Rust (2023)

328 points by behnamoh 9mo ago

bigyabai 9mo ago
Glad to see "Swift is good now" taking the place of "year of the Linux desktop" in a post-Steam Deck world.
ewuhic 9mo ago
>Swift is more convenient Rust Nah.
- Blackarea 9mo ago
  ... Literally ruined https://youtube.com/clip/UgkxFZA4XXnXzHyNso0OQ28XU60U1-jdR13S?si=86lp__cBQ_uuDgQy https://youtube.com/clip/UgkxFZA4XXnXzHyNso0OQ28XU60U1-jdR13...
dagmx 9mo ago
There’s definitely areas where I agree Swift is more ergonomic. Parameter defaults, and null short circuiting are two of them. I find writing Swift is faster for me, and it’s easier to learn for people than Rust. Also Swift interop with other languages is much simpler. Though there are way fewer resources to learn Swift, and cargo is superior to SPM. And of course rust is better cross platform today, but Swift is closing the gap. I think they feel like very similar languages overall, and they both influence each other.
killingtime74 9mo ago
Even if it's the same (faster horse?) I would rather use Rust for the fact it's development is not tied to a big tech company which could abandon it if they liked. Yes it could continue on as a fork but it's development velocity would suffer.
- threatofrain 9mo ago
  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.
  - kibwen 9mo ago
    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.
    - j3th9n 9mo ago
      Such bullshit, macOS is the best OS for power users.
      - deleted 9mo ago
        [deleted]
      - kibwen 9mo ago
        MacOS was only the best OS for power users between 1994 and 2008, at which point they shifted to x86.
        j3th9n 9mo ago
        And it still is the best OS for power users.
      - bigyabai 9mo ago
        Power users of Subway Surfers, maybe. Modern macOS is a tragedy: https://eclecticlight.co/2021/08/12/is-apple-keeping-its-promises-over-online-ocsp-certificate-checks/ https://eclecticlight.co/2021/08/12/is-apple-keeping-its-pro...
- nomel 9mo ago
  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) https://en.wikipedia.org/wiki/Swift_(programming_language)
  - heavyset_go 9mo ago
    It's about as maintained by the "open source community" as Android is lol
  - Aurornis 9mo ago
    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.
  - dochtman 9mo ago
    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.
  - piyuv 9mo ago
    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.
    - vor_ 9mo ago
      > 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.
- Hamuko 9mo ago
  A lot of Apple's software is written in Swift now. It's probably not in their interest to abandon the language.
  - HaloZero 9mo ago
    I mean they did switch from objective c. At some point they might switch again if it makes sense.
    - hokumguru 9mo ago
      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.
    - cube00 9mo ago
      Especially if the promise of coding agents porting between languages is even partially realised it could make it very easy for them to switch.
- rvz 9mo ago
  > 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.
  - sealeck 9mo ago
    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)...
    - behnamoh 9mo ago
      > 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.
      - sealeck 9mo ago
        Apple is selling Swift as a product - it is their preferred interface for constructing iOS applications!
        pjmlp 9mo ago
        Kubernetes and Docker, CNCF is full of commercial products.
        sealeck 8mo ago
        Go is an implementation detail for Kubernetes and Docker...
IshKebab 9mo ago
Interesting. I'm not totally sold - still seems like Swift is quite niche and Apple-specific - but I might take another look. Also you might want to rework the `Box` example because you don't actually need to use `Box` in that case - the `Vec` already provides indirection.
xannabelle 9mo ago
I was surprised how similar their approach was to memory management. The creator is doing the same thing for Python as they did for Objective-C, making way for a new wave of Swift and Mojo, although we'll have to see if the latter grows to the same success.
SkiFire13 9mo ago
> Consider an enum that represents a tree. Since, it is a recursive type, Rust will force you to use something like Box<> for referencing a type within itself. > > enum TreeNode<T> { > Leaf(T), > Branch(Vec<Box<TreeNode<T>>>), > } > > (You could also us Box<Vec<TreeNode<T>>> instead) This is wrong, you don't need a `Box` here. The Rust compiler forces you to have a layer of indirection, but `Vec` already does that.
- JackYoustra 9mo ago
  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.
  - nielsbot 9mo ago
    I don't think it's horrible, but I really do wish they would copy TypeScript here. Let me do this: const x: String | Int Instead of enum MyEnum { case string(String) case int(Int) } There's an existing proposal for this here: https://forums.swift.org/t/re-proposal-type-only-unions/72700 https://forums.swift.org/t/re-proposal-type-only-unions/7270...
    - Mond_ 9mo ago
      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.
      - ekimekim 9mo ago
JackYoustra 9mo ago
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.
- hboon 9mo ago
  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.
  - jbverschoor 9mo ago
    Well same for typescript
- fragmede 9mo ago
  And the licensing agreement. How do I do it on Linux with no Mac or iOS?
amelius 9mo ago
> Swift is better for writing UI and servers and some parts of compilers and operating systems. For UI, why would anyone choose a language that has no automatic GC that can handle cycles?
- keyle 9mo ago
  Look up the language and ARC.
  - astrange 9mo ago
    ARC doesn't do cycles, but it is deterministic and more power efficient than GC.
    - amelius 9mo ago
      So use a language that supports both.
      - astrange 9mo ago
        That would only have the disadvantages of both.
- mh2266 9mo ago
  weak delegates seem to work fine...?
OrangeDelonge 9mo ago
I generally like Swift, but async is a mess, it feels like they come up with a new async library every release
- hn-acct 9mo ago
  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.
  - apt-apt-apt-apt 9mo ago
    Can you explain a bit more on what changed with 6.2+ that is now better?
    - saagarjha 9mo ago
      Far fewer actor hops by default which usually makes it easier to write correct code
    - hn-acct 9mo ago
      https://github.com/swiftlang/swift-evolution/blob/main/proposals/0449-nonisolated-for-global-actor-cutoff.md https://github.com/swiftlang/swift-evolution/blob/main/propo... https://github.com/swiftlang/swift-evolution/blob/main/proposals/0461-async-function-isolation.md https://github.com/swiftlang/swift-evolution/blob/main/propo... https://github.com/swiftlang/swift-evolution/blob/main/proposals/0463-sendable-completion-handlers.md https://github.com/swiftlang/swift-evolution/blob/main/propo... https://github.com/swiftlang/swift-evolution/blob/main/proposals/0466-control-default-actor-isolation.md 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/proposals/0493-defer-async.md 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.
suddenlybananas 9mo ago
I don't really see the advantage of switch statements over match statements.
beshrkayali 9mo ago
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-game/ https://log.beshr.com/notes-on-swift-from-building-an-ios-ga...
- bloomca 9mo ago
  I personally never seen anything as bad as XCode, but granted, I haven't used really old IDEs (always preferred just editors). Last year I built a few small apps using both XCode/Swift and Visual Studio/C# and using MS stack felt like you are living in the future, despite WinUI having a very dated UI syntax.
gary17the 9mo ago
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 https://doc.rust-lang.org/book/ch15-04-rc.html [2] https://doc.rust-lang.org/book/ch15-05-interior-mutability.html https://doc.rust-lang.org/book/ch15-05-interior-mutability.h...
- rjh29 9mo ago
  It gets really verbose though!
  - virtualritz 9mo ago
    > It gets really verbose though! Nope, you just use wrapper types (which you should anyway).
- Cyph0n 9mo ago
  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.
- torginus 9mo ago
  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.
mogoh 9mo ago
> There is a perception that Swift is only a good language for Apple platforms. While this was once true, this is no longer the case and Swift is becoming increasingly a good cross-platform language. How good is the developer experience on a non-Apple platform really? Linux is my primary platform and my perception is, that allmost all of the swift eco system is for Apple. Libraries, tools, documentation, IDEs, tutorials, etc. all assume, that you use an Apple. Can someone tell me who does not use an Apple-device and uses swift?
- rcarmo 9mo ago
  I tried doing compiling a few of my Mac CLI tools to Linux. These days, it's faster to run them through an LLM and get quite excellent Go at the other end, and _that_ is much easier to cross-compile. I have been looking at the new Android support (don't have the link handy) and it's tempting, but I know Kotlin and always developed for Android with a bare Makefile and the JDK, so I don't need any fancy tooling...
- WD-42 9mo ago
  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.
  - sealeck 9mo ago
    > 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).
    - wolvoleo 9mo ago
isodev 9mo ago
Until you get to the Swift concurrency stuff, or you try to use Swift on a backend or non-Apple system - then it’s hot garbage. If Rust is too low level for you, you can write Go or Kotlin or even something new and fresh like Gleam.
- frizlab 9mo ago
  Except I did and it was good. When did you last try?
  - isodev 9mo ago
    It’s what I do, every day. You maybe in need of a broader horizon for comparison
drcongo 9mo ago
This article made me actually interested in learning Swift. Anyone recommend a good place to start?
- deryilz 9mo ago
  The Swift Book is good for this: https://docs.swift.org/swift-book/documentation/the-swift-programming-language/ https://docs.swift.org/swift-book/documentation/the-swift-pr...
  - Terretta 9mo ago
    After that, things like: https://www.hackingwithswift.com/learn https://www.hackingwithswift.com/learn https://www.hackingwithswift.com/quick-start/swiftui/ https://www.hackingwithswift.com/quick-start/swiftui/ https://sosumi.ai/ https://sosumi.ai/
rcarmo 9mo ago
Riiiiight. No. I'm a Mac user for decades, former Obj-C hacker, have tried and tried again and again to use Swift (and I have quite a few CLI apps written in it), but the thing has been a clusterfuck of paper cuts and very minor but significant changes over the years, and I gave up waiting for it to settle. And it's not a more convenient Rust. I'd rather use Zig or Go (neither of which are worthy in the eyes of true Crustaceans, but which just get the job done).
drnick1 9mo ago
No thanks, too tied to Apple and closed source development models.
usamoi 9mo ago
I really don't understand what's the point of such comparisons. Swift uses subtyping, while Rust uses typeclasses. Even looking only at their type systems, the two are completely different. You can't assume they are similar just because they both use the Latin alphabet.
- slavapestov 9mo ago
  > Swift uses subtyping, while Rust uses typeclasses. Even looking only at their type systems, the two are completely different. What does it mean to “use” subtyping vs typeclasses? Swift protocols are essentially typeclasses with associated types, just like Rust traits.
java-man 9mo ago
What is "clone-on-right"?
- lucsky 9mo ago
  A misspelling of "copy-on-write".
jdalsgaard 9mo ago
I would tend to disagree; fundamental to Rust is the concept of zero-cost abstraction. Swift does not do that. I my view, and I might be wrong, many features of Rust are chosen specifically to have the language comply to the zero-cost rule. Such as the ownership model.
- isodev 9mo ago
  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.
- behnamoh 9mo ago
  Swift also supports the ownership model.
  - kibwen 9mo ago
    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.
  - jdalsgaard 9mo ago
    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).
rickstanley 9mo ago
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 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 https://github.com/swiftlang/swift/issues/60690. No problem! They have a script for installing: https://www.swift.org/install/linux/ https://www.swift.org/install/linux/ curl -O https://download.swift.org/swiftly/linux/swiftly-$(uname -m).tar.gz && \ tar zxf swiftly-$(uname -m).tar.gz && \ ./swiftly init --quiet-shell-followup && \ . "${SWIFTLY_HOME_DIR:-$HOME/.local/share/swiftly}/env.sh" && \ hash -r But, god damn, the size is huge, Unsupported Linux platform Debian GNU/Linux 13 (trixie) is not an officially supported platform, but the toolchains for another platform may still work on it. Please select the platform to use for toolchain downloads: 0) Cancel 1) Ubuntu 24.04 2) Ubuntu 22.04 3) Ubuntu 20.04 4) Ubuntu 18.04 5) Fedora Linux 39 6) RHEL 9 7) Amazon Linux 2 8) Debian GNU/Linux 12 Pick one of the available selections [0-8] : 8 Installing swiftly in /home/debby/.local/share/swiftly/bin/swiftly... Creating shell environment file for the user... Updating profile... Fetching the latest stable Swift release... Installing Swift 6.2.3 Downloading Swift 6.2.3 100% [========================================================] Downloaded 947.6 MiB of 947.6 MiB Verifying toolchain signature... Extracting toolchain... The file `/home/debby/ent/agateteper/.swift-version` has been set to `Swift 6.2.3` The global default toolchain has been set to `Swift 6.2.3` Swift 6.2.3 is installed successfully! There are some dependencies that should be installed before using this toolchain. You can run the following script as the system administrator (e.g. root) to prepare your system: apt-get -y install libicu-dev libcurl4-openssl-dev libedit-dev libsqlite3-dev libncurses-dev libpython3-dev libxml2-dev pkg-config uuid-dev libstdc++-12-dev 947.6 MiB ! I wonder why is that...
rednafi 9mo ago
Swift is a neat language, but it’s a hard sell for server-side software. The ecosystem is tiny, and there’s nothing you gain from using it instead of Go or Rust for infra / distsys. Also, it works okay at best with VS Code, and you couldn’t pay me to use Xcode. Kotlin tried doing similar things to gain adoption on the server side. But server-side programming is a crowded space, and people just don’t like writing distsys code in another JVM language. Swift’s story is a little better on that front. If you want a quick-and-dirty language, Python and TypeScript do the job. For perf-sensitive, highly concurrent environments, Go is hard to compete against. A lot of ops tooling and infra code is written in Go. For systems programming and embedded code, Rust is a better choice. So while it’s fun to think about what language X gives you in terms of syntax, in practice it’s rarely enough to pick a language like Swift for your next non-toy backend distsys work. Also, Apple. Given their stance against free and open source software, I wouldn't be too thrilled to pick a language that works better in their walled garden.
- myko 9mo ago
  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.
  - rednafi 9mo ago
    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.
- jabwd 9mo ago
  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.
zozbot234 9mo ago
"Convenience" here basically means giving up semantic precision https://www.alilleybrinker.com/mini/rusts-culture-of-semantic-precision/ https://www.alilleybrinker.com/mini/rusts-culture-of-semanti... It's not clear that this is genuinely desirable.
HippoBaro 9mo ago
> Rust invented the concept of ownership as a solution memory management issues without resorting to something slower like Garbage Collection or Reference Counting. This is plain wrong, and it undermines the credibility of the author and the rest of the piece. Rust did not invent ownership in the abstract; it relies on plain RAII, a model that predates Rust by decades and was popularized by C++. What Rust adds is a compile-time borrow checker that enforces ownership and lifetime rules statically, not a fundamentally new memory-management paradigm.
- frizlab 9mo ago
  Thank you for saying that. It makes me crazy every time I read that rust invented the concept of ownership…
zenlot 9mo ago
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 ;)
Alex_L_Wood 9mo ago
One of the Swift’s worst parts is how Apple keeps putting features in there just for the sake of SwiftUI.
- MattDamonSpace 9mo ago
  You can just not use them
  - hn-acct 9mo ago
    First, op should mention which ones but they won't.
MarginalGainz 9mo ago
[dead]
worik 9mo ago
I am unconvinced I have used Swift (stopped about two years ago) and use Rust extensively these days. People commenting here have mentioned the dreadful Xcode. But if you want to build systems on Apple, without investing a lot in setup, you are stuck with Xcode. To be clear it's failures as an editor or build system are not the main problems with Xcode (albethey very frustrating when the intermittent problems show up) it is the abject failure of the tooling. We never got the profiler to produce anything intelligible after days of trying, spread over several weeks. SwiftUI is not part of the conversation here, and I limit the amount of UI building I do, but it shares all the problems of declarative UI frameworks - mainly "where is the code?". Debugging logic problems is nigh impossible in code you're unfamiliar with The very worst part of Swift were the thread control. Trivial to overwrite shared memory, "DispatchQueus" (?IIRC?) are a thin wrap of fork, and do nothing but add complications Swift is probably better than Objective C, the latter being from the 1980s, and things have moved on, if your target is iOS and friends, and you are sure you never want to port, then obeying Apple is a wise business decision. Other than that stay away from it. Use Go for most things, and Rust when you must
- airstrike 9mo ago
  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
  - worik 9mo ago
    > 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
    - positron26 9mo ago
      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.
nixpulvis 9mo ago
> Swift takes Rust’s ideas and hides them in C-like syntax. This example doesn't show me any meaningful difference, and Rust also let's you attach functionality to enums.
- isodev 9mo ago
  Swift tends to overuse enums, for example people would use them instead of namespaces or when they want a function but don’t want to create a class or a struct which in my opinion has always felt like a work-around for language deficiencies.
- kibwen 9mo ago
  It also assumes that "C-like syntax" is a desirable thing. Many of the worst parts of Rust syntax (and Swift syntax, and Java syntax, and Javascript syntax, and...) are things it took from C.
mirekrusin 9mo ago
MoonBit lang is better "better Rust" than Swift.
heavyset_go 9mo ago
Are Core Foundation and Foundation Kit still macOS-only?
- saagarjha 9mo ago
  Foundation has a Linux implementation.
thomassmith65 9mo ago
I lived and breathed Swift for the first five or six years of its existence. When people compliment it, I assume they haven't used it long enough to hate it. Swift is a mix of great features, miserable features, and... every other feature that someone on Evolution dreamt up (with the exception of those that would fix the miserable features) Swift is unique among high-level languages in that the mental effort required to do many simple things rivals that of a low-level language.
- ks2048 9mo ago
  I think you have to give some examples.
  - thomassmith65 9mo ago
    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!
    - saagarjha 9mo ago
      Low level languages don’t even have those features.
      - thomassmith65 9mo ago
        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.
        9mo ago
kibwen 9mo ago
> 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-explains-why-it-stopped-developing-arc/ 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.
- CharlesW 9mo ago
  FWIW, Swift for Windows is a thing (https://www.swift.org/install/windows/ https://www.swift.org/install/windows/), and there's a new Windows-specific workgroup: https://www.swift.org/blog/announcing-windows-workgroup/ https://www.swift.org/blog/announcing-windows-workgroup/
  - ternaryoperator 9mo ago
    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.
    - torginus 9mo ago
      Does Swift not have an automatic bindings generator for C headers?
csmantle 9mo ago
Swift has little to no toolchain support for less-common platforms like more recent MIPS, LA and alike. I frequently work and develop on such platforms, so sadly this is the major nay for me to use it.
Larrikin 9mo ago
Kotlin and Swift came in to popularity around the same time. They felt extremely similar at the beginning Kotlin put a lot of work into proving itself as something more than just a language for Android development, starting first with backend. It seems like once KMP became viable Swift is just trying catch back up.
- cosmic_cheese 9mo ago
  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.
- pjmlp 9mo ago
  For us grey beards, both are basically Object Pascal/Modula-2/Delphi for new generations.
politelemon 9mo ago
I can trust the community behind Rust. I cannot trust the company behind swift. They hold a stance that is against open source, and this stance can affect swift at any time, so I wouldn't want to invest into something that could be affected at a whim. It is certainly not convenient.
Zak 9mo ago
> Except this switch statement is actually not a switch statement at all. It’s an expression. It doesn’t “fallthrough”. It does pattern matching. It’s just a match expression with a different name and syntax. Giving a familiar name to a concept which behaves in familiar ways some of the time and surprising ways other times seems like a dirty trick to me, not a convenience.
g947o 9mo ago
"The compiler is unable to type-check this expression in reasonable time; try breaking up the expression into distinct sub-expressions" doesn't feel convenient to me.
Validark 9mo ago
> 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!!"
- throwaway17_17 9mo ago
  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?
dzonga 9mo ago
I once wrote a swift server app - hell even did a show hn over here last time when I used Swift was v3 - and transition from v2 was a little rough. the language kept adding features becoming a baby C++ if they had invested in bringing outside parties early on - not just iOS etc - swift would've replaced python
cosmic_cheese 9mo ago
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.
- kibwen 9mo ago
  Immediate mode GUIs like egui are imperative: https://www.egui.rs/ https://www.egui.rs/
FranklinJabar 9mo ago
[dead]
999900000999 9mo ago
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.
Mawr 9mo ago
> without resorting to something slower like Garbage Collection or Reference Counting Hah! But RC is GC! [1] > Again, this is just deception for those developers coming from C-like languages. Swift’s error handling works exactly like Rust’s behind the scenes, but it is hidden in a clever, familiar syntax. But the indent heavy syntax is one of the worst parts of exceptions? Rust: fn value_in_cents(coin: Coin) -> u8 { Swift: func valueInCents(coin: Coin) -> Int { Well, that settles it — it is known languages that use snake_case are superior. > This is because Rust is fast by default, and lets you be slow, while Swift is easy by default and lets you be fast. Good, good, you're onto something here. > There is a perception that Swift is only a good language for Apple platforms. While this was once true, this is no longer the case and Swift is becoming increasingly a good cross-platform language. Sigh. But you just said defaults matter, come on. Let me paraphrase: "This is because Swift is for Apple platforms by default, while Rust is cross-platform by default." [1]: https://www.youtube.com/watch?v=NdREEcfaihg https://www.youtube.com/watch?v=NdREEcfaihg
prairieroadent 9mo ago
[dead]
nubg 9mo ago
> to do reference counting and “clone-on-right” in your code Was this article vibe dictated?
morshu9001 9mo ago
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.
- saagarjha 9mo ago
  > Infuriating strings lib. Kinda believe the entire language was designed around emojis. Unicode but yes
  - morshu9001 9mo ago
    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.
    - saagarjha 9mo ago
      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.
      - morshu9001 9mo ago
        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.
fooker 9mo ago
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.
syspec 9mo ago
I think this title is doing more harm than good. Both are great languages
deleted 9mo ago
[deleted]
ChrisArchitect 9mo ago
(2023) Some previous discussion: 2024 https://news.ycombinator.com/item?id=41464371 https://news.ycombinator.com/item?id=41464371
bla3 9mo ago
Since then, Swift also grew excellent C++ interop, something Rust doesn't have at all.
- k_g_b_ 9mo ago
  In the long run https://github.com/google/crubit 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.
dang 9mo ago
Related. Others? Swift is a more convenient Rust - https://news.ycombinator.com/item?id=41464371 https://news.ycombinator.com/item?id=41464371 - Sept 2024 (308 comments)
porcoda 9mo ago
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.
jsomedon 9mo ago
Looks like the post was written in 2023, I wonder how much better did Swift get in crossplatform department these days?
smallstepforman 9mo ago
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).
dvfjsdhgfv 9mo ago
> 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?
- saagarjha 9mo ago
  Make it look like Rust mostly
jbverschoor 9mo ago
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 https://github.com/jrz/tools
tonyedgecombe 9mo ago
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.
VerifiedReports 9mo ago
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.
Degorath 9mo ago
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).
codr7 9mo ago
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.
jeremychone 9mo ago
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.
eviks 9mo ago
> 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)?
sharno 8mo ago
You still lose the benefits of Affine Types in Rust though

328 points by behnamoh 9mo ago

bigyabai 9mo ago

Glad to see "Swift is good now" taking the place of "year of the Linux desktop" in a post-Steam Deck world.

ewuhic 9mo ago

>Swift is more convenient Rust Nah.

Blackarea 9mo ago
... Literally ruined https://youtube.com/clip/UgkxFZA4XXnXzHyNso0OQ28XU60U1-jdR13S?si=86lp__cBQ_uuDgQy https://youtube.com/clip/UgkxFZA4XXnXzHyNso0OQ28XU60U1-jdR13...

dagmx 9mo ago

There’s definitely areas where I agree Swift is more ergonomic. Parameter defaults, and null short circuiting are two of them. I find writing Swift is faster for me, and it’s easier to learn for people than Rust. Also Swift interop with other languages is much simpler. Though there are way fewer resources to learn Swift, and cargo is superior to SPM. And of course rust is better cross platform today, but Swift is closing the gap. I think they feel like very similar languages overall, and they both influence each other.

killingtime74 9mo ago

Even if it's the same (faster horse?) I would rather use Rust for the fact it's development is not tied to a big tech company which could abandon it if they liked. Yes it could continue on as a fork but it's development velocity would suffer.

threatofrain 9mo ago
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.
- kibwen 9mo ago
  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.
  - j3th9n 9mo ago
    Such bullshit, macOS is the best OS for power users.
    - deleted 9mo ago
      [deleted]
    - kibwen 9mo ago
      MacOS was only the best OS for power users between 1994 and 2008, at which point they shifted to x86.
      - j3th9n 9mo ago
        And it still is the best OS for power users.
    - bigyabai 9mo ago
      Power users of Subway Surfers, maybe. Modern macOS is a tragedy: https://eclecticlight.co/2021/08/12/is-apple-keeping-its-promises-over-online-ocsp-certificate-checks/ https://eclecticlight.co/2021/08/12/is-apple-keeping-its-pro...
nomel 9mo ago
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) https://en.wikipedia.org/wiki/Swift_(programming_language)
- heavyset_go 9mo ago
  It's about as maintained by the "open source community" as Android is lol
- Aurornis 9mo ago
  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.
- dochtman 9mo ago
  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.
- piyuv 9mo ago
  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.
  - vor_ 9mo ago
    > 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.
Hamuko 9mo ago
A lot of Apple's software is written in Swift now. It's probably not in their interest to abandon the language.
- HaloZero 9mo ago
  I mean they did switch from objective c. At some point they might switch again if it makes sense.
  - hokumguru 9mo ago
    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.
  - cube00 9mo ago
    Especially if the promise of coding agents porting between languages is even partially realised it could make it very easy for them to switch.
rvz 9mo ago
> 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.
- sealeck 9mo ago
  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)...
  - behnamoh 9mo ago
    > 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.
    - sealeck 9mo ago
      Apple is selling Swift as a product - it is their preferred interface for constructing iOS applications!
      - pjmlp 9mo ago
        Kubernetes and Docker, CNCF is full of commercial products.
        sealeck 8mo ago
        Go is an implementation detail for Kubernetes and Docker...

IshKebab 9mo ago

Interesting. I'm not totally sold - still seems like Swift is quite niche and Apple-specific - but I might take another look. Also you might want to rework the `Box` example because you don't actually need to use `Box` in that case - the `Vec` already provides indirection.

xannabelle 9mo ago

I was surprised how similar their approach was to memory management. The creator is doing the same thing for Python as they did for Objective-C, making way for a new wave of Swift and Mojo, although we'll have to see if the latter grows to the same success.

SkiFire13 9mo ago

> Consider an enum that represents a tree. Since, it is a recursive type, Rust will force you to use something like Box<> for referencing a type within itself. > > enum TreeNode<T> { > Leaf(T), > Branch(Vec<Box<TreeNode<T>>>), > } > > (You could also us Box<Vec<TreeNode<T>>> instead) This is wrong, you don't need a `Box` here. The Rust compiler forces you to have a layer of indirection, but `Vec` already does that.

JackYoustra 9mo ago
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.
- nielsbot 9mo ago
  I don't think it's horrible, but I really do wish they would copy TypeScript here. Let me do this: const x: String | Int Instead of enum MyEnum { case string(String) case int(Int) } There's an existing proposal for this here: https://forums.swift.org/t/re-proposal-type-only-unions/72700 https://forums.swift.org/t/re-proposal-type-only-unions/7270...
  - Mond_ 9mo ago
    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.
    - ekimekim 9mo ago

JackYoustra 9mo ago

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.

hboon 9mo ago
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.
- jbverschoor 9mo ago
  Well same for typescript
fragmede 9mo ago
And the licensing agreement. How do I do it on Linux with no Mac or iOS?

amelius 9mo ago

> Swift is better for writing UI and servers and some parts of compilers and operating systems. For UI, why would anyone choose a language that has no automatic GC that can handle cycles?

keyle 9mo ago
Look up the language and ARC.
- astrange 9mo ago
  ARC doesn't do cycles, but it is deterministic and more power efficient than GC.
  - amelius 9mo ago
    So use a language that supports both.
    - astrange 9mo ago
      That would only have the disadvantages of both.
mh2266 9mo ago
weak delegates seem to work fine...?

OrangeDelonge 9mo ago

I generally like Swift, but async is a mess, it feels like they come up with a new async library every release

hn-acct 9mo ago
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.
- apt-apt-apt-apt 9mo ago
  Can you explain a bit more on what changed with 6.2+ that is now better?
  - saagarjha 9mo ago
    Far fewer actor hops by default which usually makes it easier to write correct code
  - hn-acct 9mo ago
    https://github.com/swiftlang/swift-evolution/blob/main/proposals/0449-nonisolated-for-global-actor-cutoff.md https://github.com/swiftlang/swift-evolution/blob/main/propo... https://github.com/swiftlang/swift-evolution/blob/main/proposals/0461-async-function-isolation.md https://github.com/swiftlang/swift-evolution/blob/main/propo... https://github.com/swiftlang/swift-evolution/blob/main/proposals/0463-sendable-completion-handlers.md https://github.com/swiftlang/swift-evolution/blob/main/propo... https://github.com/swiftlang/swift-evolution/blob/main/proposals/0466-control-default-actor-isolation.md 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/proposals/0493-defer-async.md 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.

suddenlybananas 9mo ago

I don't really see the advantage of switch statements over match statements.

beshrkayali 9mo ago

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-game/ https://log.beshr.com/notes-on-swift-from-building-an-ios-ga...

bloomca 9mo ago
I personally never seen anything as bad as XCode, but granted, I haven't used really old IDEs (always preferred just editors). Last year I built a few small apps using both XCode/Swift and Visual Studio/C# and using MS stack felt like you are living in the future, despite WinUI having a very dated UI syntax.

gary17the 9mo ago

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 https://doc.rust-lang.org/book/ch15-04-rc.html [2] https://doc.rust-lang.org/book/ch15-05-interior-mutability.html https://doc.rust-lang.org/book/ch15-05-interior-mutability.h...

rjh29 9mo ago
It gets really verbose though!
- virtualritz 9mo ago
  > It gets really verbose though! Nope, you just use wrapper types (which you should anyway).
Cyph0n 9mo ago
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.
torginus 9mo ago
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.

mogoh 9mo ago

> There is a perception that Swift is only a good language for Apple platforms. While this was once true, this is no longer the case and Swift is becoming increasingly a good cross-platform language. How good is the developer experience on a non-Apple platform really? Linux is my primary platform and my perception is, that allmost all of the swift eco system is for Apple. Libraries, tools, documentation, IDEs, tutorials, etc. all assume, that you use an Apple. Can someone tell me who does not use an Apple-device and uses swift?

rcarmo 9mo ago
I tried doing compiling a few of my Mac CLI tools to Linux. These days, it's faster to run them through an LLM and get quite excellent Go at the other end, and _that_ is much easier to cross-compile. I have been looking at the new Android support (don't have the link handy) and it's tempting, but I know Kotlin and always developed for Android with a bare Makefile and the JDK, so I don't need any fancy tooling...
WD-42 9mo ago
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.
- sealeck 9mo ago
  > 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).
  - wolvoleo 9mo ago

isodev 9mo ago

Until you get to the Swift concurrency stuff, or you try to use Swift on a backend or non-Apple system - then it’s hot garbage. If Rust is too low level for you, you can write Go or Kotlin or even something new and fresh like Gleam.

frizlab 9mo ago
Except I did and it was good. When did you last try?
- isodev 9mo ago
  It’s what I do, every day. You maybe in need of a broader horizon for comparison

drcongo 9mo ago

This article made me actually interested in learning Swift. Anyone recommend a good place to start?

deryilz 9mo ago
The Swift Book is good for this: https://docs.swift.org/swift-book/documentation/the-swift-programming-language/ https://docs.swift.org/swift-book/documentation/the-swift-pr...
- Terretta 9mo ago
  After that, things like: https://www.hackingwithswift.com/learn https://www.hackingwithswift.com/learn https://www.hackingwithswift.com/quick-start/swiftui/ https://www.hackingwithswift.com/quick-start/swiftui/ https://sosumi.ai/ https://sosumi.ai/

rcarmo 9mo ago

Riiiiight. No. I'm a Mac user for decades, former Obj-C hacker, have tried and tried again and again to use Swift (and I have quite a few CLI apps written in it), but the thing has been a clusterfuck of paper cuts and very minor but significant changes over the years, and I gave up waiting for it to settle. And it's not a more convenient Rust. I'd rather use Zig or Go (neither of which are worthy in the eyes of true Crustaceans, but which just get the job done).

drnick1 9mo ago

No thanks, too tied to Apple and closed source development models.

usamoi 9mo ago

I really don't understand what's the point of such comparisons. Swift uses subtyping, while Rust uses typeclasses. Even looking only at their type systems, the two are completely different. You can't assume they are similar just because they both use the Latin alphabet.

slavapestov 9mo ago
> Swift uses subtyping, while Rust uses typeclasses. Even looking only at their type systems, the two are completely different. What does it mean to “use” subtyping vs typeclasses? Swift protocols are essentially typeclasses with associated types, just like Rust traits.

java-man 9mo ago

What is "clone-on-right"?

lucsky 9mo ago
A misspelling of "copy-on-write".

jdalsgaard 9mo ago

I would tend to disagree; fundamental to Rust is the concept of zero-cost abstraction. Swift does not do that. I my view, and I might be wrong, many features of Rust are chosen specifically to have the language comply to the zero-cost rule. Such as the ownership model.

isodev 9mo ago
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.
behnamoh 9mo ago
Swift also supports the ownership model.
- kibwen 9mo ago
  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.
- jdalsgaard 9mo ago
  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).

rickstanley 9mo ago

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 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 https://github.com/swiftlang/swift/issues/60690. No problem! They have a script for installing: https://www.swift.org/install/linux/ https://www.swift.org/install/linux/ curl -O https://download.swift.org/swiftly/linux/swiftly-$(uname -m).tar.gz && \ tar zxf swiftly-$(uname -m).tar.gz && \ ./swiftly init --quiet-shell-followup && \ . "${SWIFTLY_HOME_DIR:-$HOME/.local/share/swiftly}/env.sh" && \ hash -r But, god damn, the size is huge, Unsupported Linux platform Debian GNU/Linux 13 (trixie) is not an officially supported platform, but the toolchains for another platform may still work on it. Please select the platform to use for toolchain downloads: 0) Cancel 1) Ubuntu 24.04 2) Ubuntu 22.04 3) Ubuntu 20.04 4) Ubuntu 18.04 5) Fedora Linux 39 6) RHEL 9 7) Amazon Linux 2 8) Debian GNU/Linux 12 Pick one of the available selections [0-8] : 8 Installing swiftly in /home/debby/.local/share/swiftly/bin/swiftly... Creating shell environment file for the user... Updating profile... Fetching the latest stable Swift release... Installing Swift 6.2.3 Downloading Swift 6.2.3 100% [========================================================] Downloaded 947.6 MiB of 947.6 MiB Verifying toolchain signature... Extracting toolchain... The file `/home/debby/ent/agateteper/.swift-version` has been set to `Swift 6.2.3` The global default toolchain has been set to `Swift 6.2.3` Swift 6.2.3 is installed successfully! There are some dependencies that should be installed before using this toolchain. You can run the following script as the system administrator (e.g. root) to prepare your system: apt-get -y install libicu-dev libcurl4-openssl-dev libedit-dev libsqlite3-dev libncurses-dev libpython3-dev libxml2-dev pkg-config uuid-dev libstdc++-12-dev 947.6 MiB ! I wonder why is that...

rednafi 9mo ago

Swift is a neat language, but it’s a hard sell for server-side software. The ecosystem is tiny, and there’s nothing you gain from using it instead of Go or Rust for infra / distsys. Also, it works okay at best with VS Code, and you couldn’t pay me to use Xcode. Kotlin tried doing similar things to gain adoption on the server side. But server-side programming is a crowded space, and people just don’t like writing distsys code in another JVM language. Swift’s story is a little better on that front. If you want a quick-and-dirty language, Python and TypeScript do the job. For perf-sensitive, highly concurrent environments, Go is hard to compete against. A lot of ops tooling and infra code is written in Go. For systems programming and embedded code, Rust is a better choice. So while it’s fun to think about what language X gives you in terms of syntax, in practice it’s rarely enough to pick a language like Swift for your next non-toy backend distsys work. Also, Apple. Given their stance against free and open source software, I wouldn't be too thrilled to pick a language that works better in their walled garden.

myko 9mo ago
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.
- rednafi 9mo ago
  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.
jabwd 9mo ago
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.

zozbot234 9mo ago

"Convenience" here basically means giving up semantic precision https://www.alilleybrinker.com/mini/rusts-culture-of-semantic-precision/ https://www.alilleybrinker.com/mini/rusts-culture-of-semanti... It's not clear that this is genuinely desirable.

HippoBaro 9mo ago

> Rust invented the concept of ownership as a solution memory management issues without resorting to something slower like Garbage Collection or Reference Counting. This is plain wrong, and it undermines the credibility of the author and the rest of the piece. Rust did not invent ownership in the abstract; it relies on plain RAII, a model that predates Rust by decades and was popularized by C++. What Rust adds is a compile-time borrow checker that enforces ownership and lifetime rules statically, not a fundamentally new memory-management paradigm.

frizlab 9mo ago
Thank you for saying that. It makes me crazy every time I read that rust invented the concept of ownership…

zenlot 9mo ago

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 ;)

Alex_L_Wood 9mo ago

One of the Swift’s worst parts is how Apple keeps putting features in there just for the sake of SwiftUI.

MattDamonSpace 9mo ago
You can just not use them
- hn-acct 9mo ago
  First, op should mention which ones but they won't.

MarginalGainz 9mo ago

[dead]

worik 9mo ago

I am unconvinced I have used Swift (stopped about two years ago) and use Rust extensively these days. People commenting here have mentioned the dreadful Xcode. But if you want to build systems on Apple, without investing a lot in setup, you are stuck with Xcode. To be clear it's failures as an editor or build system are not the main problems with Xcode (albethey very frustrating when the intermittent problems show up) it is the abject failure of the tooling. We never got the profiler to produce anything intelligible after days of trying, spread over several weeks. SwiftUI is not part of the conversation here, and I limit the amount of UI building I do, but it shares all the problems of declarative UI frameworks - mainly "where is the code?". Debugging logic problems is nigh impossible in code you're unfamiliar with The very worst part of Swift were the thread control. Trivial to overwrite shared memory, "DispatchQueus" (?IIRC?) are a thin wrap of fork, and do nothing but add complications Swift is probably better than Objective C, the latter being from the 1980s, and things have moved on, if your target is iOS and friends, and you are sure you never want to port, then obeying Apple is a wise business decision. Other than that stay away from it. Use Go for most things, and Rust when you must

airstrike 9mo ago
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
- worik 9mo ago
  > 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
  - positron26 9mo ago
    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.

nixpulvis 9mo ago

> Swift takes Rust’s ideas and hides them in C-like syntax. This example doesn't show me any meaningful difference, and Rust also let's you attach functionality to enums.

isodev 9mo ago
Swift tends to overuse enums, for example people would use them instead of namespaces or when they want a function but don’t want to create a class or a struct which in my opinion has always felt like a work-around for language deficiencies.
kibwen 9mo ago
It also assumes that "C-like syntax" is a desirable thing. Many of the worst parts of Rust syntax (and Swift syntax, and Java syntax, and Javascript syntax, and...) are things it took from C.

mirekrusin 9mo ago

MoonBit lang is better "better Rust" than Swift.

heavyset_go 9mo ago

Are Core Foundation and Foundation Kit still macOS-only?

saagarjha 9mo ago
Foundation has a Linux implementation.

thomassmith65 9mo ago

I lived and breathed Swift for the first five or six years of its existence. When people compliment it, I assume they haven't used it long enough to hate it. Swift is a mix of great features, miserable features, and... every other feature that someone on Evolution dreamt up (with the exception of those that would fix the miserable features) Swift is unique among high-level languages in that the mental effort required to do many simple things rivals that of a low-level language.

ks2048 9mo ago
I think you have to give some examples.
- thomassmith65 9mo ago
  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!
  - saagarjha 9mo ago
    Low level languages don’t even have those features.
    - thomassmith65 9mo ago
      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.
      - 9mo ago

kibwen 9mo ago

> 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-explains-why-it-stopped-developing-arc/ 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.

CharlesW 9mo ago
FWIW, Swift for Windows is a thing (https://www.swift.org/install/windows/ https://www.swift.org/install/windows/), and there's a new Windows-specific workgroup: https://www.swift.org/blog/announcing-windows-workgroup/ https://www.swift.org/blog/announcing-windows-workgroup/
- ternaryoperator 9mo ago
  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.
  - torginus 9mo ago
    Does Swift not have an automatic bindings generator for C headers?

csmantle 9mo ago

Swift has little to no toolchain support for less-common platforms like more recent MIPS, LA and alike. I frequently work and develop on such platforms, so sadly this is the major nay for me to use it.

Larrikin 9mo ago

Kotlin and Swift came in to popularity around the same time. They felt extremely similar at the beginning Kotlin put a lot of work into proving itself as something more than just a language for Android development, starting first with backend. It seems like once KMP became viable Swift is just trying catch back up.

cosmic_cheese 9mo ago
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.
pjmlp 9mo ago
For us grey beards, both are basically Object Pascal/Modula-2/Delphi for new generations.

politelemon 9mo ago

I can trust the community behind Rust. I cannot trust the company behind swift. They hold a stance that is against open source, and this stance can affect swift at any time, so I wouldn't want to invest into something that could be affected at a whim. It is certainly not convenient.

Zak 9mo ago

> Except this switch statement is actually not a switch statement at all. It’s an expression. It doesn’t “fallthrough”. It does pattern matching. It’s just a match expression with a different name and syntax. Giving a familiar name to a concept which behaves in familiar ways some of the time and surprising ways other times seems like a dirty trick to me, not a convenience.

g947o 9mo ago

"The compiler is unable to type-check this expression in reasonable time; try breaking up the expression into distinct sub-expressions" doesn't feel convenient to me.

Validark 9mo ago

> 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!!"

throwaway17_17 9mo ago
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?

dzonga 9mo ago

I once wrote a swift server app - hell even did a show hn over here last time when I used Swift was v3 - and transition from v2 was a little rough. the language kept adding features becoming a baby C++ if they had invested in bringing outside parties early on - not just iOS etc - swift would've replaced python

cosmic_cheese 9mo ago

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.

kibwen 9mo ago
Immediate mode GUIs like egui are imperative: https://www.egui.rs/ https://www.egui.rs/

FranklinJabar 9mo ago

[dead]

999900000999 9mo ago

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.

Mawr 9mo ago

> without resorting to something slower like Garbage Collection or Reference Counting Hah! But RC is GC! [1] > Again, this is just deception for those developers coming from C-like languages. Swift’s error handling works exactly like Rust’s behind the scenes, but it is hidden in a clever, familiar syntax. But the indent heavy syntax is one of the worst parts of exceptions? Rust: fn value_in_cents(coin: Coin) -> u8 { Swift: func valueInCents(coin: Coin) -> Int { Well, that settles it — it is known languages that use snake_case are superior. > This is because Rust is fast by default, and lets you be slow, while Swift is easy by default and lets you be fast. Good, good, you're onto something here. > There is a perception that Swift is only a good language for Apple platforms. While this was once true, this is no longer the case and Swift is becoming increasingly a good cross-platform language. Sigh. But you just said defaults matter, come on. Let me paraphrase: "This is because Swift is for Apple platforms by default, while Rust is cross-platform by default." [1]: https://www.youtube.com/watch?v=NdREEcfaihg https://www.youtube.com/watch?v=NdREEcfaihg

prairieroadent 9mo ago

[dead]

nubg 9mo ago

> to do reference counting and “clone-on-right” in your code Was this article vibe dictated?

morshu9001 9mo ago

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.

saagarjha 9mo ago
> Infuriating strings lib. Kinda believe the entire language was designed around emojis. Unicode but yes
- morshu9001 9mo ago
  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.
  - saagarjha 9mo ago
    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.
    - morshu9001 9mo ago
      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.

fooker 9mo ago

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.

syspec 9mo ago

I think this title is doing more harm than good. Both are great languages

deleted 9mo ago

[deleted]

ChrisArchitect 9mo ago

(2023) Some previous discussion: 2024 https://news.ycombinator.com/item?id=41464371 https://news.ycombinator.com/item?id=41464371

bla3 9mo ago

Since then, Swift also grew excellent C++ interop, something Rust doesn't have at all.

k_g_b_ 9mo ago
In the long run https://github.com/google/crubit 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.

dang 9mo ago

Related. Others? Swift is a more convenient Rust - https://news.ycombinator.com/item?id=41464371 https://news.ycombinator.com/item?id=41464371 - Sept 2024 (308 comments)

porcoda 9mo ago

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.

jsomedon 9mo ago

Looks like the post was written in 2023, I wonder how much better did Swift get in crossplatform department these days?

smallstepforman 9mo ago

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).

dvfjsdhgfv 9mo ago

> 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?

saagarjha 9mo ago
Make it look like Rust mostly

jbverschoor 9mo ago

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 https://github.com/jrz/tools

tonyedgecombe 9mo ago

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.

VerifiedReports 9mo ago

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.

Degorath 9mo ago

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).

codr7 9mo ago

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.

jeremychone 9mo ago

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.

eviks 9mo ago

> 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)?

sharno 8mo ago

You still lose the benefits of Affine Types in Rust though