Hacker News Reader

Comment by cageface | Hacker News Reader

My initial enthusiasm for Swift faded pretty quickly when I tried to actually use it. The tooling is buggy and unstable. Code that calls Cocoa APIs is often no less verbose than ObjC. Every XCode release brings syntax-breaking changes. It feels like the language design was compromised by the requirement to bridge to Cocoa; all the strictness of the language is just a facade when you're manually casting every time you deal with a collection, for example. I guess I like the strict handling of nils in principle but in practice I've found this often means the user gets a crashed app instead of a more tolerable bug.

I'm getting out of iOS/OS X coding anyway for other reasons but even if I weren't I certainly wouldn't use Swift for production yet. Apple should not have pitched Swift as production-ready at WWDC. I think a lot of us would be less critical if it had been billed as the technology preview it was (and still is).

View on HN

I'm really loving Swift, but Xcode has gotten atrocious. I have a keyboard app with 8 different sub-keyboards, and 80% of the time, when I open my project, Xcode gets stuck in indexing. You can't build, you can't close Xcode, you can't do anything but force-quit and hope it doesn't happen next time. There are also frequent SourceKit crashes, random crashes to the desktop, and incredibly laggy typing and auto-completion. WTF?

"I guess I like the strict handling of nils in principle but in practice I've found this often means the user gets a crashed app instead of a more tolerable bug."

How are you using optionals in such a way that it crashes your app? I've found that using optional chaining and the "if let" block guards your code against accidental nilling even more. My rule of thumb so far is to never ever use the "!" operator except for initialization. I've found that whenever I get a crash — which is rare these days — it's usually because I forced an optional, or possibly used "as" instead of "as?".

"All the strictness of the language is just a facade when you're manually casting every time you deal with a collection, for example."

I dunno, I kind of like the explicitness of (cocoaArray[i] as? ABMyObject). It's no more work than you'd be doing with a generic NSArray anyway, and you get type checking for free. (And, of course, all your Swift native arrays and maps don't have to follow this pattern.)

Xcode 6.1.1 fixed most of the problems you mentioned in the first paragraph for me. Sourcekit crashes was the biggest annoyance, ughh.

I'm on latest and the indexing issue is just getting worse and worse for me.

Try removing (backing up) all folders from ~/Library/Developer/Xcode/iOS\ DeviceSupport. It helped for me.

I'm glad I'm not the only one who feels that way. I read through the book on night 1 and was stoked to Swiftify my life, but was disappointed nearly as fast when I realized how icky Cocoa(Touch) was to implement in Swift. It felt unnatural, and I've used languages with named parameters before, but forcing the two paradigms together seems wrong.

Initially I was ripping my hair out with Swift, but after couple months of using it full time, things are much smoother now. I still have doubts on it's production-readiness though.

And the strictness is pretty badass imo. Objective-c feels very imprecise and unsafe in many ways.

Apple used quite a bit of fanfare (they're just good at it), but I never construed Swift to be more than a beta, and I still don't think that it's more than that.

Reply on news.ycombinator.com