
Is It Time for Swift? - astigsen
https://realm.io/news/ben-sandofsky-time-for-swift/
======
st3fan
Pretty happy the Firefox for iOS team made the decision to go fully Swift
about 14 months ago :-) Almost 60,000 lines later, no regrets. It is awesome.

~~~
shawn-butler
> git clone [https://github.com/mozilla/firefox-
> ios.git](https://github.com/mozilla/firefox-ios.git) FireFox-ios

> 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

~~~
deathanatos
The single .c file, I'm guessing is: [https://github.com/mozilla/firefox-
ios/blob/master/ThirdPart...](https://github.com/mozilla/firefox-
ios/blob/master/ThirdParty/sqlcipher/sqlite3.c)

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.

~~~
Someone
I haven't checked, but chances are it is the SQLite amalgamation or a tweaked
version of it.
[https://www.sqlite.org/amalgamation.html](https://www.sqlite.org/amalgamation.html):

 _" 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"_.

------
BuckRogers
I knew there was some churn in the Swift language but didn't think it was
going to continue. I'm not using Swift now but will likely hold off a bit
longer as a result. I did think they nailed the open source launch. Swift on
the server is an exciting prospect, more competition is always good. While I'm
not a Swift dev yet (I don't have a Mac thus mainly interested in the libre
crossplatform launch), I've been keeping my eye on it with Swift Weekly.

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

~~~
lpsz
Have been using Swift since late 2014 (having used ObjC for many years prior
to that).

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.

~~~
ktRolster
> the sheer gain in productivity due to brevity, type checking, cleaner
> closures, and various other language features, easily outweighs any costs.

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

------
dxhdr
Swift is a neat language but unfortunately doesn't fix the extremely verbose
and archaic-feeling NextStep libraries that make Objective-C a pain to read or
write:

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

Compare to any other language, say Python:

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

~~~
schrototo
I know exactly what the first one does, without knowledge of the underlying
API. I have no idea what the second one does. Does it replace occurrences of
the first parameter with the second one, or vice versa? I assume it returns a
copy of the string? What do I need to do to perform a case insensitive search?
etc.

~~~
greggman
Do you also pronounce every abbreviation? Do you say "International Business
Machines" instead of "IBM"? How about "Répondez s'il vous plaît" vs "RSVP".
"As soon as possible" or "ASAP". Ever use a contraction? How about a keyboard
shortcut?

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);
    

vs

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

which is best

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

~~~
comex
I'd do

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

which seems to go along well with the "sorted" and "appending" mentioned in
the new API design guidelines:

[https://swift.org/documentation/api-design-guidelines/#be-
gr...](https://swift.org/documentation/api-design-guidelines/#be-grammatical)

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;"])
    

This is better because most of the time you don't actually want characters
produced by earlier replacements to match later ones, and it can be faster for
large strings.

------
melling
How many iOS Objective C books have been written in the past 18 months? I
count at least 3 dozen Swift books:

[http://www.h4labs.com/dev/ios/books](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.

~~~
travisty
Sadly though, a lot of the books either are or will be out of date as more
updates come to Swift and break existing code.

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.

~~~
alblue
It's tough. I had a book out in 2014 and it's just been re-released as a
second edition in 2016 (Swift Essentials) with fixes for all the changes
introduced since the initial release. And you can't run the fix-its on a book
:-)

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.

------
yrezgui
I'm not an iOS developer but for the native modules that I developed for
Cordova or React Native, Swift is definitely a much better and cleaner
language to develop it.

------
tylerc230
One of the most compelling reasons to start using Swift is to make your
project more attractive to job applicants.

------
preordained
Something to think about from end user Joe, here: A quick search seemed to
indicate that Swift support (officially) began in iOS 7. Great, that's the
version I'm on. If anything coming down the pipe for Swift depends on a later
version, I'm not on board. I'm not going anywhere. A lot of users, myself
included, have been burned when a version upgrade runs like a dog on old
hardware...but unfortunately, I'm not going to spring for a new iPad every
year, much to the chagrin of Apple. It'd be interesting to see how App Store
success correlates with how many versions you can support.

~~~
thewarrior
Apple already thought of this and tbe Swift runtime + libraries are embedded
inside every app that uses Swift. No worries :).

~~~
preordained
No worries, indeed. Good to know!

------
peterkelly
It will be time for Swift when they stop making backwards-incompatible changes
to the syntax and I can be sure my code from today will still compile tomorrow
when I download the latest version of Xcode.

~~~
sssilver
The alternative is to either stifle improvements, or to bloat the language.
And we all know what that looks like _looks at C++_

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.

~~~
dikaiosune
You don't need breaking changes to get many benefits of a language like swift
- for example rust has had very little breakage since hitting 1.0.

~~~
wallacoloo
Thanks for bringing rust into the discussion - they handle language
standardization/evolution very effectively, in my opinion. "Experimental"
features _are_ added to the language, but they are all effectively #define-
gated for at least one release before being concretized (it's done more
pragmatically than a literal #define of course, given that rust doesn't have
any concept of #defines).

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.

------
natch
Why is he talking as though using objects is out, and using value types is the
only valid path with Swift?

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.

------
bsaul
I'm so desperate to find a good programming environment on the server side,
that i thought this talk was about using swift for the server side...

~~~
mike_hearn
Kotlin looks somewhat like Swift (or Swift like Kotlin, depending on your
perspective) and you get all the tools and libraries that have been built up
over the years for server side programming on the JVM.

~~~
bsaul
Deploying on the jvm isn't what i would call a sane environment, i'm looking
for something more go like (aka build copy, done).

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.

~~~
mike_hearn
"Not sane"? You can literally unzip a JVM and then run "java -jar myapp.jar",
how is that too complicated for modern day sysadmins?

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.

~~~
bsaul
I'll have a look at the javapackager tool, thanks. For now the only jvm web
framework i've used and found elegant enough is play, but since it's coded in
scala, i don't feel like using another non-java language on top ( i already
felt like using java for play was like using a second class citizen). Not that
it won't work, but it has all the chances of creating weird code patterns and
edge cases, and feel non natural at all.

------
peterashford
Reference counting seems really backwards and it hurts performance. Odd
feature to have in a modern language

------
edwinnathaniel
> Syntax Doesn’t Move the Needle; It’s All About Tradeoffs

That section is gold.

------
tomwilson
I still prefer objective-c most of the time. RIP :-(

------
billconan
here is one of my pain points of using swift.

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.

~~~
wolfsir
Int is a 64-bit data type and Int32 is 32-bits. The compiler refuses to infer
that you want to lose data. Converting the other way, the compiler refuses to
infer that you want to bloat your data.

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.

------
frik
Should one wait for Swift 3? The API/syntax changes are a concern. Code
breaking changes aren't that great. Also last time I checked Swift still
requires a 64bit iOS device.

~~~
jakobegger
Not sure where you got that 64bit thing from. I wrote an app using Swift and
it runs fine on my 32bit iPhone 5.

------
smegel
This is starting to sound a lot like Android developers still asking if they
should use Android Studio or Eclipse...

~~~
vinceyuan
It's totally different. Google officially stopped development and support for
ADT in Eclipse. But Apple is still supporting Objective-C and most Apple's
apps are written in Objective-C.

~~~
agildehaus
Apple is supporting Objective-C out of necessity (both for themselves and
others). It's still very clear where the future of iOS development lies, and
how few disadvantages there are.

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

------
R00TL3SS
lol. "use an 'objective' approach to adopting swift". nothing like a well
placed pun.

------
pmalynin
What bother me the most about Swift, is it essentially a C# clone, actually
worse, because C# has more features. It is a travesty that Apple chose to
design yet another shit language when there are so many other alternatives.
And now, like with Go, everybody is jumping on the band wagon because its
Apple.

Sigh.

~~~
millstone
Swift borrows some ideas from C#, along with Kotlin, ObjC, and others. It's
also radically different from C#:

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.

~~~
peterashford
That sounds really trivial to me. You've described less difference between
Swift and C# than exists between C# and Java and those latter languages are
commonly thought to bew very similar.

