Live data from Hacker News

IBM says Swift is ready for the enterprise

computerworld.com

151–160 of 235 posts

Re: IBM says Swift is ready for the enterprise

#151

Earlier quoted context omitted.

Swift 3 was just released, like 2 weeks ago. Unless you interviewed very recently then I don't see the problem with that statement. If they had said swift 2 wasn't production ready, then I'd be concerned.

It's more they are aware that there is still no stable abi and they know of breaking changes coming down the pipeline internally already.

People always demand a stable ABI, but I've seen very few use case on enterprise software delivered to the cloud where this is even necessary.

Most people rebuild their software entirely prior to release, and deliver the entire package. Having a stable ABI doesn't do much to help this scenario.

Linux doesn't have a stable ABI, hasn't hurt its success much.

Re: IBM says Swift is ready for the enterprise

#152
post #62

Earlier quoted context omitted.

Swift, the language, is from Apple. IBM simply has built a bunch of tools for Swift and would like to sell consulting services around them.

Yes, but I thought the question you replied to was about IBM's implementation, and thus their github page for it.

What? They don't have their own implementation...

Re: IBM says Swift is ready for the enterprise

#153

Overall I like Swift and it's certainly a massive quality of life improvement for Mac/iOS devs. But I don't see as much upside for enterprise development. Server side tooling and deployment is still TBD, reference counting adds non-negligible cognitive overhead vs GC in an environment where the downsides of GC matter much less. They will have to build a complete ecosystem of server-side libraries from scratch. And un…

Meanwhile, developers are flocking to contribute to the most popular server-side Swift frameworks, like Perfect, Vapor and Kitura. I have followed the development closely, and for such a new language the enthusiasm around these projects are surprisingly big. I think the potential of server-side Swift is underestimated. Of course there's still several features lacking at this point, but that is to be expected of such a new language and will only improve. But yeah, large enterprise deployments are probably too early.

Re: IBM says Swift is ready for the enterprise

#154
post #138

Earlier quoted context omitted.

> Scala and Kotlin both have projects for AOT compilation to native code Not sure about Kotlin (stable version of the language was only recently released; more likely a stable JS target is higher on the priority list), but Scala Native isn't production ready, will likely be at least a year from now; same goes for Scala Meta, and Dotty's even further out, minimum 2 years away. Swift has a head start here, and a huge c…

You missed the part that AOT native compilers for JVM languages already exist today, but I accept that people don't want to pay for them.

Sure, was just pointing out that no such native ports exist for Scala or Kotlin that are anywhere near production ready.

In fact, it appears that a Kotlin Native project exists in the sense that a blog post exists that announced a native target is something they're looking into implementing down the road -- hardly a project ;-) Scala Native's been under heavy development for over a year now[1], and even then it's a long way off.

[1] https://github.com/scala-native/scala-native/graphs/contribu...

Re: IBM says Swift is ready for the enterprise

#155

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 with two different teams at Apple recently and they gave me the same answer. Most teams are using Objective-C and not even touching Swift. Which is pretty strange given they are shouting out of their lungs to other developers on adopting Swift.

Re: IBM says Swift is ready for the enterprise

#156

Earlier quoted context omitted.

The Dock? Why would they completely rewrite the Dock?

Maybe it was a mess anyway, so they went with Swift when rewriting it?

Apple may have wanted to prove out the language a distribution of core OS components in Swift.

Choosing the Dock, it's probably one of the smaller end-to-end apps that makes use of many OS features.

So they may have done it purely to prove our Swift for core apps. Now if only they'd have actually updated the UI...

Re: IBM says Swift is ready for the enterprise

#157
post #83

Earlier quoted context omitted.

I think the pitch is that despite static typing, it offers a lot of multi-paradigm high-level features while remaining elegant with fairly minimal syntax compared to other native static languages like Rust or C++. It automatically manages memory but without a stop-the-world garbage collector and goes a long way to opening a lot of flexible design options to any developer: it has great support for generic programming,…

> but without a stop-the-world garbage collector a RC is a stop-the-world garbage collector when the reference count reaches 0 in very complex data structures, which trigger a cascade of deletions. Also it has issues with sharing data between threads leading to cache coherency contention and locks.

That's not stop the world. Under RC, when a thread is destroying a complex data structure, other threads are free to keep doing useful work.

RC does otherwise have very bad interactions with threads of course.

edit: clarify

Re: IBM says Swift is ready for the enterprise

#158

Earlier quoted context omitted.

How does that make them any more difficult to use?

You have to manually optimize away unnecessary reference counting without help from the compiler.

That is true, but a totally different issue from breaking or avoiding retain cycles.

Re: IBM says Swift is ready for the enterprise

#159
post #20

So... what's the "elevator pitch" for Swift? It has anything interesting over Elixir or Go (well, go's feature is "lack of feature" but you know what I mean) or Scala or Kotlin? I know that iOS and MacOS desperately needed a modern language, and great for them that they have it now, but does the rest of the world need it?

For IBM, part of the lure probably is "the enemy of my enemy is my friend".

It's not running on a VM that Oracle or Microsoft control, and not a language Google controls.

Yes, it is Apple's language, but IBM apparently thinks it will become more popular than one they would control on their own, and picking Apple's language then is, for them, the least risky, as Apple isn't a company focusing on servers.

Re: IBM says Swift is ready for the enterprise

#160

Earlier quoted context omitted.

> this attitude to dog fooding isn't great. The Dock and a few other components of macOS Sierra are written in 100% Swift, according to this year's WWDC.

The Dock? Why would they completely rewrite the Dock?

Total speculations on my part:

It's probably a reasonably small codebase with well specified requirements, it's a standalone app already, and it's not likely to cause underlying OS performance or stability problems if it lost a little bit of performance migrating to Swift. I'm guessing it could be an experiment to see what parts of the OS are reasonably replaced with Swift?

People have also complained for several yearly releases now that OSX isn't improving as an operating system. It's also been around in various incarnations for like 18 or more years and has likely accumulated some deficiencies that needed addressing. Maybe things need some rewriting now to be positioned to become better in the future and a Swift migration is a good excuse to do both. Enough people are also complaining Apple isn't dogfooding Swift enough internally, so there you go, macOS is starting to dogfood it.

I'd also guess Apple probably has a reasonably hard time hiring for Objective-C positions to work with OS-level code (e.g. they've probably hired all of the existing, interested and qualified people willing to work in the Bay Area already), and the up and coming labor pool of people coming from iOS development is likely to be more interesting in or previously experienced with Swift. Modernizing your codebase where possible now seems like a reasonably way to hedge for the future hiring needs. Apple's been around long enough they likely have people retiring out of some critical positions.

Post reply on HN