Swift 3.0 Release Process

Outside of Google, using Go tends to be a decision made among a wider range of technical options whereas Swift is very often "not-ObjectiveC." To put it another way, Google created Go as an inhouse alternative for applications where Python, C++, or Java might have been the choice previously. A wide language range: even more considering the range of Java alternatives [Scala, Clojure] on the JVM.

A third factor I see with Go is the Clojure effect. The median Computer Science and Engineering knowledge in its community tends to be high relative to languages chosen based on platform limitations, institutional standards, or "this is the language I know".

I've left out Rust because I don't see it as likely to achieve the scale of adoption of Go or Swift...and saying that I should clarify that I think that platform binding, and a few billion platforms at that, will mean Swift is likely to instantiate more lines of code than Go. Clarifying further, I think Rust's adoption will be a matter of power law distribution not technical shortcomings.

It's probably mostly personal preference, but I prefer Swift's approach to things over Go or Rust. Go in particular does a lot of things that I personally find obnoxious (capitalization of method names indicating exporting instead of using a proper keyword I find particularly egregious, but I also find the := assignment operator annoying as well.)

Swift is the first language I've learned in a while that had way more "OH yeah that's awesome!" than "What?! Why did they do that?"

Well, I think it could have been more cleanly designed if it was able to abandon the burden of Objective-C interoperability. (But Apple can't do this, obviously.) The standard libraries could have also been much cleaner if it didn't rely on NextStep. Also, I don't personally like the dichotomy of value types and reference types, but YMMV.

I think Swift will be a Go killer.

This is such a critical thing with todays interconnected apps that i have no idea how they did not worry about it from the start. Having had the pleasure of dealing with threads, mutexes, dispatchers, execution-contexts and the like there is no way i'd pick up a language that hasn't evolved in that regard, especially on a server. Even Javascript has this figured out with stage-3 async/await.

WWDC is June 13-17, so they basically have to have something ready by then. Not so coincidentally, June 13 is "4-6 weeks later" from the May 12 date for making the release branch. Similarly, the late 2016 release for the final version of Swift 3.0 is probably actually mid September, since the version of Xcode with iOS 10 support has to ship before the next iPhone model.

Hurrah for marketing-driven release schedules.

I briefly ran the code sample you graciously provided me with a month ago through the profiler (https://gist.github.com/austinzheng/d6c674780a58cb63832c4df3...).

Long story short, it looks like the reflection machinery in the standard library is improperly being used to construct String instances. Doing so, while probably not sufficient to account for the entirety of the awful performance, is probably quite expensive. This looks like a bug and I'll try to dig deeper into it this week.

Swift also badly needs a native version of NSCharacterSet, even if only for programmer ergonomics.

The developer in charge of the standard library has mentioned that that team intends on redesigning the String API in the near future; this should provide an opportunity to reexamine the performance implications of the current implementations.

The first proposal for bringing Foundation APIs to this decade has already been accepted for Swift 3: https://github.com/apple/swift-evolution/blob/master/proposa...

https://lists.swift.org/pipermail/swift-evolution/Week-of-Mo...

It's not clear what the schedule would be but I suspect a number of the constraints changes will be in Swift 3.

The wildcard is probably the decision to go with reference counting over a tracing GC. We'll see how that works out. There are good arguments on either side.

Also if you're using Scala, there's a huge ecosystem of libraries and frameworks that just doesn't exist in Swift. If you want native compilation, just wait for http://www.scala-native.org/

Unless you are trying to build some really high performance shit, what really matters is developer productivity, which is abysmal for server-side Swift right now. Getting better every day though.

Source: built and deployed a service in Swift

Depends how you write the code :-)

http://benchmarksgame.alioth.debian.org/u64q/compare.php?lan...

For instance, now I have this code

    mutating func next() -> Element? {
        //...
        pos += 1
        return data[pos-1]
    }

    mutating func next() -> Element? {
        //...
        let e = data[pos]
        pos += 1
        return e
    }

    mutating func next() -> Element? {
        //...
        return data[pos++]
    }

for (index, element) in list.enumerate() { print("Item \(index): \(element)") }

Functional decoration trivially provides that. Just zip a counter with the backing iterable, and modern languages generally provide that OOTB as a variant of `enumerate()` e.g.

    for i, item in it.enumerate():
        # stuff

Meh. It's generally present in B derivatives (via C) and that's pretty much it. Most languages do just fine without it.

Disappointed, only for Windows 10.