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

121–130 of 186 posts

Re: Swift 5: start your engines

#121

Post by randyrand »

eridius wrote: post #14
ainar-g wrote: post #3

Maybe someone will explain this to me. Does Swift use this confusing "rapid release" versioning? Does Swift 4 break backwards compatibility with Swift 3? In my company people are looking for a language to rewrite some legacy Objective-C to. Swift is often discarded as "unstable" because of these major version bumps. Compare this to Go, which, seven or so years after the initial release is still 1.x and still doesn't…

Swift 3 was a major backwards-incompatible change. It came with an automatic migration tool, but the tool only kind of worked. Swift 4 is a much smaller change. There are backwards-incompatible standard library changes, but not on the scope of Swift 3. Again, it comes with an automatic migration tool. I haven't tried it myself, but I'm optimistic that it will work much better, both because they've had a year to fix w…

My biggest issue would be compiled libaries. I come from c++ so updating and recompiling all the libs would be a huge pain. How is it in Swift?

Re: Swift 5: start your engines

#122

Post by mahyarm »

developer2 wrote: post #81
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…

Regarding iOS and macOS kits, all of the documentation is in Objective-C. The libraries' Obj-C is imported and usable with Swift-only code, but the Swift documentation lazily links you to examples in the Obj-C docs. You have to perform trial-and-error by manually converting the Obj-C examples into the equivalent Swift (which often entails renamed classes, methods, types, etc.). If your projects typically do a lot of…

String operations are also really slow in swift. Python is the same speed or faster

Re: Swift 5: start your engines

#123

Post by shanev »

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…

You'll get up to speed in no time. Start with WWDC videos [1] in an area you're interested in. Then play around with some of Apple's sample code [2] and modify an app to your liking.

After you're a little more advanced, check out the resources at objc.io [3].

[1]: https://developer.apple.com/videos/

[2]: https://developer.apple.com/library/content/navigation/

[3]: https://www.objc.io

Re: Swift 5: start your engines

#124

Post by melloclello »

saagarjha wrote: post #115
bsaul wrote: post #104

Earlier quoted context omitted.

Ever tried to have 60fps on a tableview with constraint-based layout cells ? CALayer is definitely not legacy, it's often the only way to get smooth animation. Spring n struts is also sometimes the best way to get fast position for smooth scrolling. Ever had to deal with Core Data migration on an app that needs to evolve throughout the year ? Migration is a mess, and so is concurrency. My personal conclusion after ha…

> Ever tried to have 60fps on a tableview with constraint-based layout cells Yes. I've found AutoLayout to be acceptable in this case, provided you're not doing something awful.

We ran some casual benchmarks on this at work once, and it's important to note that the performance of AutoLayout dramatically improves based on the degree of nesting you employ.

If you have sixteen views on a cell and their locations all depend upon each other, it's going to take a long time to solve those constraints. But if you can break up the cell, say into four subviews with four elements inside them, it's likely to be faster (no guarantees, though)

Re: Swift 5: start your engines

#125

Post by eridius »

randyrand wrote: post #121
eridius wrote: post #14

Earlier quoted context omitted.

Swift 3 was a major backwards-incompatible change. It came with an automatic migration tool, but the tool only kind of worked. Swift 4 is a much smaller change. There are backwards-incompatible standard library changes, but not on the scope of Swift 3. Again, it comes with an automatic migration tool. I haven't tried it myself, but I'm optimistic that it will work much better, both because they've had a year to fix w…

My biggest issue would be compiled libaries. I come from c++ so updating and recompiling all the libs would be a huge pain. How is it in Swift?

The major goal of Swift 5 is ABI stability. Until then, libraries written in Swift do have to be recompiled with each new version of the compiler.

Re: Swift 5: start your engines

#126

Post by aplummer »

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…

Hey on the struct serialisation thing, try the new codable feature, it's so great. I can probably delete 20% of my code in swift 4!

Re: Swift 5: start your engines

#127

Post by Jack4E4B »

bsaul wrote: post #101
Jack4E4B wrote: post #99

Earlier quoted context omitted.

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.

At the moment, it's mostly the framework's job. You write your handler and call the libs for interacting with i/o. Posting a job ( aka function call) on a queue for async programming is also very very easy. There's nothing like coroutines or channels though. So you're back to mutex and OS thread constraints in terms of the number of spawnable threads.

Thanks for that explanation... so in short is not ready yet. Go's channels is what makes it seamless. So few choices for solid concurrency today.

Re: Swift 5: start your engines

#128

Post by dep_b »

mahyarm wrote: post #122
developer2 wrote: post #81

Earlier quoted context omitted.

Regarding iOS and macOS kits, all of the documentation is in Objective-C. The libraries' Obj-C is imported and usable with Swift-only code, but the Swift documentation lazily links you to examples in the Obj-C docs. You have to perform trial-and-error by manually converting the Obj-C examples into the equivalent Swift (which often entails renamed classes, methods, types, etc.). If your projects typically do a lot of…

String operations are also really slow in swift. Python is the same speed or faster

I only remember a very early review of string operation speeds that was pretty bad at times indeed. But that was about Swift 1 and the string implementation has been changed a few times. Do you have any recent source?

Re: Swift 5: start your engines

#129

Post by throwaway91111 »

melloclello wrote: post #124
saagarjha wrote: post #115

Earlier quoted context omitted.

> Ever tried to have 60fps on a tableview with constraint-based layout cells Yes. I've found AutoLayout to be acceptable in this case, provided you're not doing something awful.

We ran some casual benchmarks on this at work once, and it's important to note that the performance of AutoLayout dramatically improves based on the degree of nesting you employ. If you have sixteen views on a cell and their locations all depend upon each other, it's going to take a long time to solve those constraints. But if you can break up the cell, say into four subviews with four elements inside them, it's like…

Yup, it's easiest if you understand what the solver is doing and help point it towards solutions/find them trivially.

Unfortunately, i had to write my own constraint system and practice with it a lot to use AutoLayout with high performance where i was confident i was not introducing significant re-layout performance problems.

Re: Swift 5: start your engines

#130

Post by infinisil »

askvictor wrote: post #114
bsaul wrote: post #54

Earlier quoted context omitted.

Hardest part isn't the language. Swift is among the best languages you can get today. 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). Stanford courses are the best you can find online for free. https://youtu.be/HitSIzPM_6E

Languages are easy. It's always the frameworks (which are usually needed for any real world tasks) that are the killer.

> Languages are easy.

Not always true, my favorite example being Idris. (but then again, it's all relative to what you know already)

Post reply on HN