Swift 5 Release Notes for Xcode 10.2 | Hacker News Reader

Swift 5 Release Notes for Xcode 10.2

developer.apple.com

68 pointsjaynagpaul24 comments

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.

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.

To be fair, libobjc is open-source: https://opensource.apple.com/source/objc4/objc4-750.1/

That is a very tiny part of Objective-C story.

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.

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!

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!

"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

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

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?

Swift has largely stopped making source-breaking changes.

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.

2 to 3 was brutal. Otherwise totally fine.

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.

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

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

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

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

no I meant for data science applications specifically, sorry

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

This looks promising: https://github.com/hollance/Matrix

Another way to do what?

matrix computations in swift as in numpy

Reply on news.ycombinator.com