Nah.
https://youtube.com/clip/UgkxFZA4XXnXzHyNso0OQ28XU60U1-jdR13...
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.
What?! This is complete nonsense. Swift was introduced 11 (!) years ago and it was clear from day one that it was going to be the future. Every single year since the introduction there were clear messages and hints in documentation and WWDC that Swift is in and Objective-C will _eventually_ be out.
Little warning? Maybe if you kept your eyes closed the past 11 years.
And do not forget that today you can still write apps in Objective-C.
Objective-C remains a first-class iOS development language, and there's no sign of that changing for at least another decade.
> Swift is a high-level general-purpose, multi-paradigm, compiled programming language created by Chris Lattner in 2010 for Apple Inc. and maintained by the open-source community.
As the article repeats, it is not Apple specific.
[1] https://en.wikipedia.org/wiki/Swift_(programming_language)
I doubt Apple is in danger of dropping Swift, but if they did it would create a devastating vacuum in the Swift ecosystem.
And that’s not to say they don’t support objective-c still. It just hasn’t been actively developed with new features.
Go's development is tied to Google Inc. and is widely used at Google. Same with Microsoft's C# with .NET and Swift isn't very different to this as long as it is open source.
So this really is a moot point.
Additionally Google isn't selling Go as a product in the same way as Apple does Swift (and where Google does publish public Go APIs it also tends to use them in the same way as their users do, so the interests are more aligned)...
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.
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.
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.
Let me do this:
const x: String | Int
enum MyEnum {
case string(String)
case int(Int)
}
https://forums.swift.org/t/re-proposal-type-only-unions/7270...
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.
type Option<T> = T | undefined
function f<T>(value: T): Option<T> { ... }
let thing: string | undefined = undefined;
let result = f(thing);
The mistake here is in how Option is defined, but it's a footgun you need to be aware of.
So lots of optionals might well be the better path here.
enum Tree<T> { Lead(T), Branch(Vec<Tree<T>>), }
works just fine, no superfluous Box needed.
Hell, even if you’re not moving things around explicitly, don’t forget that vectors resize themselves. If you use Box, then these resizes will be less painful with large objects.
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
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.
- 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.
You can also sometimes avoid xcode, see https://github.com/xtool-org/xtool
although, at this point, just use expo!
The license is pretty much Apache 2.0
If you hate Xcode, this is definitely worth a look.
And when you say "you hear", you really mean "you", not "me". I hear it a lot.
What motivated your comment?
If there are developers who are that incurious, all I can say is I don't understand them.
No, not in the slightest. I would call this one the most dangerous and unfortunate fallacies that so many intelligent people have ever accepted and been cheated by. If it were true, you'd know everything important there is to know, and be a master of philosophy, and would have many answers to some basic questions which most people have been told have no good or concrete or verifiable answers.
Errors everywhere with horrible messages that leave you no idea whats wrong
My code was data race free, but the underlying OS primitive wasn’t, so my program crashed out about 10% of the time.
This isn’t really a criticism of swift as a language, but I haven’t had this sort of problem with the rust ecosystem.
I've thrown Claude and Gemini at the app to try to analyze the code, had them use vmmap and Instruments, asked them run all of the code in a loop to reproduce the leakage — and still it leaks, slowly, tens of megabytes per day.
I'm sure it's something simple starting me in the face. But the fact remains that Swift's sort-of-automatic-but-not-quite memory model still makes it much harder to reason about memory than Rust or even Go.
I wasn’t of the mind that AppKit/UIKit really needed replacing in the first place, though…
I’ll bet Claude was channeling some Reddit guru dripping with swagger born from knowing their understanding of coding is far more advanced than most big-shots in the field— especially impressive because they only wandered into /r/LearnProgramming for the first time several months prior.
And of course, Apple's UI frameworks != Swift the language itself.
If its a reference cycle, instruments will find it. If it is a leak, instruments will find it. However, you seem to be worried about an implementation detail on how you get memory from your CPU which the mach kernel handles for you, and is something you don't quite grasp.
please don't reply with "I asked stupid generator", seriously, what is the actual issue you have?
I’m not sure why you’re having so much trouble with SPM though, most people seem to get on well with it.
You don't need to add an annotation on `let foo = bar()` where bar is a function that returns `String` or whatever.
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.
Unless you’re doing Apple-specific development, you don’t need Xcode.
Their newer Dia browser which is meant to be cross-platform also uses Swift.
[1]: https://speakinginswift.substack.com/p/swift-tooling-windows...
[2]: "How we're building the Arc Browser Windows app with Swift" -- https://www.youtube.com/watch?v=Xa_fNuaSE_I
Skip allows to "Build truly native iPhone and Android apps with Skip" so technically skip runs swift on android which is outside of Apple-specific development.
They also recently got open source from their closed source model prior from what I can tell
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.
Hmm...
TypeScript: Microsoft
Rust: Mozilla
Go: Google
Java: Oracle
By your logic we should be programming in Common Lisp.
==========
Edit:
- Rust: Mozilla
+ Rust: Rust FoundationNope. Not anymore, several years maybe?
Python: The Python Software Foundation
Turns out two of the best languages don't need corporate overlords to steer their development.
Alot of its current popularity is becasue big companies developed the libraries that make up the foundation of Ai with it.
You left out an important part of the GP's comment.
>By your logic we should be programming in Common Lisp.
I wish. (Scheme is acceptable too)
I believe firmly that there should be a single true value, which we might reasonably name true, and a single false value, false, other values aren't booleans, so it's no more reasonable to ask whether an empty string is false, than to just forget to close the quote marks on a string. What we wrote isn't a correct program.
The others (Scheme, Clojure, etc.) are just Lispy syntax but lack the true "soul" of Lisp-style development.
The only real drawback to common lisp is the fact that the library ecosystem is practically non-existent.
For the reasons stated in the article.
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?
(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
> imports are all implicitly module-scoped, meaning that changing a single file means recomputing the types for all files in the module
import struct MyModule.MyStructXcode is optional, though its primacy has meant less adoption of Swift's first party LSP and VS Code extension.
For UI, why would anyone choose a language that has no automatic GC that can handle cycles?
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...
[1] https://doc.rust-lang.org/book/ch15-04-rc.html
[2] https://doc.rust-lang.org/book/ch15-05-interior-mutability.h...
Nope, you just use wrapper types (which you should anyway).
And there are no footguns to using Rc. More specifically, you cannot mistakenly use a Rc across threads, because the compiler will ensure that you aren’t doing this thanks to the Send marker trait.
How good is the developer experience on a non-Apple platform really? Linux is my primary platform and my perception is, that allmost all of the swift eco system is for Apple. Libraries, tools, documentation, IDEs, tutorials, etc. all assume, that you use an Apple.
Can someone tell me who does not use an Apple-device and uses swift?
I 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...
Rust wasn’t designed for any specific platform and you can tell. The ecosystem on Linux especially is fantastic.
I suspect that Mozilla being the primary developer and sponsor for many years actually meant that compatibility with all major platforms was prioritised; Mozilla obviously care about stuff working on Windows, and run lots of builds on Windows + I imagine a number of Firefox developers (if not drive) at least own a Windows machine for testing Windows-specific stuff!
I call out Windows because I think generally software people go for Mac > Linux > Windows (although Mac > Linux may be slowly changing due to liquid glass).
But the later years I spent every release looking at new fancy features I couldn't use because I don't use apple exclusively (and I don't use iOS at all, too closed for me). So almost no features that appealed to me while usually breaking some parts of the workflow I did use.
While I did hate the 'flat' redesign after Mavericks that on its own was not really a deal-breaker though. Just an annoyance.
I'm kinda surprised liquid glass is so bad people actually leave for it. Or is it more like the last drop?
No, but every release of MacOS has a noisy minority declaring it, or some features of it, as the end of Macs. Some people will genuinely hate it in the way that nothing can be universally loved, some people will abandon Macs over it, most people don't feel strongly about it at all.
Maybe there's some people out there that love it, even.
I can barely tell the difference between the Mac I use that's been upgraded, and the Mac that hasn't due to its age, because I'm not spending my time at the computers staring at the decor. The contents of the application windows is the same.
I don’t like it, but I think the claims of mass exodus are unlikely.
It feels a lot like the situation when Reddit started charging for their API: Everywhere you looked you could find claims that it was the end of Reddit, but in the end it was just a vocal minority. Reddit’s traffic patterns didn’t decline at all.
All in all it’s not perfect yet, but it’s getting better, with intent to continue in that direction.
I tried to write a websocket client: https://willhbr.net/2023/08/23/the-five-stages-of-swift-on-l... Then tried again 2 years later: https://willhbr.net/2025/10/13/the-6-2nd-stage-of-swift-on-l...
I should spend my time writing actual code and ship stuff, not debugging or finding holes in someone else's product.
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.
If Rust is too low level for you, you can write Go or Kotlin or even something new and fresh like Gleam.
https://docs.swift.org/swift-book/documentation/the-swift-pr...
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).
What does it mean to “use” subtyping vs typeclasses? Swift protocols are essentially typeclasses with associated types, just like Rust traits.
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.
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
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
Also, it works okay at best with VS Code, and you couldn’t pay me to use Xcode.
Kotlin tried doing similar things to gain adoption on the server side. But server-side programming is a crowded space, and people just don’t like writing distsys code in another JVM language. Swift’s story is a little better on that front.
If you want a quick-and-dirty language, Python and TypeScript do the job. For perf-sensitive, highly concurrent environments, Go is hard to compete against. A lot of ops tooling and infra code is written in Go. For systems programming and embedded code, Rust is a better choice.
So while it’s fun to think about what language X gives you in terms of syntax, in practice it’s rarely enough to pick a language like Swift for your next non-toy backend distsys work.
Also, Apple. Given their stance against free and open source software, I wouldn't be too thrilled to pick a language that works better in their walled garden.
I 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.
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.
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.
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
Well, the only difference 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
In particular “"DispatchQueus" (?IIRC?) are a thin wrap of fork, and do nothing but add complications”, in addition to having typo, is as wrong as it can get.
> if you want to build systems on Apple, without investing a lot in setup, you are stuck with Xcode.
If you want to do in Swift the same type of dev you do in go/rust/whatever, Xcode is more than not mandatory, it is generally recommended to use something else, including in the Swift community. Also, you can build native apps in Swift using something else than Xcode (if it is possible to do that in rust for macOS, it is obviously possible with Swift).
> We never got the profiler to produce anything intelligible after days of trying
You mean Instruments? That app is incredibly good, I fail to see how you failed to get anything out of it.
> The very worst part of Swift were the thread control
Already talked about that one, but Swift has async/await now, also.
Async/await is 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
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.
This example doesn't show me any meaningful difference, and Rust also let's you attach functionality to enums.
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.
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.
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.
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.
Are there people who see a "match" statement, smash both hands on the table, and shout, "WHAT THE ___ is a ------- MATCH STATEMENT?!!! THIS IS SO $%^&@*#%& CONFUSING!! I DON'T KNOW THAT WORD!! I ONLY KNOW SWITCH!!"
I think your comment was probably rhetorical, but does address/raise a fairly common issue in designing programming languages. My position on this is that it is less like "WHAT THE ___ is a ------- MATCH STATEMENT?!!! THIS IS SO $%^&@*#%& CONFUSING!! I DON'T KNOW THAT WORD!! I ONLY KNOW SWITCH!!" and instead more like the following (from the language designers POV):
Okay, we want a Case construct in the language, but programmers coming from or preferring imperative syntax and semantics may not like the Case concept. But, they often like Switch, or at least are familiar with it appearing in code, sooooooo: first, we will alter the syntax of the tradition Switch to allow a more comfortable transition to using this functional inspired construct; then second, we wholesale replace the semantics of that Switch with the semantics of a Case. This is underpinned by the assumption the the syntax change is small enough that devs won’t recoil from the new construct, then the larger divergence of semantics will hopefully not produce issues because it is just a small semantic change coated in an most familiar syntax.
Interestingly, the author of TFA seems to be operating under the assumption that the Case construct is an unqualified positive change and sneaking the corresponding semantics into that unfortunate imperative code is a wholly positive goal for the language design.
Without taking a position on the above positivity, I think the maneuvers language designers take while designing syntax and semantics (as exhibited in Swift’s Switch syntax for a Case Expression) is motivated by divergent, and often times strange, priorities and prior assumptions. So, from the 10,000’ view, does enshrining priorities and assumptions, and others like it, as a hard coded facet of the language the right path for languages generally? Should a language seek to be an overall more general framework for programming, leaving a vast majority of the syntax and higher-level semantics to be chosen and instantiated by devs where fit-for-purpose and pros/cons direct its inclusion? Or is the goal for opinionated languages, with or without accompanying sugar to help smooth over differences from other languages, the better path? Is there a ‘happy’ medium where:
1) design goals and forward thinking or experimental syntax/semantics get put in the language as an ‘it’s for your own good’ method for advancing the field as a whole and advancing/optimizing a single dev’s programs in particular;
2) the default position of a language should be as generalized as possible, but with abilities and options for users to specify what advanced, uncommon, or divergent syntax/semantics are utilized in a given program?
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
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.
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 {
> 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."
Was this article vibe dictated?
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.
The more you deviate from this, the more cracks there are.
Both are great languages
Some previous discussion:
Swift is a more convenient Rust - https://news.ycombinator.com/item?id=41464371 - Sept 2024 (308 comments)
bigyabai•6h ago