Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Swift 5: start your engines

lists.swift.org

Post reply on HN
Print view View original

91–100 of 186 posts

Re: Swift 5: start your engines

#91

Post by saagarjha »

ancarda wrote: post #86
nathcd wrote: post #35

Earlier quoted context omitted.

To expand on this, from the linked post: > First, ABI stability is the center focus of Swift 5 — and we will pivot much of our prioritization of efforts for Swift 5 around it. With Swift 4, ABI stability was a strong goal. In Swift 5, it is a requirement of the release. Whatever ABI we have at the end of Swift 5 is the ABI that we will have. ABI stability is an important inflection point for the maturity of the langu…

>In Swift 5, [ABI stability] is a requirement of the release. Once Swift 5 comes out, does that mean it's "safe" for people to write things in Swift? My company still has apps stuck on Swift 2.x because we simply can't give people the time to fix the hundreds of issues that happen when we try to upgrade the project to Swift 3. Unfortunately the migration tools just don't work and we end up having to either fix almost…

> Once Swift 5 comes out, does that mean it's "safe" for people to write things in Swift?

It means it's "safe" to ship binaries to people without providing the source and it should remain compatible forever™.

> It's a complete mess, and hearing year on year "this is the last time we'll break everything" is getting very tiring.

Swift 3->4 was much easier. Of course, if you're still stuck on Swift 2 this isn't going to help you much…

> Can you promise me if I push for the rewrite in Swift 5 it will be the last time we need to do that (for a reasonable amount of time, say 5 years? Or that changes will be far far more gradual and can incorporate it with our workflow?)

That's how it was supposed to be in Swift 4, and it should get better from there.

Re: Swift 5: start your engines

#92

Post by tambourine_man »

Since things at Tesla haven't worked out, I hope Lattner eventually returns to Apple.

Not that the Swift team is in a bad shape without him, it's just that it's nice to have an amazingly smart guy behind an open source language that many of us use (and that number that will probably only grow).

Re: Swift 5: start your engines

#93

Post by slavapestov »

kibwen wrote: post #77
xenadu02 wrote: post #19

Earlier quoted context omitted.

The Swift 4 compiler has a Swift 3.2 mode that is 99.9% source compatible with Swift 3.x. Further you can link 3.2 and 4.0 binaries together. This allows a phased upgrade approach that was not possible in earlier releases. Swift 5 is about having a stable binary interface so you can link against pre-compiled code going forward. In other words a Swift 6/7/8 binary can link against one compiled with Swift 5. The bar fo…

> Further you can link 3.2 and 4.0 binaries together. Do you have a source for this? This would imply ABI stability, which isn't being promised until Swift 5.

Swift "3.2" and 4.0 are really the same compiler, run with -swift-version 3 and -swift-version 4 flags, respectively.

Re: Swift 5: start your engines

#95

Post by _delirium »

k-mcgrady wrote: post #85
_delirium wrote: post #80

Earlier quoted context omitted.

It also doesn't help that these APIs are rapidly changing, in ways ranging from minor rearrangements that the XCode auto-upgrader can mostly handle, to real porting hassles. I've been working on a project that was started in early 2016, so it was originally in Swift 2, the then-current version. A ton of things changed for Swift 3, which came out 6 months later, in late 2016. And a bunch of things are changing again w…

AFAIK Swift 3 was supposed to be the last version to introduce breaking changes. Have they changed that policy? I know that the last Swift update I did was very manageable compared to in the past (where I'd easily lose a day or two).

This project's still on Swift 3, so I don't have first-hand experience upgrading to Swift 4. It looks like there are breaking changes though, albeit not nearly as many as 3 had.

The most notable one looks like in the String API [1]. There are a few other minor ones that most projects won't hit, like in the dictionary/set API [2]. A few of these are also slightly more breaking than it initially seems because they've added temporary compatibility workarounds marked as deprecated in Swift 4 to avoid breaking as much working Swift 3 code, but these will go away for Swift 5, so you do still have to port anyway (just not immediately).

[1] https://github.com/apple/swift-evolution/blob/master/proposa...

[2] https://github.com/apple/swift-evolution/blob/master/proposa...

Re: Swift 5: start your engines

#96

Post by lordnacho »

ssijak wrote: post #44

And just today I was contemplating writing my first native iOS and macOS app... I was looking at the options and decided to go native with Swift. I have never written Objective-C app and never used x-code for dev. But I have ~10 years of dev experience, mostly Java and Python on the backend and front end dev exp mostly with Angular. Some Android, and a little from because I like to experiment. So, my question is. How…

I did this a couple of years ago on a completely fresh MVP for a friend.

Worked fine, my background was in trading systems using C#, Python, and C++. I'd also done a lot of Android Java for another app MVP, so interesting to compare how iOS and Android do things.

I think most people who've done a few languages are not going to find a lot of problems with Swift. There's a lot of nice sugar in there to keep things neat.

Your main issue if you haven't done iOS before is learning iOS. It's a bit weird, you can tell some libs haven't been upgraded while others have. The old libs need a bridge header and have weird relics from Obj-C. Also the whole constraints layout system might take some getting used to, but I did manage to build some pretty complex components with it. It didn't seem to map well onto the Android layout engine, but I'm not that experienced with the layout engines.

Re: Swift 5: start your engines

#97

Post by cmoscoso »

bsaul wrote: post #49

About concurrency : does anyone know of a language that would let you tag portions of a codebase in some way, and declare something like "all those methods should execute in the same thread". Those declarations would then be checked by the compiler. That would be a first step toward agent like concurrency, but it would be general enough to apply to other types of concurrency models.

Something like Agents in Clojure?

Re: Swift 5: start your engines

#98

Post by zackmorris »

bsaul wrote: post #75
bogomipz wrote: post #64

Earlier quoted context omitted.

>"IOS sdk, on the other hand, has become a bit of a mess, due largely to the pace at which the field is moving ( although not as bad as android)." Could you elaborate on whats messy with these SDKs?

For ios : look at the number of various apis you can use to do widget positionning and animations : calayer, uiview spring n struts, constraints, physic based, and yet none compose well with each other. IOS also doesn't have any good tech for offline storage ( core data should be burried once and for all) and swift relies on compile-time codegen hack to provide easy struct serialization, because techs like nscoding r…

Also Apple uses a lot of patterns that lead to goto hell because of NeXT's foundations in the delegate pattern:

https://en.wikipedia.org/wiki/Delegation_pattern

So you start some sequence (like a new UIViewController) and interact with it via callback events instead of having a single (blocking) thread of execution that waits for the view controller call to return like a function. This makes it virtually impossible to deterministically model flow control. Note that since Android copied many metaphors from iOS, it also inherited these complexities in things like its Activity class.

I agree that Core Data probably needs to go away (at least its iCloud integration) and be replaced by Firebase or PouchDB etc.

KVO was a great missed opportunity because it's not clear who is watching a value. I think the pattern itself has merit from a functional programming perspective (after all this is how Excel works).

I generally avoid native mobile development now for these reasons among many, not to mention cross-platform issues. We likely need web metaphors running above native code, writing plugs where necessary (like Cordova or React Native). These are generally quite painful to use though, so I don't see many solutions materializing for at least several more years.

Re: Swift 5: start your engines

#99

Post by Jack4E4B »

bsaul wrote: post #70
bjt wrote: post #40

Earlier quoted context omitted.

The linked post talks about concurrency not being a focus until Swift 6 at the earliest. Personally, I don't want to make a commitment to server-side Swift until after that dust has settled.

I've recently started to investigate web frameworks for swift, and specially the concurrency part. So just to clarify something : current swift web frameworks ( and ios apps for that matter) rely on grand central dispatch, which is a decent library for spawning work on work queues, managed by the OS, and dispatched on OS threads. This type of model is fine and has worked quite well in the past. It is not event loop l…

How much work is expected from the developer point of view? I'd love to have an alternative to Go, but no concurrency for me kills Swift right of the gate for server stuff.

Re: Swift 5: start your engines

#100

Post by jakeva »

k-mcgrady wrote: post #83
bsaul wrote: post #75

Earlier quoted context omitted.

For ios : look at the number of various apis you can use to do widget positionning and animations : calayer, uiview spring n struts, constraints, physic based, and yet none compose well with each other. IOS also doesn't have any good tech for offline storage ( core data should be burried once and for all) and swift relies on compile-time codegen hack to provide easy struct serialization, because techs like nscoding r…

>> For ios : look at the number of various apis you can use to do widget positionning and animations : calayer, uiview spring n struts, constraints, physic based, and yet none compose well with each other. IOS also doesn't have any good tech for offline storage ( core data should be burried once and for all) I disagree with most of this. Laying out views was a mess for a while but auto layout is easy to get right onc…

As a ten year vet of Cocoa and Cocoa touch, I agree with your counterpoints. A lot of stuff is simply legacy.
Post reply on HN