behnamohSwift is a more convenient Rust (2023)
https://nmn.sh/blog/2023-10-02-swift-is-the-more-convenient-rust
Even if it's the same (faster horse?) I would rather use Rust for the fact it's development is not tied to a big tech company which could abandon it if they liked. Yes it could continue on as a fork but it's development velocity would suffer.
If we're going to be concerned about any language languishing due to a lack of support... like, I don't think people are going to put "Apple dropping support" as anywhere near their shortlist. Rust has a higher risk of losing support.
Apple was the primary and only major sponsor of Objective-C, used it as the core foundation of their entire platform, and dropped it like a stone with little warning or ceremony. Yes, being tied so closely to Apple is an existential risk for Swift. One need only look at the quality and trajectory of MacOS to see that Apple isn't a software company, let alone a company that cares about developer experience (Xcode, anyone?). As far as modern Apple is concerned, the primary benefit of Swift is that it produces a tiny bit extra lock-in for iOS apps, by making cross-platform development more difficult.
Power users of Subway Surfers, maybe. Modern macOS is a tragedy: https://eclecticlight.co/2021/08/12/is-apple-keeping-its-pro...
First sentence of the wiki page [1]:
> Swift is a high-level general-purpose, multi-paradigm, compiled programming language created by Chris Lattner in 2010 for Apple Inc. and maintained by the open-source community.
As the article repeats, it is not Apple specific.
[1] https://en.wikipedia.org/wiki/Swift_(programming_language)
Swift being maintained by the open source community is an illusion. The community was very against function builders. Apple went ahead and did it anyway because they needed it for SwiftUI. The open source community just provides discussion, and Apple gets its way either way.
> The community was very against function builders.
Scanning the multiple review threads, that doesn't appear to be the case. According to the acceptance post, the community was overall positive about the feature but expressed concerns over the attribute naming, which was renamed in response.
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
I’m sorry but reading your comment, you have not understood much about Swift (and GCD).
In particular “"DispatchQueus" (?IIRC?) are a thin wrap of fork, and do nothing but add complications”, in addition to having typo, is as wrong as it can get.
> if you want to build systems on Apple, without investing a lot in setup, you are stuck with Xcode.
If you want to do in Swift the same type of dev you do in go/rust/whatever, Xcode is more than not mandatory, it is generally recommended to use something else, including in the Swift community. Also, you can build native apps in Swift using something else than Xcode (if it is possible to do that in rust for macOS, it is obviously possible with Swift).
> We never got the profiler to produce anything intelligible after days of trying
You mean Instruments? That app is incredibly good, I fail to see how you failed to get anything out of it.
> The very worst part of Swift were the thread control
Already talked about that one, but Swift has async/await now, also.
Async/await is not a solution to poor thread models.
Async/await is cooperative multitasking and is no help at all for cpu bound problems.
For i/o intensive systems it makes non-blocking i/o look like blocking i/o, and people find that helpful.
I do real-time i/o so I need more control and Async/await is unhelpful.
It is a worthy adition to Swift I agree. But they sorely lack Rust's excellent design in this area
Are Core Foundation and Foundation Kit still macOS-only?
I lived and breathed Swift for the first five or six years of its existence. When people compliment it, I assume they haven't used it long enough to hate it.
Swift is a mix of great features, miserable features, and... every other feature that someone on Evolution dreamt up (with the exception of those that would fix the miserable features)
Swift is unique among high-level languages in that the mental effort required to do many simple things rivals that of a low-level language.
It's been a while, but the one I remember with the most horror was dealing with Enums, and Enum payloads. Since Swift is statically-typed, many 'type union' situations end up becoming difficult problems. The question usually boils down to thinking about choosing one of (a) Enum with Payload (b) Generic (c) Type erasure. Nearly anything technically is do-able, but I wasted many hours (ie: repeatedly, not until I figured out the 'right way' for every situation) deliberating over how!
I didn't mean to suggest they do!
When I used Swift, I frequently was surprised to find some simple part of a program actually required me to sit and plan for several hours.
The exhausting amount of mental energy is the only part that reminds me of coding in Assembly.
I used Swift in versions 1-4, so idk if it's better now, but the syntax seemed fancy and complicated for no reason. So many different ways to do simple things like loops. Infuriating strings lib. Kinda believe the entire language was designed around emojis. And Xcode was a liability.
Rust is more complicated than C but has good reasons for everything it does. It's lower level too, which is fine. If I want high level, I look to JS and not Swift.
> Infuriating strings lib. Kinda believe the entire language was designed around emojis.
Unicode but yes
I mean emojis specifically. Python or JS strings are designed for unicode chars. Swift made it about grapheme clusters, which are possibly a valid edge case for like Arabic emphasis marks but not something they'd be motivated to center the entire strings behavior around if it weren't for emojis.
Weird part is the Swift way was still annoying even in cases where I wanted to manipulate strings with emojis very often. Had to build some custom pre-indexed string (just an array of 1-cluster Swift strings), cause find/replace/split/etc was too cumbersome and inefficient otherwise.
I think Swift made the right choice, though: it’s rare that you’d want to slice a grapheme. Usually you don’t have to build an index if you take a step back and design the algorithm around the indexing model.
That's the thing, there is no indexing model. Every string operation is an O(N) seek. But even if you don't care about performance, it's just cumbersome.
Looking at the SO questions for simple things like finding the position of a substring, it also lacked a lot of typical built ins until Swift 5. But that was like 5 years after GA.
There's definitely an indexing model, it's just that it's similar to that of a linked list. You can do all sorts of useful operations on a linked list. Not everything is O(n) in this world.
You can't do any linked list operations on this other than "get next" which is still kinda different
> 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?