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

Swift's Evolution

carpeaqua.com

Post reply on HN
Print view View original

91–100 of 105 posts

Re: Swift's Evolution

#91

Post by coldtea »

nicky0 wrote: post #76
coldtea wrote: post #58

Earlier quoted context omitted.

Great for small projects, people coding for fun, learners, and early adopters/neophiles who enjoy keeping up with all the changes. But substantial projects need solid, stable tools. Lots of projects more important and substantial than anything you and I have worked on have been shipped with Swift. So that argument doesn't really fly. Apps redone/adopting Swift include Twitter, Pandora, Groupon, Fitbit, etc. (Heck, ma…

That just shows that big companies can have poor judgment too.

Only if we assume from the start that it's "poor judgement".

That is, precisely what we are trying to access.

Re: Swift's Evolution

#92

Post by vlozko »

adamnemecek wrote: post #80
mikeash wrote: post #44

Earlier quoted context omitted.

I'd say it's ready, but it's a bit iffy because of the tooling. The compiler is way too easy to crash, the debugger is often worse than useless, and larger projects can be extremely slow to build. You can put up with these, and I think it's worth the tradeoff, but you should definitely consider them carefully before putting a lot of effort into build a real-world Swift code base.

> larger projects can be extremely slow to build Ironically this forced me to start using Swift Package Manager more and to split my projects into frameworks.

Unfortunately, the rise of frameworks has led to another, often ignored problem: app startup time. Carthage and CocoaPods, while great tools, became enablers and I'm hoping static library support will be announced this WWDC.

Re: Swift's Evolution

#93

Post by adamnemecek »

vlozko wrote: post #92
adamnemecek wrote: post #80

Earlier quoted context omitted.

> larger projects can be extremely slow to build Ironically this forced me to start using Swift Package Manager more and to split my projects into frameworks.

Unfortunately, the rise of frameworks has led to another, often ignored problem: app startup time. Carthage and CocoaPods, while great tools, became enablers and I'm hoping static library support will be announced this WWDC.

I dislike both Carthage and CocoaPods with passion. Fortunately SPM doesn't link dynamically.

Re: Swift's Evolution

#94

Post by rudedogg »

eschaton wrote: post #86
dep_b wrote: post #46

I didn't have a really rough time with the Big Rename but some subtle differences bit me, simply the way how strings are constructed for example: var someId: Int! ... let urlString = "\(baseUrl)/\(route)/\(someId)" Result in Swift 2: "http://ac.me/products/123" result in Swift 3: "http://ac.me/products/Optional(123)" Happy hunting! Some of this ended up in production :( They've changed it to a warning in later versio…

You should be using the methods on the URL struct to compose a URL, rather than string interpolation. You wouldn't use string interpolation or concatenation to compose an SQL query, would you?

What's the advantage of using URL versus strings?

The networking libraries I've worked with just use string interpolation:

https://github.com/Moya/Moya/blob/master/docs/Targets.md

https://github.com/Alamofire/Alamofire#routing-requests

Re: Swift's Evolution

#97

Post by clouddrover »

virtualwhys wrote: post #53
eggy wrote: post #10

Will Kotlin Native be able to compete with Swift on iOS? The syntax is very similar and it would make for a nice cross platform PL. I was holding off on Swift to see where it was going, but I'd like to add iOS to my dev targets. Objective-C was too verbose for me years ago, but I've heard it has changed a bunch.

Kotlin Native doesn't exist beyond pre-alpha software at this point, so the the question is a bit premature. In 3-5 years Kotlin might be where Swift is now, but there's nothing guaranteed, just coming up with a GC solution alone is a gigantic engineering effort -- Kotlin, like Scala, Clojure, etc. all benefit from world class GCs, just by being hosted on the JVM. With LLVM you essentially start from scratch, same fo…

Or things like Delphi are an option for cross platform mobile development. Object Pascal is quite nice these days:

https://www.embarcadero.com/products/delphi

Re: Swift's Evolution

#98

Post by nicky0 »

valuearb wrote: post #81
nicky0 wrote: post #77

Earlier quoted context omitted.

In what ways is objC difficult to maintain, and in what ways is Swift easier to maintain than objC? I look forward to the magical bug free future when I switch to Swift.

If you actually believe I offered you a magical bug free future, can you at least pay me for it? Swift is far more readable and a bit more concise than objective c, that makes it more maintainable. The bigger win is of course optionals, which, (if you embrace them properly), can mean your app will never have a dangling pointer or runtime crash from a nil pointer. I spent nearly 20 years writing object oriented C and…

Language features to eliminate sources of bugs I can get behind.

Re: Swift's Evolution

#99

Post by sheeshkebab »

valuearb wrote: post #71
leeter wrote: post #21

Earlier quoted context omitted.

as much as I like swift, wait for it to become stable. Don't subject yourself to the pain yet. That said do take advantage of using literally all the things that have been added to Objective-C for compatibility as they provide useful information and diagnostics.

It is stable. I would wager that more people are building professional apps in Swift today than Objective C.

While renaming for loops? Even js is more stable than this...

Re: Swift's Evolution

#100

Post by orbitur »

adamnemecek wrote: post #93
vlozko wrote: post #92

Earlier quoted context omitted.

Unfortunately, the rise of frameworks has led to another, often ignored problem: app startup time. Carthage and CocoaPods, while great tools, became enablers and I'm hoping static library support will be announced this WWDC.

I dislike both Carthage and CocoaPods with passion. Fortunately SPM doesn't link dynamically.

Too bad there's no package manager for ObjC libraries.
Post reply on HN