5 ms·

Swift 5 Release Notes for Xcode 10.2

68 points by jaynagpaul 8y ago

dlivingston 8y ago
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.
- favorited 8y ago
  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. So faster load times and smaller app bundles!
- zapzupnz 8y ago
  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.
  - saagarjha 8y ago
    To be fair, libobjc is open-source: https://opensource.apple.com/source/objc4/objc4-750.1/ https://opensource.apple.com/source/objc4/objc4-750.1/
    - pjmlp 8y ago
      That is a very tiny part of Objective-C story.
      - zapzupnz 8y ago
        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.
liquidise 8y ago
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?
- saagarjha 8y ago
  Swift has largely stopped making source-breaking changes.
- cschep 8y ago
  2 to 3 was brutal. Otherwise totally fine.
- plorkyeran 8y ago
  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.
- happytoexplain 8y ago
  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.
make3 8y ago
"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
- saagarjha 8y ago
  This was done so Swift’s Result doesn’t conflict with your library’s hand-rolled Result.
make3 8y ago
Swift matrix use looks pretty gross compared to Julia, R or Python (NumPy) https://developer.apple.com/documentation/accelerate/simd/working_with_matrices https://developer.apple.com/documentation/accelerate/simd/wo... Is there an other way?
- saagarjha 8y ago
  Another way to do what?
  - make3 8y ago
    matrix computations in swift as in numpy
- dlivingston 8y ago
  This looks promising: https://github.com/hollance/Matrix https://github.com/hollance/Matrix
- stephencanon 8y ago
  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.)
  - make3 8y ago
    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
    - make3 8y ago
      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
kitsunesoba 8y ago
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!
theredbox 8y ago
It is a shame this language does not get any momentum besides the Apple ecosystem.

68 points by jaynagpaul 8y ago

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.

favorited 8y ago
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. So faster load times and smaller app bundles!
zapzupnz 8y ago
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.
- saagarjha 8y ago
  To be fair, libobjc is open-source: https://opensource.apple.com/source/objc4/objc4-750.1/ https://opensource.apple.com/source/objc4/objc4-750.1/
  - pjmlp 8y ago
    That is a very tiny part of Objective-C story.
    - zapzupnz 8y ago
      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.

liquidise 8y ago

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?

saagarjha 8y ago
Swift has largely stopped making source-breaking changes.
cschep 8y ago
2 to 3 was brutal. Otherwise totally fine.
plorkyeran 8y ago
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.
happytoexplain 8y ago
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.

make3 8y ago

"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

saagarjha 8y ago
This was done so Swift’s Result doesn’t conflict with your library’s hand-rolled Result.

make3 8y ago

Swift matrix use looks pretty gross compared to Julia, R or Python (NumPy) https://developer.apple.com/documentation/accelerate/simd/working_with_matrices https://developer.apple.com/documentation/accelerate/simd/wo... Is there an other way?

saagarjha 8y ago
Another way to do what?
- make3 8y ago
  matrix computations in swift as in numpy
dlivingston 8y ago
This looks promising: https://github.com/hollance/Matrix https://github.com/hollance/Matrix
stephencanon 8y ago
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.)
- make3 8y ago
  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
  - make3 8y ago
    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

kitsunesoba 8y ago

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!

theredbox 8y ago

It is a shame this language does not get any momentum besides the Apple ecosystem.