Swift: Challenges and Opportunity for Language and Compiler Research [pdf]

Funny how people here mention source breaking change as the main issue with the language. I think it's because they haven't used swift on a large codebase. The main issue once you start to work on a big project are compiler crash ( https://github.com/practicalswift/swift-compiler-crashes ) and compilation time.

I really don't understand how a compiler can crash that much ( actually i've been coding in many client and server languages before and it's the first time i see a compiler crashing while i code). It makes me really nervous, because it shows that unit tests aren't good enough, and that the language is really in alpha stage, not more.

As for compilation time, you may think it's just a matter of optimisation. But the problem is that until those optimisation arrive, you can't rely too much on type inference (main source of slowdowns), which diminishes a lot the beauty of the code.

Now that was for client side. Server side probably adds its share of issues.

I used to be very optimistic for this language, but i'd say the swift team only has one more shot to make it really production grade, before the word spreads that this language is for now just a joke ( maybe apple using it for its own app would help allocate more resources).

I found that on macOS, refactoring even a tiny Xcode project to use Swift added 10 MB of libraries to the resulting bundle. The OS needs to start including a stable set of Swift frameworks by default so that Swift-based programs do not require users to download much fatter binaries.

I've recently started working on an iOS app in Swift 3 and it's a mostly pleasant experience, even though XCode doesn't have Vim keybinds.

I hope Swift can break out of the app-building niche, but from these slides it sounds like it will be a while until it can compete with Go and others in the high-concurrency space.

Kitura is mentioned in the slides since it's an IBM talk, but there's also http://vapor.codes/

The presentation claims that Swift offers "progressive disclosure of complexity", but I don't really buy the argument. "Progressive disclosure of complexity" works when you are learning a language and writing code, because you choose what language features you use. But it doesn't work when you read code written by someone else.

Sadly this will go nowhere until Apple invests significantly more resources into non-Apple platforms.

They dont support Ubuntu 16.10, there is no IDE support besides XCode, and no Windows support at all. And I havent heard even a mention of Android support.

Such half-assed Linux and non existent Windows support will leave it as a toy language on these platforms.

For a while I wanted to wait investing too much time in Swift, due to it's instability (breaking changes on every big release). But I noticed many potential clients in The Netherland already work on Swift projects. I've already lost some freelance work due to my limited (<1 year) Swift experience. Even though the language is still unstable, it's probably better to just bite the bullet and build up some Swift experience (perhaps by working on personal projects) if one is a freelancer.

Even though I haven't used it much, I like Swift: it's a big upgrade over Objective-C.

I do have some thoughts on the JIT/AOT part of the presentation though, which seems the most interesting to me. After many years where the two camps were largely separate, what we're seeing recently are more cases where JIT and AOT compilation get combined in new and interesting ways:

• Swift is AOT except when developers need fast response times, then it becomes JIT.

• Rust and Go are pure AOT always.

• Android went interpreted, JIT, AOT, back to JIT with AOT at night.

• Java 9 introduces mixed AOT/JIT mode, in which you can pre-compile Java modules to native code ahead of time, but that native code still self-profiles and reports behaviour data into the runtime which can then schedule a JIT-compiled replacement for any given method using the new profiling data. It also introduces ahead of time cross-module optimisation (a "static linker"-like thing called jlink).

Obviously these are quite different approaches, but they're working with similar(ish) languages on identical hardware. So which approach is going to win out, in the long run, if any?

It's fair to say that LLVM is the most advanced compiler toolchain for C-like languages. The JVM is I'd argue the most advanced runtime for more dynamic languages like Java, JavaScript, Python, Ruby etc. But it seems to me that LLVM struggles with some optimisations that should be quite basic and important - the way I read the presentation is that it won't do things like inline parts of the standard/collections library into calling code because they reside in different modules, and inter-procedural optimisation is only done at the level of the module. Otherwise compilation times become too problematic. A profile-directed JIT compiler has no such problems and will happily optimise across module boundaries.

As languages evolve, they seem to take on more dynamic features. This is especially true with the incorporation of functional programming styles where you're frequently passing functions to other functions and working with immutable data, which implies dynamic dispatch (when you can't inline through the call chain) and lots of copying of short-lived data structures (what a generational GC eats for breakfast).

Another major trend is multi-core processors, which we still aren't as good at exploiting as we should be. But more dynamic runtimes tend to find ways of using multiple cores even for single-threaded programs: if your program is inherently only able to use 1 or 2 cores at once, but you're on an 8 core machine and you aren't heat/power constrained, then using the other cores for concurrent GC or JIT compilers is basically free. If these techniques can speed up the execution of your program threads then it's a win, even though analysed holistically it might look like a loss. It is notable that multi-threading LLVM is apparently only a recent feature.

These trends lead me to believe that the JVM architects have the right general direction:

• Allow code to be AOT compiled but still optimise at runtime using multiple spare cores at once, to extract performance even in more modern, heavily OOP or FP-oriented code.

• Use a generational GC that is optimised for objects being mutated through copying and which doesn't cause large quantities of cache-coherency traffic due to the use of atomics all over the place.

• Support inter-procedural ahead of time optimisations like dead code elimination and statically resolved reflection with an optional link phase.

• Rely on pure JIT when developing to keep the edit-compile-run loop tight.

• Use a high level code transport format like bytecode that minimises the exposed ABI, thus allowing you to tweak and optimise the ABI used at runtime without breaking the world.

Apple has gone in this direction with the app store compiling bitcode to binaries for you, but LLVM bitcode was never really designed for that use case. Still, it seems like LLVM will be heading further in this direction in the future, or at least would like to, judging from the following comment:

I dream about the day when we can speed up the edit/compile/run cycle by using a JIT compiler to get the process running, before all the code is even compiled. In addition to speeding the development cycle, this sort of approach could provide much higher execution performance for debug builds, by using the time after the process starts up to continuously optimize the hot code.

Unfortunately, getting here requires a lot of work and has some interesting open questions when it comes to dependence tracking for changes (how you invalidate previously compiled code). That said, this would be a really phenomenal research area for someone to tackle.

These problems were already tackled years ago by the HotSpot project, which is capable of tracking the dependencies between compiled methods and invalidating compiled code when assumptions used in their compilation become invalidated. As you can also do manual memory management and bypass the GC in languages that target the JVM, I wonder if Swift would benefit more than Chris Lattner imagines from a port that targets it (at least, once the JVM supports value types, which it's getting experimental support for at the moment).

Great to hear they want to add Rust-like borrow checker as one of memory management options.

Is it not possible to get multi thread compiling with swift in Xcode today?

I've noticed that the compiler (both real-time analysis and actual compiling) gets sluggish and unreliable over time when a project grows. I think I've found the source of the problem and unfortunately for people in large code bases it does take a bit of rewriting to get it back into shape.

Since the language is very strictly typed yet allows for a loose syntax, the compiler needs to guess which type you are actually using. For example the type Any? always works but perhaps you are declaring it like a dictionary that always uses a string as a key? It doesn't know until it analyzes all keys and sees that you're indeed always using a string as an index. Put one Int in the end of a long list and it breaks.

Now something like this doesn't hurt:

    let indexOfTab = 4

Because the compiler sees you're trying to put an int in a constant.

But this is a bit more difficult:

    let tabDict = [ /* long list of declarations here */ ]
    let indexOfTab = tabDict.first(where: { key, value in value == "contacts" })?.key ?? 0

First it needs to know if that tabDict indeed would have only Ints or similar values as keys and only strings as values because they would now need to match what happens in the filter.

This makes the complexity of the code to analyze explode in a way that if your code consists of many of these things you all of the sudden find your computer go to a crawl.

The alternative however is a bit more ugly (I could use a bad word to describe it, like: "Java"):

   let tabDict: [Int: String] = [ /* long list of declarations here */ ]
   let tabWithContact: [Int: String] = tabDict.first(where: { key, value in value == "contacts" })
   let indexOfTab: Int = tabWithContact?.key ?? 0

(bear with me, this code is not checked in Xcode, just a hasty example)

Now step by step the compiler does not have to guess anymore, if the first line doesn't compile (because for example you've added a string as a key) it just won't compile. Same goes for the filter function, if you treat the types wrong inside the filter block. Also not too much to guess in the third line, it will never guess what type the key is let alone compile if you would declare indexOfTab as a String.

What I would like to see is:

* A tool that can actually show the points where your code is slowing down the compiler a lot

* A tool that proposes you to split the declarations up for faster execution just like you can automate much of the changes after upgrading to a new version of Swift

All I do now is guessing and adding more code to get performance back to acceptable levels.

So Swift 4 is coming in Late 2017. Will it break all previous code again?

Horrible slides! Is there a video recording from Chris' talk?

I thought about sitting down and learning swift, but they make breaking changed so often I really can't justify the time yet. I'm very curious what IBM comes up with, not sure yet why they're so interested in it other than LLVM.

Interesting news anyways.

Naysayers. The world will pour billions of dollars in Swift the coming years and they will keep complaining about it.

The most important advantage of Swift is that it allows you to code from the server to the desktop, mobile, watch, tv, IoT, in one language.

Swift will be everywhere and some are afraid of that, very afraid.