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

IBM says Swift is ready for the enterprise

computerworld.com

Post reply on HN
Print view View original

121–130 of 235 posts

Re: IBM says Swift is ready for the enterprise

#121

Post by aaronbrager »

mikeash wrote: post #111
themihai wrote: post #101

Earlier quoted context omitted.

Swift can't do realtime. It has automatic memory management. How do you replace C or C++ with Swift for that? What they mean is that Swift replaces Objective-C on user facing apps(on Apple devices) but I doubt you will see the critical parts of the OS (kernel, drivers, etc) written in Swift. It's almost like saying javascript will replace C/C++. I want a nice language like Swift (or Go) to replace C but there is none…

You can essentially write C in Swift by using UnsafePointer and such. If you avoid using reference types then you won't get any automatic memory management. I don't think it's quite ready to replace C as a kernel or driver language, but it's not that far off.

This is especially true in Swift 3, which has many improvements around this type of programming.

Re: IBM says Swift is ready for the enterprise

#122

Post by pjmlp »

themihai wrote: post #101
pjmlp wrote: post #89

Earlier quoted context omitted.

"Swift is intended as a replacement for C-based languages (C, C++, and Objective-C). " Taken from https://swift.org/about/ "Swift is a successor to both the C and Objective-C languages." Taken from https://developer.apple.com/swift/

Swift can't do realtime. It has automatic memory management. How do you replace C or C++ with Swift for that? What they mean is that Swift replaces Objective-C on user facing apps(on Apple devices) but I doubt you will see the critical parts of the OS (kernel, drivers, etc) written in Swift. It's almost like saying javascript will replace C/C++. I want a nice language like Swift (or Go) to replace C but there is none…

> Swift can't do realtime. It has automatic memory management. How do you replace C or C++ with Swift for that?

Of course it can, it is just a matter of OS vendors caring to push it down developers throats.

There are ways to manually manage memory if required to do so, but then you suffer the consequences of dealing with Unsafe*.

Re: IBM says Swift is ready for the enterprise

#123

Post by cableshaft »

valarauca1 wrote: post #44

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 when they rejected me. Of course all the companies I worked for were being more conservative and hadn't yet made the leap to Swift yet, so getting that professional experience was pretty much impossible. But I guess if anyone can afford to be picky, it's IBM on a project working directly with Apple.

So yeah, IBM is definitely gung-ho about Swift. Apple itself, possibly less so.

Re: IBM says Swift is ready for the enterprise

#125

Post by pjmlp »

mpweiher wrote: post #105
pjmlp wrote: post #92

Earlier quoted context omitted.

Can you predict what your C compiler with going to do with your code, taking into account UB and compiler specific implementation behaviors not specified by ANSI C?

More than with Swift. I routinely see 100x - 1000x and more performance difference between -O0 and -O in Swift. Considering that the optimiser doesn't give warnings or errors if it can't apply optimisations, that's out of bounds for me for a systems programming language. YMMV. The whole UB idiocy is a different matter, though related because it's perpetrated by roughly the same group of people, for similar nonsensica…

> More than with Swift. I routinely see 100x - 1000x and more performance difference between -O0 and -O in Swift. Considering that the optimiser doesn't give warnings or errors if it can't apply optimisations, that's out of bounds for me for a systems programming language. YMMV.

Improvements required for the toolchain in a young language, than Apple, IBM and others will certainly improve.

Re: IBM says Swift is ready for the enterprise

#126

Post by dcosson »

hellofunk wrote: post #34
nnq wrote: 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?

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,…

One other downside is XCode. No refactoring support, and lots of errors that give you little help. For instance, if you're trying to implement a protocol which is itself a few layers of nested protocols, XCode will just tell you it doesn't conform and not what method you're missing, so you have to dig through and check every signature of every method carefully.

The swift 2 to 3 migration was absolutely insane, I'd estimate Xcode did maybe 25% of the work automatically and left me with hundreds of different errors to convert manually (and often they were red herrings where the actual error was not where Xcode said it was). And you have to rebuild all dependency frameworks on swift 3 as well since the binaries are incompatible. If you use Swift make sure you have 2-3 whole developer days per year to devote to just migrating to the next version in a medium sized project.

Re: IBM says Swift is ready for the enterprise

#128

Post by iheartmemcache »

pjmlp wrote: post #85
aikah wrote: post #56

Earlier quoted context omitted.

Swift is statically typed (Elixir isn't) with a good type system (Go hasn't) and doesn't run in a VM (like Scala or Kotlin). I don't know how good its concurrency is and on how many platforms it is available though. It also looks like the language itself is still not that stable which is in my opinion a no go.

Scala and Kotlin both have projects for AOT compilation to native code. You can also get it today with any commercial JDK like Excelsior JET.

Yep, and as a result of this, the JDK ecosystem is healthy as ever. N.b to those who have only written web or phone apps for a living -- GC latency isn't 'bad' in most cases - unpredictable latency is what's bad. Having a deterministic upper-bound is what is important in the enterprise, on your aviation component regulating cabin pressure, on your SWIFT bank transfer.

Also, see the top comment here: https://news.ycombinator.com/item?id=11759762 for a JDK discussion against ref-counting, along with this [now incredibly old] paper https://www.cs.purdue.edu/homes/hosking/690M/urc-oopsla-2003...

(N.b. around the time that paper was published, I was in HFT. We used Azul C4 and it just fine to crush even with management taking their typical 30/3 fees. Though to be fair, this was when the easy pickin's were still there to be plucked. Don't underestimate how well good-ol' free Hotspot is now; we're not talking 1996 Jakarta days with Swing)

Re: IBM says Swift is ready for the enterprise

#129

Post by pjmlp »

mikeash wrote: post #103
spotman wrote: post #96

Earlier quoted context omitted.

Can you elaborate on the cognitive overhead vs a GC language like golang or java? (With regards to memory) To me sure there is things you think about but generally memory performance is less of a mental burden. Also, swift 4 is supposed to support a rust like memory model. Not sure if it's opt in or how it will work but my impression is that it's memory model is about to support some new use cases to make it appropri…

Speaking only for myself, avoiding or breaking retain cycles is a noticeable problem in Swift code that simply isn't there in languages with a proper garbage collector. Among newer iOS programmers, it's a big point of confusion to figure out when a callback closure should use [weak self] versus capturing self strongly, for example. I've seen a lot of people struggle to understand, completely fail, and end up dogmatic…

It is much easier than in either C++ or Rust.

Re: IBM says Swift is ready for the enterprise

#130

Post by virtualwhys »

pjmlp wrote: post #85
aikah wrote: post #56

Earlier quoted context omitted.

Swift is statically typed (Elixir isn't) with a good type system (Go hasn't) and doesn't run in a VM (like Scala or Kotlin). I don't know how good its concurrency is and on how many platforms it is available though. It also looks like the language itself is still not that stable which is in my opinion a no go.

Scala and Kotlin both have projects for AOT compilation to native code. You can also get it today with any commercial JDK like Excelsior JET.

> 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 captive audience in legions of iOS developers -- unlikely that Scala will be able to compete on the native front directly. More likely Scala.js + React Native may draw some from the JS developer pool that want to take advantage of static types and seamless client-server interop that can be had via Scala/Scala.js today.

Post reply on HN