Swift is a more convenient Rust (2023)

https://nmn.sh/blog/2023-10-02-swift-is-the-more-convenient-rust

by behnamoh • 6 months ago

328 357 6 months ago

nmn.sh

bigyabai2• 6 months ago

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

ewuhic• 6 months ago

Swift is more convenient Rust

Nah.

Blackarea• 6 months ago

... Literally ruined

https://youtube.com/clip/UgkxFZA4XXnXzHyNso0OQ28XU60U1-jdR13...

dagmx• 6 months 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• 6 months 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• 6 months 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.

kibwen10• 6 months 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.

satvikpendem2• 6 months ago

Rust of all languages, now that it's been majorly adopted by many companies big and small, has a higher risk of losing support over a language developed exclusively by one corporation? I sincerely doubt that.

nomel• 6 months 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)

Aurornis2• 6 months 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• 6 months 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• 6 months 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.

WD-423• 6 months ago

Yup just like google doesn’t actually control chromium right

afavour3• 6 months ago

But the fact remains that if Apple abandoned Swift tomorrow the language would almost certainly wither and die.

heavyset_go3• 6 months ago

It's about as maintained by the "open source community" as Android is lol

Hamuko• 6 months ago

A lot of Apple's software is written in Swift now. It's probably not in their interest to abandon the language.

HaloZero• 6 months ago

I mean they did switch from objective c. At some point they might switch again if it makes sense.

rvz• 6 months 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.

sealeck4• 6 months 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)...

cube002• 6 months ago

IMHO your case for a moot point would be stronger if you also mentioned which company you feel is tied to Rust in the same way as the other languages you've mentioned.

kibwen10• 6 months ago

Objective-C had its own open source source implementations, along with a better cross-platform story than Swift has ever had, and yet Apple's abandonment still managed to reduce it to irrelevance.

thayne2• 6 months ago

I have similar concerns about c# as I do about swift.

I'm less concerned about go, because unlike swift and c# it was designed from the beginning to be cross-platform and if anything Linux is the best supported OS. But barely so. Also, if Google were to discontinue support, or change the license, or do something else disruptive, I have more faith that the ecosystem would create a fork to continue the language.

FWIW, my biggest concern isn't that the language would be completely abandoned, it is that the company would diminish or drop support for tooling on OSes and editors and IDEs that compete with the company's products (Mac OS and Xcode for apple, Windows and Visual Studio for MS).

IshKebab• 6 months 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• 6 months 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• 6 months 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.

JackYoustra9• 6 months 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.

nielsbot2• 6 months 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/7270...

frizlab8• 6 months ago

I don’t which Swift developers you are talking to, but let the record know I don’t and use enum quite a lot. And I don’t find it particularly painful though a bit verbose at times.

vor_2• 6 months ago

actually using swift enums and protocols is so painful.

In what way? My understanding is they're widely used and encouraged.

YmiYugy• 6 months ago

I don't think that is true. Testing with rust 1.92

enum Tree<T> { Lead(T), Branch(Vec<Tree<T>>), }

works just fine, no superfluous Box needed.

slavapestov2• 6 months ago

Similarly, the ‘indirect’ keyword can be omitted from Swift example in the blog post, for the same reason. A Swift Array stores its elements out of line, so an enum case payload can be an array type whose element contains the same enum, without any additional indirection.

LukaD• 6 months ago

You don't need Box here because Vec<T> is already a fixed size handle to heap data.

slaymaker1907• 6 months ago

A vector of boxes is beneficial if you need to move objects around. If each T is 1000B or something, you really don’t want to copy or even do true moves in memory.

Hell, even if you’re not moving things around explicitly, don’t forget that vectors resize themselves. If you use Box, then these resizes will be less painful with large objects.

tialaramex2• 6 months ago

In one sense the places where the Rust is wrong don't trouble me because I already know Rust well, but in the end they do trouble me because it seems reasonable to assume the Swift is equally wrong but I don't know where and how.

For example "In fact, Swift treats enums as more than just types and lets you put methods directly on it" seems to assume that "just types" don't have methods, which I guess is what you might assume coming from say, C++ but Rust isn't C++ and so of course all of its types, including not only user-defined enums, structures and indeed unions can have methods - but also the built-in primitive types all have methods too.

    'F'.to_digit(16).unwrap() // is the 32-bit unsigned integer constant 15

Or maybe an even closer to the metal example: Rust's pointer provenance APIs get to provide a method on raw pointers which takes a closure to do stuff like hide boolean flag bits at the bottom of an aligned pointer. The fact that you're ultimately going to lower to an XOR on a CPU address register doesn't mean you shouldn't get method syntax, it's the 21st century.

mh22663• 6 months ago

In fact, Swift treats enums as more than just types and lets you put methods directly on it

This section was fairly disappointing, that Rust requires you to put "} impl {" between the `enum` and its methods is... not really an interesting point.

I think the title of the article is... basically correct, and the high-level point that they're both languages with modern type systems, sum types, pattern matching, and so on is good, but too many of the examples were weak.

saghm• 6 months ago

You're not wrong, but I think there's a subtle way people still might get confused about `Vec` versus `Box` with the way you've phrased it. I'd argue the important characteristic of `Vec` here isn't that it's indirection but specifically that it's sized at compile time. Compared to a `Box`, it does not provide meaningful indirection around types that are themselves not sized at compile time (e.g. dyn trait objects), and storing them inside a `Vec` itself will require a `Box` or something similar.

JackYoustra9• 6 months 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.

fragmede• 6 months ago

And the licensing agreement. How do I do it on Linux with no Mac or iOS?

JackYoustra9• 6 months ago

You can develop Swift without it. I assume you mean SwiftUI / apple's sdk, which is what most people assume (a note, I'd say, to advocates of Swift who wish not to address SwiftUI: it's the biggest target, and its poor performance on it should speak volumes about the language).

You can also sometimes avoid xcode, see https://github.com/xtool-org/xtool

although, at this point, just use expo!

bjtitus• 6 months ago

Swift has builds for Linux: https://www.swift.org/install/linux/

The license is pretty much Apache 2.0

snickell• 6 months ago

Swift is available for Linux, license is Apache 2.0. There's even swift bindings for some linux ecosystem libraries, e.g. adwaita-swift for writing gnome apps and qt bindings for writing kde apps.

dfabulich• 6 months ago

If you're not developing an iOS/macOS app, you can skip Xcode completely and just use the `swift` CLI, which is perfectly cromulent. (It works great on Linux and Windows.)

behnamoh5• 6 months ago

Even if you're developing for macOS you can skip xcode. I've had a great time developing a menubar app for macOS and not once did I need to open xcode.

mort962• 6 months ago

I would avoid it for Linux and Windows. Even if they are "technically supported", Apple's focus is clearly macOS and iOS. Being a second- (or even third-) class citizen often introduces lots of issues in practice ("oh, nobody teenaged that functionality on Windows"...)

alwillis3• 6 months ago

There'a great indie app called Notepad.exe [1] for developing iOS and macOS apps using macOS. You can also write and test Swift apps for Linux easily [2]. It also supports Python and JavaScript.

If you hate Xcode, this is definitely worth a look.

[1] https://notepadexe.com

[2] https://notepadexe.com/news/#notepad-14-linux-support

stackghost2• 6 months ago

FWIW I have written a complete macOS cocoa+swift app in emacs alone without XCode, just using Makefiles. You don't strictly need it.

fluffybeing• 6 months ago

Can you share your configs or link to it? Would love to learn how you did it?

mrcwinn• 6 months ago

Totally agree. Xcode is awful. I’m sure that team has a lot to deal with but they’ve produced since really trash software.

doawoo• 6 months ago

+1 I went out of my way to set up a skeleton project that just uses shell scripts to build an app bundle. I really dislike Xcode but Swift itself is actually fun to write.

lawgimenez• 6 months ago

Hours ago I was setting up Xcode Cloud on Xcode and it kept crashing whenever I edited the workflow. Smh

blueprint4• 6 months ago

I know Xcode might struggle every now and then with some of the things you're talking about and I'm not saying that I don't have any feedback for Apple, but Xcode is one of the most powerful and well designed development and instrumentation environments I've ever used.

peyton• 6 months ago

+1 blows the pants off anything else I’ve touched with zero config fiddling. Great stuff.

jayd162• 6 months ago

I can't say you hear a lot of folks on other OSes with other IDEs saying "I wish I had Xcode". There was a minute when MonoDevelop was trying to emulate Xcode but that must be over a decade ago.

andoando• 6 months ago

Weird the little Ive used it I completely hated it.

Errors everywhere with horrible messages that leave you no idea whats wrong

cosmic_cheese5• 6 months ago

Personally speaking I don’t get the hubbub around Jetbrains and MS IDEs. Like they’re not bad by any means but they have their own sets of idiosyncrasies and bugs… it just depends on which set you happen to run up against most often in your day to day.

hedora• 6 months ago

My one experience with swift involved calling a macos api not written in swift, but that had ergonomic swift bindings from Apple.

My code was data race free, but the underlying OS primitive wasn’t, so my program crashed out about 10% of the time.

This isn’t really a criticism of swift as a language, but I haven’t had this sort of problem with the rust ecosystem.

jtrueb• 6 months ago

Yes! I’m not sure how many people arguing for one or the other have tried both, but it is clear that you know the pain.

atombender6• 6 months ago

I've made a tiny SwiftUI app. It was really difficult to figure out the memory leaks. In fact, I have leaks that I still haven't been able to find. For some reason the heap is fine, but the app continues to allocate virtual memory.

I've thrown Claude and Gemini at the app to try to analyze the code, had them use vmmap and Instruments, asked them run all of the code in a loop to reproduce the leakage — and still it leaks, slowly, tens of megabytes per day.

I'm sure it's something simple starting me in the face. But the fact remains that Swift's sort-of-automatic-but-not-quite memory model still makes it much harder to reason about memory than Rust or even Go.

cosmic_cheese5• 6 months ago

Personally I avoid using SwiftUI except in bite size chunks like collection view cells. It’s great for that kind of use case but doesn’t scale up well.

I wasn’t of the mind that AppKit/UIKit really needed replacing in the first place, though…

heavyset_go3• 6 months ago

What's the issue if it allocates virtual memory?

teunispeters• 6 months ago

hunting dangling references in a reference counted system is like that.... that's all I can guess is going on here. Good hunting! I wonder if there's a resource debugger? So far when I have really had to look, xcode was suffiicent... but there's likely better out there for finding this kind of thing.

groundzeros20152• 6 months ago

The memory management is almost broken. They decided not crashing was better than mashing memory.

rTX5CMRXIfFG• 6 months ago

I agree, but I think that it's difficult to spot memory leaks in SwiftUI because it's such a high-level abstraction framework. When working with the Cocoa and Cocoa Touch libraries, it's so much easier to find.

And of course, Apple's UI frameworks != Swift the language itself.

jabwd3• 6 months ago

I'm sorry but what exactly are you doing? This is the first time I've ever heard any of this type of reasoning, and well, the fact that you're using AI makes me think you have no clue what you're actually talking about.

If its a reference cycle, instruments will find it. If it is a leak, instruments will find it. However, you seem to be worried about an implementation detail on how you get memory from your CPU which the mach kernel handles for you, and is something you don't quite grasp.

please don't reply with "I asked stupid generator", seriously, what is the actual issue you have?

saagarjha17• 6 months ago

Is it something you can share the code to?

lelanthran2• 6 months ago

There's no valgrind equivalent, I guess?

I mean, even if valgrind ran on MacOS, it may still not give anything meaningful because the debug symbols are probably not going to be the same as that generated by GCC, and even if they were the same, there's still gonna be a bunch of symbols "missing" because of internal swift name-mangling, and even if that wasn't the case, the emitted code might just not be ABI compatible with C anyway.

waffletower• 6 months ago

Perhaps try again and analyze for reference cycles between objects. I agree that ARC has painful subtleties. It existed prior to Swift, being introduced in Objective-C, and is definitely not a perfect memory model.

maksimpiriyev• 6 months ago

I experienced a similar problem, and upon further investigation, I discovered that it occurred in the parts of the code where Swift and Objective-C are bridged. The problem seemed to stem from either the bridging or an issue within the Objective-C code itself

willtemperley4• 6 months ago

Most Swift compilation slowness can be avoided by componentizing using packages, plus a few tricks like being explicit with types rather than relying on type inference.

I’m not sure why you’re having so much trouble with SPM though, most people seem to get on well with it.

cosmic_cheese5• 6 months ago

Experience with SPM might vary depending on how many dependencies you’ve got. A lot of Apple platform apps are quite thin on third party library use, in which case SPM is probably not a large source of trouble.

h4x0rr• 6 months ago

Using explicit types is less fun though

plagiarist• 6 months ago

SPM is fine for most Swift and then fully enraging when you have a slightly divergent use case. IME of course.

ElFitz2• 6 months ago

Trying to make a .xcframework from SPM is "fun". And getting the Objective-C that are generated, but treated as intermediary artifacts discarded is a bit of a pain.

But I guess the issue here is that .xcframework is an Apple thing, not a Swift thing.

The whole "won’t build if the product / target has the same name as one of its classes" is absolutely ridiculous on the other hand.

hn-acct8• 6 months ago

I'm also wondering how big their programs are that the compile times are an issue. I'm seeing fantastic build times with Xcode 16 and Xcode 26.2 with swift 6.2 it's even better. SPM is also better with the newer version. Most issues can be solved or exposed by closing the window and reopening or going to the package with issues and pressing cmd+s.

JackYoustra9• 6 months ago

Xcode (and as of a couple years ago the vscode spm integration) tends to have difficulty when scaling this solution.

Being explicit with types is very disruptive when used in SwiftUI or TCA.

frizlab8• 6 months ago

I still don’t understand the Xcode rant. Using Swift can be done in any LSP-compatible text editor (VSCode, which even has a first-party extension for Swift, but also zed, Sublime Text, etc.)

Unless you’re doing Apple-specific development, you don’t need Xcode.

teaearlgraycold• 6 months ago

What company is using Swift outside of Apple-specific development?

wolvoleo2• 6 months ago

Why would you bother using Swift if you're not targeting Apple? I can imagine wanting to use it for something cross-platform that is primarily an ios/macos thing.

But if you don't want to include those I wouldn't pick a language that's under control of a company I don't use.

It's a bit like using c# or powershell on Linux. Yes it can be done and it's helpful for cross platform with windows but I wouldn't consider it a first class citizen.

truncate• 6 months ago

LSP support isn't great. It keeps improving however. Used to get quite a few crashes. And I think background indexing still doesn't work.

hn-acct8• 6 months ago

Agreed. People use any thread mentioning swift to dunk on Apple for X number of reasons with vague details and regurgitated dogma. I get Xcode has quirks I use it everyday believe me I know but it's not that bad that it's unusable.

crowbahr• 6 months ago

I do think xcode is the worst IDE I've ever worked in, bar none. Even Eclipse from 2010 was better than xcode from 2025

ks20483• 6 months ago

As someone who basically only uses Emacs and Xcode- why is Xcode so bad?

latexr3• 6 months ago

Xcode

You don’t need it to program in Swift. I write a lot of it and never open Xcode, my terminal editor with LSP support is fantastic at it.

Imustaskforhelp3• 6 months ago

You don’t need it to program in Swift. I write a lot of it and never open Xcode, my terminal editor with LSP support is fantastic at it.

when you mention terminal editor, I think you are a Neovim user right?

geooff_• 6 months ago

Xcode truly is terrible.

ks20483• 6 months ago

I’m curious about SPM vs Cargo - are there basic design decisions that make Cargo better or just particularities of thier current states?

Imustaskforhelp3• 6 months ago

I also wish to ask given that uv from Python learnt from cargo,npm and other things. Can it be possible for SPM to have an alternative similar to how uv got made for python too?

(I am not familiar with swift which is why I am asking this question if there's a really big difference between Swift package manager and cargo in the first place to warrant a uv like thing for swift ecosystem. I think someone recently posted a uv alternative for ruby)

Rv, a new kind of Ruby management tool: https://news.ycombinator.com/item?id=45023730

hota_mazi• 6 months ago

Not mentioning the fact that Swift is nonexistent outside of the Apple ecosystem, and worse, Apple is explicitly not supporting it outside of the Apple operating systems.

hn-acct8• 6 months ago

https://www.swift.org/blog/announcing-windows-workgroup/ https://www.swift.org/blog/exploring-the-swift-sdk-for-andro... ?

andrekandre2• 6 months ago

  > imports are all implicitly module-scoped, meaning that changing a single file means recomputing the types for all files in the module

i've noticed this too... i wonder if doing scoped importing helps with this for example:

  import struct MyModule.MyStruct

JackYoustra9• 6 months ago

iirc you can't do this for extensions which being a huge amount of compiler constraint resolution time

easeout• 6 months ago

The main problem I have with the language is compile times. Rust is good at many things, but not that.

Xcode is optional, though its primacy has meant less adoption of Swift's first party LSP and VS Code extension.

hboon• 6 months 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.

jbverschoor2• 6 months ago

Well same for typescript

monster_truck• 6 months ago

SwiftUI is straight up the worst thing Apple has ever shipped. Absolute fucking pile of dogshit. They should be ashamed of themselves. Steve would have fired everyone and I mean that.

It remains the only UI framework I've prototyped something in where I've had to respond to a well paying client with a list of what it (still!) can't do, doesn't do well, and a long list of documentation that does not match the code. I have a sense of integrity so I do this work honestly. There are plenty of devs out there that will happily tell you xyz can be done just so that they're paid to make something they know will be subpar.

amelius2• 6 months 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• 6 months ago

Look up the language and ARC.

astrange2• 6 months ago

ARC doesn't do cycles, but it is deterministic and more power efficient than GC.

mh22663• 6 months ago

weak delegates seem to work fine...?

OrangeDelonge• 6 months ago

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

hn-acct8• 6 months 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• 6 months ago

Can you explain a bit more on what changed with 6.2+ that is now better?

suddenlybananas• 6 months ago

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

beshrkayali• 6 months 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-ga...

bloomca• 6 months 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• 6 months 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

[2] https://doc.rust-lang.org/book/ch15-05-interior-mutability.h...

rjh29• 6 months ago

It gets really verbose though!

virtualritz• 6 months ago

It gets really verbose though!

Nope, you just use wrapper types (which you should anyway).

Cyph0n• 6 months 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.

torginus4• 6 months 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.

steveklabnik2• 6 months ago

Rust tags every &mut T and every &T with the equivalent of restrict except for when the T transitively contains an UnsafeCell<T>. Types like Arc<T> and Rc<T> are built on top of UnsafeCell<T>.

Don’t use shared ownership? You get the semantics you want. It’s the norm for the vast majority of things.

mogoh• 6 months 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?

rcarmo2• 6 months 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-423• 6 months 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.

sealeck4• 6 months 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).

jiggawatts• 6 months ago

Arguably the dotnet sdk now works better on Linux than Windows. For example, Windows Containers are "supported" only the marketing checkbox sense.

myko2• 6 months ago

I ship a lot of .NET on Linux these days, works great

frizlab8• 6 months ago

Swift has swiftly to manage the Swift compilers to use (equivalent of rustup) and LSP works pretty well. Most of the (open-source) libs that Apple does are cross-platform. I personally take care to make sure my personal libs work on all platforms as well, including Windows(!) (anecdotal, I know…).

All in all it’s not perfect yet, but it’s getting better, with intent to continue in that direction.

willhbr• 6 months ago

My experience is that it is very frustrating. Apple's documentation makes no mention of what works on Linux and its limitations, so you just have to guess or work it out with trial and error.

I tried to write a websocket client: https://willhbr.net/2023/08/23/the-five-stages-of-swift-on-l... Then tried again 2 years later: https://willhbr.net/2025/10/13/the-6-2nd-stage-of-swift-on-l...

g947o2• 6 months ago

Sounds like a language not to waste my time on.

I should spend my time writing actual code and ship stuff, not debugging or finding holes in someone else's product.

afavour3• 6 months ago

Yes, in my experience the Apple bias exists in all the articles and how-tos you read in a way that can trip you up.

It’s been years now but I wanted to create a Set with weak memory in its keys. Everything I read said “oh just use NSHashTable” and I dutifully did (it’s in Foundation) and then when I tried to cross compile it didn’t exist outside of Apple platforms. It’s not as if the import made it clear I wouldn’t be able to use it, but I couldn’t.

sparky4pro• 6 months ago

This! Also, for new APIs Apple reduces (or does not provide) Objective-C documentation.

I really tried to love Swift, but in the end I ended up with 1 project using Swift/SwiftUI, and all the other apps I started to write, I rewrote in Zig or Rust, because the Swift compiler kept giving me vague error messages with no hint which Swift file was the culprit or/and which line/column the error was.

YMMV

isodev4• 6 months 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.

frizlab8• 6 months ago

Except I did and it was good. When did you last try?

isodev4• 6 months ago

It’s what I do, every day. You maybe in need of a broader horizon for comparison

drcongo• 6 months ago

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

deryilz• 6 months ago

The Swift Book is good for this:

https://docs.swift.org/swift-book/documentation/the-swift-pr...

Terretta• 6 months ago

After that, things like:

https://www.hackingwithswift.com/learn

https://www.hackingwithswift.com/quick-start/swiftui/

https://sosumi.ai/

rcarmo2• 6 months 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• 6 months ago

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

usamoi• 6 months 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.

slavapestov2• 6 months 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• 6 months ago

What is "clone-on-right"?

lucsky• 6 months ago

A misspelling of "copy-on-write".

jdalsgaard2• 6 months 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.

isodev4• 6 months 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.

behnamoh5• 6 months ago

Swift also supports the ownership model.

kibwen10• 6 months 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.

jdalsgaard2• 6 months 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• 6 months 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.

Really interesting results, not sure how well it is written but works. I was quite found of Rust syntax; it certainly is not as convoluted as C++ (in my opinion).

Then I read this article. Since I was already eye-balling Swift for some time, I decided to give it a try and port to it, using Rust implementation as reference, and this time, without much of A. I. assistance, if I could help it.

I'm using an qcow2 Debian trixie arm image in UTM as playground. I found out that there is no packaging for Debian at the time of this writing: https://github.com/swiftlang/swift/issues/60690. No problem! They have a script for installing: https://www.swift.org/install/linux/

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

rednafi2• 6 months 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.

myko2• 6 months 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.

rednafi2• 6 months 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.

jabwd3• 6 months 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.

robertjpayne• 6 months ago

We use server side Swift extensively since about 2016 for decent production load and it's easily one of the worst decisions I've ever made.

- C/C++ interop is great but if we wanted to use C/C++ libraries why use Swift at all? It's annoying to interop with them even if there is no FFI and still requires a lot of glue code for memory management etc…

- The stdlib (Foundation) is not identical on all platforms even today. This has been a major thorn as releases constantly have discrepancies and subtle bugs that are hard to diagnose and track down. Even Swift 6.1 broke non UTF-8 string encodings by just returning "nil" on Linux and took until Swift 6.2 to be fixed (nearly a year).

- The compile times are awful, with a large Swift codebase it takes us ~10-20 minutes to compile our backend Docker container and thus deployments to dev take that long and it's only going to keep getting longer as Apple seemingly has no interest in making the Swift toolchain much faster and Swift has a fatal flaw in it's design around bi-directional type inference that ensure it can never be compiled fast.

- Talent is impossible to find. Yes lots of people know Swift for iOS apps but nobody knows Swift for server code and a backend dev is a very different skillset than an app dev.

We chose it because it allowed us to share some domain code between our flagship iOS product and the server with a custom built sync engine but as our platform has grown it's just gotten harder and harder to justify keeping Swift on the server which is why we're actively migrating off it.

pjmlp7• 6 months ago

The target group for server-side software are iOS and macOS developers that also need a server component, thus like the JS folks, they get to use the same programming lanugage.

zozbot234• 6 months ago

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

HippoBaro• 6 months 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.

frizlab8• 6 months ago

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

zenlot• 6 months 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• 6 months ago

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

MattDamonSpace• 6 months ago

You can just not use them

hn-acct8• 6 months ago

First, op should mention which ones but they won't.

worik4• 6 months 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• 6 months 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

worik4• 6 months 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

frizlab8• 6 months ago

I’m sorry but reading your comment, you have not understood much about Swift (and GCD).

In particular “"DispatchQueus" (?IIRC?) are a thin wrap of fork, and do nothing but add complications”, in addition to having typo, is as wrong as it can get.

if you want to build systems on Apple, without investing a lot in setup, you are stuck with Xcode.

If you want to do in Swift the same type of dev you do in go/rust/whatever, Xcode is more than not mandatory, it is generally recommended to use something else, including in the Swift community. Also, you can build native apps in Swift using something else than Xcode (if it is possible to do that in rust for macOS, it is obviously possible with Swift).

We never got the profiler to produce anything intelligible after days of trying

You mean Instruments? That app is incredibly good, I fail to see how you failed to get anything out of it.

The very worst part of Swift were the thread control

Already talked about that one, but Swift has async/await now, also.

worik4• 6 months ago

Async/await is not a solution to poor thread models.

Async/await is cooperative multitasking and is no help at all for cpu bound problems.

For i/o intensive systems it makes non-blocking i/o look like blocking i/o, and people find that helpful.

I do real-time i/o so I need more control and Async/await is unhelpful.

It is a worthy adition to Swift I agree. But they sorely lack Rust's excellent design in this area

positron262• 6 months ago

Yeah. You can bind C in swift. You can expose C interfaces from Rust. Write non-iOS code in Rust, then bind. Now you have iOS support with common client code in Rust.

You can compile Rust to WASM. You can run Rust on the backend. It's gaining popularity on k8s for memory consumption. You can write music visualizers in Rust. You can pivot to killer drones or embedded in Rust. It has very few foot guns compared to C and all of the advantages of C.

The people who want Swift to succeed off of Apple hardware are basically waiting for someone else to do it. Rust users will just invade Apple from every side. It is very clear which platform is the better investment of anyone's time.

I can't believe I'm even wasting keystrokes thinking about this. I saw a bunch of upvotes and can only imagine this has to be wishful thinking from Swift users.

nixpulvis• 6 months 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.

isodev4• 6 months 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.

kibwen10• 6 months 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• 6 months ago

MoonBit lang is better "better Rust" than Swift.

heavyset_go3• 6 months ago

Are Core Foundation and Foundation Kit still macOS-only?

saagarjha17• 6 months ago

Foundation has a Linux implementation.

thomassmith654• 6 months 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.

ks20483• 6 months ago

I think you have to give some examples.

thomassmith654• 6 months 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!

kibwen10• 6 months 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-exp... ) and AFAICT their efforts to port Swift to Windows for its sake have been cancelled.

CharlesW2• 6 months ago

FWIW, Swift for Windows is a thing (https://www.swift.org/install/windows/), and there's a new Windows-specific workgroup: https://www.swift.org/blog/announcing-windows-workgroup/

ternaryoperator• 6 months 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.

csmantle• 6 months 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• 6 months 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_cheese5• 6 months 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.

pjmlp7• 6 months ago

For us grey beards, both are basically Object Pascal/Modula-2/Delphi for new generations.

politelemon• 6 months 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• 6 months 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.

g947o2• 6 months 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.

Validark2• 6 months 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• 6 months 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?

Validark2• 6 months ago

We're talking about fallthrough happening by default or not by default. You could call it a "map" construct or a "choose" statement for all I care.

Whether or not you have to write the "case" keyword 10 times is an aesthetic choice.

I don't think this has anything to do with program optimization. On all non-theoretical ISA's I'm aware of, you don't need a JUMP instruction to go to the next instruction. We're debating names.

I'm a Ziguana so my answer to the programming philosophy questions would be that we need a language where the complexity emerges in the code, not in the language itself, and we generally want a shared language that can be read and used by anyone, anywhere. If everyone has their own subset of the language (like C++) then it's not really just one language in practice. If every project contains its own domain specific language, it may be harder for others to read because they have to learn custom languages. That's not to say you should never roll your own domain specific language, or that you should never write a program that generates textual source code, but the vast, vast majority of use cases shouldn't require that.

And, yes, be opinionated. I'm fine with some syntactic sugar that makes common or difficult things have shortcuts to make them easier, but again, if I learned a language, I should generally be able to go read someone's code in that language.

What do you consider "advancing the field as a whole"?

dzonga• 6 months 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_cheese5• 6 months 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.

kibwen10• 6 months ago

Immediate mode GUIs like egui are imperative: https://www.egui.rs/

999900000999• 6 months 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• 6 months 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

nubg• 6 months ago

to do reference counting and “clone-on-right” in your code

Was this article vibe dictated?

morshu90014• 6 months 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.

saagarjha17• 6 months ago

Infuriating strings lib. Kinda believe the entire language was designed around emojis.

Unicode but yes

morshu90014• 6 months 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.

fooker• 6 months 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• 6 months ago

I think this title is doing more harm than good.

Both are great languages

ChrisArchitect• 6 months ago

(2023)

Some previous discussion:

2024 https://news.ycombinator.com/item?id=41464371

bla3• 6 months ago

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

k_g_b_• 6 months ago

In the long run https://github.com/google/crubit will very likely solve this for Rust even if it's a bit specific to Google's use cases right now as per readme.

dang• 6 months ago

Related. Others?

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

porcoda• 6 months 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• 6 months ago

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

smallstepforman• 6 months 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• 6 months 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?

saagarjha17• 6 months ago

Make it look like Rust mostly

jbverschoor2• 6 months 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

tonyedgecombe• 6 months 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• 6 months 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• 6 months 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).

codr72• 6 months 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• 6 months 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• 6 months 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• 6 months ago

You still lose the benefits of Affine Types in Rust though

Swift is a more convenient Rust (2023)

Related Stories