Live data from Hacker News

IBM says Swift is ready for the enterprise

computerworld.com

211–220 of 235 posts

Re: IBM says Swift is ready for the enterprise

#211

When I recently interviewed at Apple I was told my position would primarily be coding in Java, but the team would be open to other languages as the project progressed and needs changed. I asked if they would consider Swift. Then was told that Swift wasn't production ready in their eyes. (I didn't get the job) I guess every team is different, but this attitude to dog fooding isn't great.

I interviewed at IBM for a position making Enterprise template apps for iPad working directly with Apple, and the main reason they said they passed on me was while I had a good amount of Objective-C experience, I had only dabbled with Swift on my spare time and had difficulty answering a couple of the questions they grilled me on in Swift. They specifically said I should have had more professional Swift experience wh…

IBM advertises jobs yet when qualified people show up, they are rejected. Either it's a way to look like they are reaching out to the public to satisfy the government so they can then go hire outside the US; or it's a way to let insiders get those positions after the applying public are rejected, all IMO. When I was in there, 99.999% of the people I met came in through acquisitions, not applying for a job and getting hired.

Re: IBM says Swift is ready for the enterprise

#212
post #196

Earlier quoted context omitted.

Using their weight, huh. Apple hit 10% market share with the Mac for the first time in 2012. I think it's something like 15% now.

Do you think laptops are the dominant computing device?

No. The context of the post is the one I replied to, which is often the case in a forum with threads, if that helps you out.

Re: IBM says Swift is ready for the enterprise

#213
post #186

Earlier quoted context omitted.

I would agree with this. The biggest issue with Swift right now is Xcode. Multiple times each day, syntax highlighting and code completion will break, even though the code is perfectly valid. The lack of refactor support after three Xcode releases and major versions of Swift is inexcusable. Using storyboards is super frustrating due to the load times. It seems no one at Apple tests with more than one storyboard in a…

Well I don't know any experienced developer that would put more than three populated scenes in a Storyboard. I would only add more if it was something like a navigation setup (navcontroller, menu, etc) where I would simply nest a lot of empty screens and link to the real screens with storyboard references. You can always use AppCode if you don't like Xcode.

AppCode has also become increasingly buggy over the last year or so, and is now almost as unusable as Xcode (albeit in different ways).

On my computer, recent versions of AppCode constantly use at least 100% CPU, even when it's in the background doing nothing. I got this a few times in earlier versions as well, but an "Invalidate caches and restart" usually fixed the problem. No such luck with recent versions. It will always use at least 100% when it's running.

I often get 30 seconds of beachball when I switch back to AppCode from some other app, despite having 16GB of RAM and not running any other remotely heavy app. This will happen even if I just leave AppCode for half a minute in order to check something on a web page. It's gotten so bad that I've developed the habit of checking web pages on my iPad instead of on my Mac, in order to avoid temporarily leaving AppCode.

There is a particularly infuriating bug that will sometimes cause AppCode to freeze when I type the opening parenthesis of a function invocation. When this happens, killing, restarting and typing again won't work, AppCode will freeze at the same spot. The only workaround I have found when this happens is to type my function invocation in some other editor and copy and paste to AppCode (often after waiting the usual 30 seconds for AppCode to stop beachballing).

It is not just me – all my coworkers suffer from the same problems. AppCode is by far the most annoying app I use on a daily basis. I hate it nearly – but not quite – as much as Xcode.

Re: IBM says Swift is ready for the enterprise

#214
post #200

Earlier quoted context omitted.

I said it can, not that it does it already. My Swift experience is constrained to the GNU/Linux version, so I don't know if XCode is already doing something in this direction. Sure one can have blessed library types that the compiler knows about, but then from language design point of view it creates a decision between those types and others written by developers, but with similar semantics.

Since you said it's easier than these other languages, I thought you were referring to how the languages work now. There's nothing wrong with special treatment for stuff in the standard library. C and C++ already do this with many things (e.g. many compilers understand calls like memcpy and will emit optimized code based on the standard library semantics) and Swift gives special treatment to built-in types like Optio…

Sure, I was more thinking about the language geek point of view.

Thanks for clarifying.

Re: IBM says Swift is ready for the enterprise

#216

Earlier quoted context omitted.

Swift memory management isn't nearly as expressive as C++ when it comes to references (i.e. unmanaged pointers). You can use in/out/inout parameters on functions and that's about it. I agree with the parent that Swift memory management is basically like Go or Java: everything is GC'd (reference counting being a form of GC).

You don't need in/out params to get references; in Swift, anything defined with "class" is always passed by reference.

Unmanaged references. Regular old class references aren't unmanaged (they adjust reference counts).

Re: IBM says Swift is ready for the enterprise

#217
post #214

Earlier quoted context omitted.

Since you said it's easier than these other languages, I thought you were referring to how the languages work now. There's nothing wrong with special treatment for stuff in the standard library. C and C++ already do this with many things (e.g. many compilers understand calls like memcpy and will emit optimized code based on the standard library semantics) and Swift gives special treatment to built-in types like Optio…

Sure, I was more thinking about the language geek point of view. Thanks for clarifying.

Understood. If you have any ideas for cool diagnostics or other guides, I'd be interested in hearing. I couldn't think of anything offhand, but that's probably just my lack of imagination. I would love to see some static analysis help for finding retain cycles and recommending how to break them, but I'm not sure if that's practical.

Re: IBM says Swift is ready for the enterprise

#218
post #186

Earlier quoted context omitted.

I would agree with this. The biggest issue with Swift right now is Xcode. Multiple times each day, syntax highlighting and code completion will break, even though the code is perfectly valid. The lack of refactor support after three Xcode releases and major versions of Swift is inexcusable. Using storyboards is super frustrating due to the load times. It seems no one at Apple tests with more than one storyboard in a…

Well I don't know any experienced developer that would put more than three populated scenes in a Storyboard. I would only add more if it was something like a navigation setup (navcontroller, menu, etc) where I would simply nest a lot of empty screens and link to the real screens with storyboard references. You can always use AppCode if you don't like Xcode.

This is my point - I use multiple storyboards to break up the app and use storyboard references where appropriate. But loading up individual storyboards, waiting for them to render (which takes far longer now with @IBDesignable), etc is such a drain in productivity.

Re: IBM says Swift is ready for the enterprise

#219

When I recently interviewed at Apple I was told my position would primarily be coding in Java, but the team would be open to other languages as the project progressed and needs changed. I asked if they would consider Swift. Then was told that Swift wasn't production ready in their eyes. (I didn't get the job) I guess every team is different, but this attitude to dog fooding isn't great.

I interviewed at IBM for a position making Enterprise template apps for iPad working directly with Apple, and the main reason they said they passed on me was while I had a good amount of Objective-C experience, I had only dabbled with Swift on my spare time and had difficulty answering a couple of the questions they grilled me on in Swift. They specifically said I should have had more professional Swift experience wh…

They pretty much said you should've been on the Apple's Swift language development team :). I mean, the shit is like only 2 years old.
Post reply on HN