No garbage collection, so no GC performance hiccups. No explicit threading for easier concurrency.[1] Optionals for protection from null pointer exceptions. These are 3 of the biggest problems in server-side Java programming, I'd say. That's before we even get to the elegance of the syntax.
[1] https://developer.ibm.com/swift/2016/02/22/talking-about-swi...
If your models are naturally highly cyclic, dropping a GC can vary from painful to near impossible. I think a better solution for most server-side code (from both an ease of use and performance standpoint) is to use a hybrid GC/arena approach, centered around tasks.
If most of your work and memory churn centers around discrete and relatively short-lived requests, you can allocate all objects whose lifetimes are bounded by the duration of the transaction in a thread-local arena. You can't beat unsynchronized bump-pointer allocation, and you can simply throw the memory away at the end.
I've been really disappointed with the lack of innovation in the memory management space. Rust is the only recent language I've seen that did something more significant than choose between GC and reference-counting.
Another place where this can really hurt is "reactive" approaches, where cycles are very hard to avoid. Weak delegates (like what WinRT uses for events) can help here, but they raise a number of complications. The biggest is that they compose poorly: if you have an intermediary in your event chain, you need to make sure the subscription is the only place where a reference is being held.
a) Declaring weak pointers does take some more reasoning about your object graph. A silver lining is it makes the intention of your code more explicit which helps with maintenance.
b) Swift emphasizes value types which reduces the need for pointers vis-a-vis Java.
c) Most garbage collectors also add overhead when updating object references.
d) Swift is massively more memory efficient. Fast GC requires 3-4X the memory.
[1] https://www.quora.com/Why-doesnt-Apple-Swift-adopt-the-memor...
b. Very true, but these are the exact opposite of the cases that I'm talking about.
c. Two things:
First, memory has gotten incredibly cheap and dense for servers. Server GCs are generally more cache friendly than reference counting (due to both allocation strategies/compaction and the lack of need to touch reference counts), which is important because CPU performance gains are slowing down.
Second, the graph he shows (I've seen it before) is looking at older GCs, and more importantly GCs where memory usage outside of the working set was not optimized for. In a paged system, it is of little benefit to ensure memory outside your working set is released.
Obviously on mobile the situation is different, but there are also GCs that have far lower memory usage because they have been optimized for constrained scenarios. Android's new ART collector is sort of an example of this, but their efforts were massively undermined by the fact that they had to adapt to all of the existing Android library/app code which uses tons of object pooling. Manual object pooling with GCed objects creates all kinds of problems for GCs, particularly generational ones.
I agree with the decision to go with ARC for Swift from a lot of perspectives: Swift's target market is not usually dealing with complex interconnected models, using a GC would make ObjC interop difficult, etc. But it is far from obvious based on this information that it is beneficial to have a language stick with only a GC or only reference counting.
As a point of logic, optimizing to make 95% of cases a lot less "painful" would be worth a tradeoff of a bit more pain in the already difficult 5%. Thus if Swift fits that description it stands to reason that it could displace server-side Java.
[1] (Although one could argue those are exactly the scenarios where reasoning more carefully about your object graph is helpful.)
The biggest reason is that while some server side applications are very latency sensitive, many (most?) are not. For most websites, significant (i.e. collections of older generations) GC pauses are going to be relatively infrequent and having a few requests slow down just a bit for less than a second is not a huge problem. In these cases (which if they aren't the majority, they're still close) throughput is more important that latency, which is where a GC shines. And ease of programming/maintenance is likely to be more important than both.
As far as "helping you reason about your object graph", I don't see the argument about how forcing you to RC helps you do that at all. All of the extra reasoning is centered around something that would be otherwise irrelevant. Even in cases where you do something that is not amenable to GC collection (e.g. events/observers that keep objects alive which you didn't intend to), it seems of little benefit to have to constantly think about all of your other references at the same time.
I respectfully and strongly disagree. Outlier performance issues are a huge problem when scaling businesses.
Additionally "ease of programming/maintenance" is exactly an area where, overall, Swift may have some major advantages over Java. Without even further debating the cost-vs-benefit of declaring dense graph relationships, I believe you've conceded that this a small part of the overall picture.
For server-side GCs, a major collection is well within the bounds of incidental network latency, and happens far less frequently. Outlier performance is a huge problem, but from what I can tell outlier performance specifically due to GC pauses is an issue in far fewer cases (one that comes to mind is servers for certain financial services).
> Additionally "ease of programming/maintenance" is exactly an area where, overall, Swift may have some major advantages over Java.
That's true, but these advantages are uncorrelated to reference counting and they diminish if you choose to compare with a language that has aged better (C# comes to mind). If you're really concerned about high-performance, low-latency server programming and you are willing to switch to a less common language you'll be much better served by something like Erlang, which is specifically designed for that.
Erlang's memory model is fairly similar to what I have described here, but still runs into some issues that I feel could be solved by giving more control over where exactly things are allocated. It also resists any kind of mutable state; I agree that mutable state can complicate concurrency heavily, but having an option to use it sparingly would help (process dictionaries are too limited).
My point is basically that just like GCs aren't the solution to every problem, ARC isn't either. I think a language that allows for both will beat both Java and Swift handily when it comes to making both easy things easy and hard things possible.
As for local object pools, they are nice as long as their size is smaller than CPU cache. Without the control on the pull size it is very to easy to accumulate a lot of local garbage that it starts to hurt the performance.
Another advantage of the task-focused approach is that you can optionally collect the arena if it has gotten too big without halting the whole program (just the running task). In this case, you may have latency on one request but it need not effect latency on other requests.
> As for local object pools, they are nice as long as their size is smaller than CPU cache. Without the control on the pull size it is very to easy to accumulate a lot of local garbage that it starts to hurt the performance.
How is this different from the ARC case? If your working set fits in the cache, great, if it doesn't, then you'll have problems. If your allocation/release patterns are such that the allocator keeps handing you the same exact pieces of memory, then you're basically doing stack allocation. Not to mention that RC doesn't help the cache-unfriendliness that comes from heap fragmentation.
But your comment leads me to believe you haven't used Java in some time.
The GC has 100s of man years worth of research and optimization built in to it, Java provides a lot of higher level concurrency like executor services, fork/join, promises/futures, and with Quasar it has Go like goroutines called fibers. Optional is built in to the language as well (and to be honest find them sort of ho-hum, certainly a bizarre reason to stop using a language.)
Despite much optimization, GC still struggles with memory efficiency and predictable performance in a diversity of scenarios. You have to tune it.
I guess you could simplify my comment to two advantages: No GC, and elegantly baking constructs that make programming safer into the language as opposed to things you can opt-in to. While it may be possible to get these things with Java, if it's a lot simpler to get consistent performance, efficient memory use, protection from null pointers, and safe concurrency.. then there may be an opportunity for Swift.
(Nit: ARC is a form of GC)
(And yes you're right, by "GC" I mean mark-and-sweep GC.)
Last time I checked developing with swift requires xcode, which requires osx, which requires spending excess $1k on what should be commodity x86 hardware, to have it labeled "a Mac".
So a big fat no chance there.
Not that I think any enterprise that has tons of Java code will switch to anything ever, much less Swift. But "needs a Mac" is not the reason.
[1] http://www.oreilly.com/programming/free/swift-pocket-referen...
It says xcode 7 or later is required. How am I going to run that on Linux? How am I going to CI that on Linux?
Watch someone code and run Swift on Linux: https://developer.apple.com/videos/play/wwdc2016/415/
This is Apple and regard for other platforms in a nutshell. And it sorts of kills any interest I may have had in Swift as well.
Do I need to pay the apple-tax just to use their web-pages? That's basically a huge middle-finger to web standards. Absolutely useless crap, borderlining offensive.
Apple is doing some pro-grade trolling here. Not even Microsoft is doing stuff like this anymore.
Not sure who's trolling here...
edit: Oh wow, I didn't even notice but the video can stream in Edge! Doesn't do it in Chrome on OS X though XD
Anyway.. their web pages and developer resources are clearly disfunctional garbage, and their cross platform commitment almost non-existent.
I think it's still fair to say swift won't displace java anytime soon.
Anyway, there is no conspiracy to deny the WWDC videos to non-Safari users or to piss them off. It's just how the Apple is, they have protocol they were pushing for a long time (HLS), they are certainly not going to use competitor (MMS or DASH).
In Firefox on Android, check Request Desktop Site and you will get the download links. Or use Chrome for Android, it supports HLS streaming. Meanwhile, you can file bug to Firefox bugzilla and ask for HLS.
I don't think Swift would replace Java anytime soon either. From JVM languages Kotlin has better chances, from non-JVM languages probably Go. (Sorry Rust fans, a typical enterprise programmer is not going to learn how to appease the borrow checker).
However, Swift for Linux is not yet "productized" in the same way, as Swift for Darwin is. You can download a tarball for Ubuntu only, unpack it somewhere and call it a day. It will take a while before you can use 'yum install swift' from EPEL on your shiny Centos/RHEL workstation.
To answer your question: Very unlikely. Swift has a lot of irrelevant complexity from its Apple/Objective-C interop, poor reflection support, poor IDEs (Xcode) compared to established platforms such as Java 8 or alternatives such as Kotlin, Scala and so.
I'm not sure what you mean by "irrelevant complexity". Maybe you could cite some examples. Limited reflection/dynamism was an intentional design choice for greater safety, and there are complaints, but it's not without benefit. And it's a bit hasty to criticize lack of IDE support when it was just open sourced 7 months ago. That's like criticizing Scala for lack of IDE support.. in 2005.
[1] see https://developer.ibm.com/swift/2016/02/22/talking-about-swi...
Swift has ARC(https://en.wikipedia.org/wiki/Automatic_Reference_Counting) which is a GC strategy. And I don't think it can compete with the performance of the JVM's G1 (currently).
> I wonder whether Java will get displaced by Swift on the server at some point. Anyone want to place bets?
I'd bet on Scala(http://scala-lang.org/) which has far more benefits compared to Swift - OOP+FP, higher kinds, typeclasses, implicits, (hygienic) macros etc. dotty(https://github.com/lampepfl/dotty) will have union- and intersection types with other useful stuff. There is a JS backend(https://www.scala-js.org/) and there'll be an LLVM(https://github.com/scala-native/scala-native) backend too.
[1] https://news.ycombinator.com/item?id=11659863#up_11662144
[2] https://en.wikipedia.org/wiki/Reference_counting#Use_in_garb...
[3] https://www.cs.virginia.edu/~cs415/reading/bacon-garbage.pdf
Java is the new COBOL - and it'll be lurking in the guts of big enterprise systems for decades.