Very cool. App thinning seems to be the golden feature of Swift 5. I am dying for the day (if it ever comes) that UIKit and SpriteKit work natively with Linux and Windows frameworks, so that I can finally make Swift a daily driver.
ABI stability on Darwin is the big feature. That enables the Swift runtime + standard libraries to ship in the OS, which enables app thinning to strip them from apps going forward.
Yeah, UIKit and SpriteKit will never come to other platforms. They constitute part of iOS' and macOS' competitive advantage.
Swift's progress also has little to bear on that front as UIKit and SpriteKit are written in C, Objective-C, and C++; their use in Swift depends on Apple's Objective-C runtime which is not released as part of the non-macOS/iOS port of Swift for Linux.
Indeed. I don't think Apple would open source Foundation, App Kit, UI Kit, and a bunch of other things; that by itself precludes inclusion with Swift. Aside from that, a lot of those things rely on the full version of Core Foundation in C; I think the (open source, non-Swift) implementation of Core Foundation, CF Lite, is heavily reduced compared to what ships with Apple's OSs and would make an ineffective base for redundantly reimplementing those frameworks on other systems.
As someone who hasn't yet put in the time with swift, i get the sense that every version release of Swift includes a surprising amount of breaking changes. Are these edge cases that don't really effect anyone or does every Swift project you undertake basically cement itself into a swift version?
I had to make two changes to update from swift 4.2 to 5 and they were both trivial tweaks to fix warnings, rather than hard errors.
Each version up to 2 had a lot of language breaking changes, 3 had incredibly rough standard library changes, and everything since then has been about 5 minutes of work.
Personally, I find the intense focus on API/ABI stability and legacy support in the software world to be a major blockage on the road to great software. I'm ecstatically happy every time a new version of Swift makes big breaking changes, because it means that people care a lot about making Swift excellent, and as somebody who has used many different languages and frameworks, I can tell you that care is acutely felt in the experience of writing with Swift and Apple frameworks. I'm paradoxically kind of disheartened to see it reach stability. I wish this went on for a couple more versions.
"Unqualified references to Result in any of your code that imports the Foo module will resolve to Foo.Result"
That feels like it potentially can have weird unintended consequences
That's not Swift matrices. Swift hasn't defined a language-level numeric matrix type. That's a C library type imported into Swift.
You can alternatively import Python and use NumPy directly, as well as any other C library, or you can define numeric operations in Swift. (On the other hand, if you are using fixed-size 3x3 or 4x4 matrices, the simd_floatNxN types deliver vastly better performance than NumPy can. So it depends on what your goals are.)
the point of using swift is to be faster than Python. if your computations are using numpy and most of your time is spent in these computations, passing through the python interpreter every time, it's going to have performance similar Python
plus numpy is apparently 3x slower than pure simd optimized c++ with something like eigen. I was hoping to get something faster (than numpy, not eigen) with swift
> the point of using swift is to be faster than Python
There are plenty of other compelling reasons to prefer Swift over Python such as its type system or its easy, somewhat native, integration with existing Swift, Objective-C, and C frameworks available for macOS, iOS, watchOS, and tvOS.
Speed isn't the only driver, and I'm sure not it's not "the [only] point".
Migrated a substantial project today and other than updating a pod and fixing a few warnings it’s been smooth sailing. Probably my smoothest swift migration yet. Won’t be surprised if Swift 6 breaks almost nothing!
24 comments
[ 3.4 ms ] story [ 64.7 ms ] threadSo faster load times and smaller app bundles!
Swift's progress also has little to bear on that front as UIKit and SpriteKit are written in C, Objective-C, and C++; their use in Swift depends on Apple's Objective-C runtime which is not released as part of the non-macOS/iOS port of Swift for Linux.
Each version up to 2 had a lot of language breaking changes, 3 had incredibly rough standard library changes, and everything since then has been about 5 minutes of work.
You can alternatively import Python and use NumPy directly, as well as any other C library, or you can define numeric operations in Swift. (On the other hand, if you are using fixed-size 3x3 or 4x4 matrices, the simd_floatNxN types deliver vastly better performance than NumPy can. So it depends on what your goals are.)
There are plenty of other compelling reasons to prefer Swift over Python such as its type system or its easy, somewhat native, integration with existing Swift, Objective-C, and C frameworks available for macOS, iOS, watchOS, and tvOS.
Speed isn't the only driver, and I'm sure not it's not "the [only] point".