I think 2016-2017 could well be the year(s) of Swift's ascension.

Even with the occasional churn (eg move to 2.0 or 2.1), the sheer gain in productivity due to brevity, type checking, cleaner closures, and various other language features, easily outweighs any costs. I find myself being able to do more with less code, and cleaner code. It's cognitively way easier to build bigger abstractions.

We do have a few legacy bits that makes no business reason to port at this point, but Swift-to-legacy interop works well, too.

I would say the biggest step that made things usable was introduction of incremental builds in 1.2.

Serious question: do you have a metric you are using to measure that, or is it just kind of a "gut feeling?"

http://www.h4labs.com/dev/ios/books

At some point soon if you want to find recent examples for iOS 8 and 9, they'll all be in Swift. iOS 10 will be announced in 4 months. Books, blogs, and perhaps all of Apple's examples, will be in Swift.

I've been working on and off with Swift since the beginning, it has a lot of great characteristics, but updates breaking code isn't something most developers have time to worry about.

One thing that has helped with the new openness of Swift's evolution is that I included several upcoming warnings, such as the demise of the ++ and -- operators and the 'standard' for loop.

There will have to be a phase change in the future when Swift moves from a "move fast and break things" to a "stable evolution". It has been suggested that this will begin with Swift 3 (when a stable ABI is introduced) but I suspect it will be Swift 4 or 5 when stability is really nailed down.

> cloc FireFox-ios/

1068 text files. 928 unique files. 303 files ignored.

C 1 files 10606 blank 51150 comment 94618 code

Swift 332 files 9660 blank 5808 comment 43474 code

EDIT: I give up trying to format the output correctly

It appears to be the source for sqlite3, all concatenated together, which is why it's absurdly long.

And it's third party, so its not really their code, but of course the tooling can't tell that.

"The standard makefiles for SQLite have a target for building an object we call the "amalgamation". The amalgamation is a single C code file, named "sqlite3.c", that contains all C code for the core SQLite library and the FTS3, FTS5, RTREE, DBSTAT, JSON1, and RBU extensions. This file contains about 184K lines of code (113K if you omit blank lines and comments) and is over 6.4 megabytes in size".

One of our devs starting adding Swift code to the project about a year and a half ago. After that proved successful, the rest of the dev team then started getting up to speed. For the last 8 months, all development has been done in Swift.

We don't arbitrarily rewrite existing source, but if we're making changes to an existing Objective-C file, we evaluate if it would be worthwhile to rewrite in Swift. Often the answer is yes.

From our perspective, Swift is absolutely ready for primetime. For a large codebase like ours, it takes some time before you see direct benefits, but if you keep with it, I'm sure you won't regret it.

I should mention the downsides: the migration to Swift 2 took time, but it wasn't awful. I'm sure we'll have similar issues moving to Swift 3. Also our compilation times are quite a bit slower than with purely Objective-C.

That they continue to support Objective-C has little to do with whether or not you should be using it. You should, clearly.

I personally am happy they're making backwards-incompatible changes, and I hope they always continue doing that. I'm happy to maintain my software in return of working with an elegant, cutting-edge, small, logical language.

This makes sense in my opinion because it gives an opportunity to evaluate proposed language changes under real-world use-cases before making it official, and people must explicitly opt into the possibility of their code not working with future releases, thus fully knowing and accepting the risks.

At the very early stages of the language, sure. But ten years down the line with significant assets in Swift? I think your opinion will change.

let bar = foo.stringByReplacingOccurrencesOfString(" ", withString: "", options: .LiteralSearch, range: nil)

Compare to any other language, say Python:

bar = foo.replace(" ", "")

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

There's a steeper learning curve sure. But brevity has value.

Is grep a stupid ass name that makes no sense to the layman? Of course! Can even moderately complicated regular expressions actually be read by anyone after the fact? Hell no. And yet it's a fantastic tool.

If there were a dynamic toggle between verbose and brief newbies would start with verbose. I bet most users would eventually switch to brief. Not all, but most.

I certainly agree it's potentially more readable at first. I'm not yet convinced, without actual data, that anyone, given a month or so experience with a given and common API wouldn't be more productive with shorter names up to a point. I would be good to get that data. Maybe I'd be better off with

    a = Math.numberFromAddtionOf2Numbers(c, d)
    e = Math.numberFromDivisionOf2Numbers(numerator: b, denominator, c);

    a = c + b;
    e = b / c;

    s = str.stringByReplacingOccurrencesOfString(" ", withString: "", options: .LiteralSearch, range: nil)
    s = str.replace(" ", "");
    s = str.r(" ", "");

    s = str.replacing(" ", with: " ")

https://swift.org/documentation/api-design-guidelines/#be-gr...

This is a bit more verbose if you need to chain a lot of replacements... but chances are you shouldn't be doing that in the first place! Instead there should be a version that takes a dictionary, like

    str.replacing(["<": "&lt;", "&": "&amp;"])

Can you really defend that as an identifier in any sane API? It's utterly abhorrent to my eyes, in the same way typical Microsoft bastardized Hungarian looks. Actually - it's worse.

So it's just as short, from a typing perspective. With a lot of free bonus clarity.

I lived through the bad years when Apple's dev tools were half-baked and made you almost pine for the first dot-com bubble when you were writing Java (but in IDEA IntelliJ, which made it almost worth it).

But today Xcode is state-of-the-art, at least in terms of autocomplete, and it makes a big difference.

Regexes have facilities for case insensitive replace, as in most languages.

Maybe I've been programming in Python too long, but str.replace is intuitive to me (unlike, say PHP's str_replace). I'm guessing you don't program in Python much, judging by your question of string copying.

Sigh.

I don't know anyone in PL who thinks Swift is a bad language. It's a nice, conservative, tasteful design that uplifts some proven functional features. What's not to like?

C# is, in essence, better Java. Much, much better Java. Swift is a different language, it implements some new ideas (much more advanced type inference) and forces the programmer to thinks in a different way (by trying to eliminate nullability).

Swift is not a perfect language (my biggest gripe is very awkward generics implementation), but it is a good language, and it's getting better. Saying that it's "a shit language currently on the spot just because Apple" isn't fair, I think.

1. Swift collections and strings are value types, but in C# they are reference types

2. Swift strings are mutable, C# strings are not

3. C# by default allows reference types to be nil, Swift does not

4. Swift performs overflow checking by default, C# does not

5. Swift is reference counted, C# is GCed

6. Swift's inouts are very different from C#'s ref. For example, Swift's inouts support properties

7. Swift's error handling is quite different from C#'s exceptions, both in syntax and implementation

8. Swift's enums act as algebraic data types, C# has nothing like this

9. Swift's switch statements are much more flexible than C#, because of where clauses

and more.

These are some radical departures! The differences between Swift and C# are much greater than the differences between C# and Java.

That section is gold.

I need to convert Int to In32 and CFloat to CGFloat a lot.

I wonder why there are so many basic types, and why can't they be simply converted to other types.

CGFloat, depending on the runtime, may either be a Float or a Double, so explicitly converting to and from it is required.

Rather than create a byzantine set of rules about whether it is "safe" to convert from one type to another, Swift wisely requires that all type conversions be explicit.

Plus kotlin doesn't seem to have a very stable web framework for now, and clojure isn't enough strongly typed for my taste.

All those things i'm looking for makes me really hope in swift on the server...

But thank you a lot anyway for making suggestions.

But if you want a single copyable deployment then look at the javapackager tool in Java 8. It will take a unified JAR (which any build tool can produce) and create a .deb/.rpm/.tar.gz with a bundled JRE inside such that you can install it and then run your app in the usual UNIX way (by name). You wouldn't even know it's Java under the hood.

Kotlin doesn't need any web frameworks because it's 100% interoperable with Java, so you'd just use any of those like Play Framework, Ninja framework, Spring Boot, etc.

Swift doesn't require 64-bit iOS, and never has as far as I recall.

Especially during a transition phase, which we are inescapably in right now, wouldn't it be pragmatic to continue using objects when needed, even if the eventual goal is to end up transitioning to protocol oriented programming?

In other words we don't need to conflate Swift with POP, which I think is what he's doing when he talks about the purported problems of NSNotificationCenter.