
Swift's Evolution - carpeaqua
https://carpeaqua.com/2017/06/02/swifts-evolution/
======
AsyncAwait
I think the author misses the fact that Swift wasn't truly 'done' when it was
introduced, (and still isn't). Objective-C had some 30+ years to evolve, but
Swift can't have 3?

I get that if you're shipping Swift in production you want to refactor as
little as possible, but it is pretty hard to come up with the ideal design
straight out of the gate. Swift can stop evolving, but it will be THEN when it
loses the reason to exist. If Swift is just going to be ObjC with a nicer
syntax, (or the features that YOU personally find desirable), then why bother
with it at all? Swift is trying to get its design right and that takes time,
at the same time I wouldn't want to be stuck with a poorly designed language
for the next 30 years, so it's worth the current turbulence for me.

(Rust was the same way 2011-2015 to a MUCH bigger degree and it did in fact
eventually stabilize as promised.)

If it's that much of a problem, ObjC isn't going anywhere, it's your choice.

EDIT: Fixed a typo.

~~~
nicky0
Anyone shipping swift code one day one had to be pretty masochistic. I just
couldn't understand why people were doing it. It was obviously not ready for
production use, and still isn't.

But I'm happy that people are playing with it and the language is being
refined so that I can start using it in a few years.

~~~
karmelapple
Why isn't it currently ready for production use?

ABI stability is the only real issue I can see now.

~~~
mikeash
I'd say it's ready, but it's a bit iffy because of the tooling. The compiler
is way too easy to crash, the debugger is often worse than useless, and larger
projects can be _extremely_ slow to build.

You can put up with these, and I think it's worth the tradeoff, but you should
definitely consider them carefully before putting a lot of effort into build a
real-world Swift code base.

~~~
adamnemecek
> larger projects can be extremely slow to build

Ironically this forced me to start using Swift Package Manager more and to
split my projects into frameworks.

~~~
vlozko
Unfortunately, the rise of frameworks has led to another, often ignored
problem: app startup time. Carthage and CocoaPods, while great tools, became
enablers and I'm hoping static library support will be announced this WWDC.

~~~
adamnemecek
I dislike both Carthage and CocoaPods with passion. Fortunately SPM doesn't
link dynamically.

~~~
orbitur
Too bad there's no package manager for ObjC libraries.

~~~
adamnemecek
Embrace the future and never look back.

------
bsaul
I'm actually pretty happy swift moves the server side story forward, because
i'm convinced the "next big language" will have to run on mobile and server.
Actually, i think they don't go fast enough, especially regarding concurrency
( which on the server goes beyond just providing async await, as lattner said
they were aiming at something closer to the actor model).

I don't think the "maybe objc is still relevant for new project" trend we've
been seeing the last few months on HN is going anywhere. I'm currently in the
process of converting a large codebase from objc to swift, and there is
absolutely no doubt that the language is WAY better, and brings a lot of
safety enhancements as well.

The only big remaining pain point now is clearly in the tooling, but now that
they're stabilized the language a bit more, it's probably going to get better
fast.

~~~
ngrilly
> which on the server goes beyond just providing async await, as lattner said
> they were aiming at something closer to the actor model

I'd be interested in further information about this, if you can share some
link here.

~~~
Someone
[http://researcher.watson.ibm.com/researcher/files/us-
lmandel...](http://researcher.watson.ibm.com/researcher/files/us-
lmandel/lattner.pdf), page 52:

 _" Async/await are effectively proven at this point and would fit well with
the Swift type system and structure, we should probably just do it.

Erlang/Akka have proven actor models. Swift providing syntax yields a
declarative model which enables programmers to reason about what mutable state
goes with each task. Each actor is effectively a DispatchQueue + state it
manages + operations that act on it.

Actor approach also generalizes well to future. It could be a great way for
handling heterogenous compute (e.g. GPU tasks), distributed compute, etc since
each async “call” to an actor really is a message send (thus could be DMA or
IPC)."_

I don't think a video of that talk is available online.
[https://researcher.watson.ibm.com/researcher/view_group_subp...](https://researcher.watson.ibm.com/researcher/view_group_subpage.php?id=6940)
doesn't mention it.

------
jordansmithnz
The author mentions that Apple often nudge their idea of the future forward
each year at WWDC. I see no different with Swift: the introduction of
Playgrounds, teaching resources, finesse over small details, etc - to me
indicate Apple wants to make this a language that the next generation of
developers grow up learning and using.

Quite a good move on their part if it is successful. If kids start learning
Swift at school, they get exposed to Apple devices (not necessarily but this
is where the teaching resources are aiming), and they've got developers in
their arena from an early age.

Yeah, Swift needs ABI stability, but I also understand that they don't want to
screw it up by adding it too soon. Because the goal of Swift seems more long
term oriented, short term ABI stability isn't worth risking a 10 year goal
for.

~~~
Someone
_" Quite a good move on their part if it is successful."_

I haven't used it, nor do I work in education, but what I have read of it, it
at least is successful in the sense that those who use Apple's Swift training
material find it to have good quality.

For example, [http://www.speirs.org/blog/2017/6/1/a-year-of-teaching-
swift](http://www.speirs.org/blog/2017/6/1/a-year-of-teaching-swift):

 _" In times past the experience was that, if you were an able student in
Computing, you would get your programs working. If you were not an able
student, your experience would be almost insurmountable challenges to get
anything working. Working or not-working was the differentiator in the class.

In the Learn to Code curriculum, I found that everyone got something working.
The difference between the stronger students and the weaker students then was
more to do with evaluations of the complexity of their solution, the
understandability and style of their solutions or other factors like memory
and time efficiency.

I have never really had these kinds of conversations in classes at this level
before. It has been an incredibly satisfying year to get the opportunity to
debate which of three possible solutions is the 'best' for a given problem
and, further, what definition of 'best' we should accept."_

It also is good to see that Apple expands its offering.
[https://www.apple.com/newsroom/2017/06/swift-playgrounds-
exp...](https://www.apple.com/newsroom/2017/06/swift-playgrounds-expands-
coding-education-to-robots-drones-and-musical-instruments/):

 _" Apple is working with leading device makers to make it easy to connect to
Bluetooth-enabled robots within the Swift Playgrounds app, allowing kids to
program and control popular devices, including LEGO MINDSTORMS Education EV3,
the Sphero SPRK+, Parrot drones and more. The Swift Playgrounds 1.5 update
will be available as a free download on the App Store beginning Monday, June
5."_

------
coldcode
I use Swift daily in a mixed application of both languages. I worked with ObjC
since back in the NeXT days and I used to like the language but today nothing
could ever drive me back. Xcode on the other hand is nightmare I despise daily
but that's a different issue. The sooner ObjC goes away the better.

~~~
protomyth
I'm the exact opposite. I have been forcing myself to use Swift daily to
rewrite utilities and help with an iOS app. I hate their take on the
Smalltalk-style selector (the unnecessary parentheses is a pain) and other
parts of the language. I'll use it, but it is much like Transact-SQL or Perl
was for me (become an expert but not really like the language or programming
in it).

------
jcizzle
If you follow the Apple dev community, there is a group of folks that make
their living on books and speaking. That's fine, but they are using the
platform differently than someone shipping software. They are also often the
authors of some of the more ideological, less pragmatic proposals. This has a
large impact on the disconnect the author describes - which incurs a cost on
folks who ship software. I do wish the Swift team said no more often, but as
with any dependency, you're never gonna get 100% alignment.

~~~
mikeash
Maybe I'm in the wrong part of the Apple dev community, but I don't know of
anyone who makes a living on books and speaking. I know many who write books
and do a lot of speaking, but there isn't enough money in it for it to be
anything more than a side gig.

~~~
plorkyeran
Yeah, there's certainly some people who would _like_ to make a living on books
and speaking, but every single one of them that I know of has a job as an iOS
(or macOS) developer of some sort and no one's even in the range where they
can pretend that maybe one day they'll be able to quit their day job.

------
asveikau
Very distracted by the lack of the accusative case in the name of the site.
Unless he is instructing the water to seize, I think it should be carpe aquam.

------
dep_b
I didn't have a really rough time with the Big Rename but some subtle
differences bit me, simply the way how strings are constructed for example:

    
    
       var someId: Int!
    
       ...
    
       let urlString = "\(baseUrl)/\(route)/\(someId)"
    

Result in Swift 2:

    
    
       "http://ac.me/products/123"
    

result in Swift 3:

    
    
       "http://ac.me/products/Optional(123)"
    

Happy hunting! Some of this ended up in production :(

They've changed it to a warning in later versions of Xcode 8 at least. But
that was too late for me.

Apart from that it's a big step forward, less wordy than Objective-C yet it's
still "readable language" instead of a bunch of almost random generic English
words.

I'm not sure about async / await. Whenever I deal with it in .Net languages I
never find it that intuitive compared to blocks. But you know every programmer
suffers from Stockholm Syndrome at least a bit so it could just be my mind
warped to not only accepting but even glorifying the flaws in a language.

There are people out there that genuinely like JavaScript for instance!

~~~
eschaton
You should be using the methods on the URL struct to compose a URL, rather
than string interpolation. You wouldn't use string interpolation or
concatenation to compose an SQL query, would you?

~~~
rudedogg
What's the advantage of using URL versus strings?

The networking libraries I've worked with just use string interpolation:

[https://github.com/Moya/Moya/blob/master/docs/Targets.md](https://github.com/Moya/Moya/blob/master/docs/Targets.md)

[https://github.com/Alamofire/Alamofire#routing-
requests](https://github.com/Alamofire/Alamofire#routing-requests)

------
bernadus_edwin
Nothing wrong with swift but the build tool team. I can tolerate method name
convention that always changing. And also still not support async await.

Xcode build tool is the worst. Compiler time is the most hurt. Very slow.
Android, react and xamarin already support hot swap compile.

Migration tool is not working. I'm not sure this year xcode able to
refactoring rename method

------
sheeshkebab
And I thought 2017 is the year when I start a new app in swift... guess will
be sticking to objc and react native depending on what makes sense where.

~~~
leeter
as much as I like swift, wait for it to become stable. Don't subject yourself
to the pain yet. That said do take advantage of using literally all the things
that have been added to Objective-C for compatibility as they provide useful
information and diagnostics.

~~~
valuearb
It is stable. I would wager that more people are building professional apps in
Swift today than Objective C.

~~~
sheeshkebab
While renaming for loops? Even js is more stable than this...

------
brutus1213
This post hits it right on ... the renaming thing and the removal of
traditional for loops ... I'm just bewildered by it. When I saw it, my
reaction was ... WHY??? The incompatibilities between swift 2 and swift 3 made
me thankful I did not invest the language prior to 3. While I stepped into it
at this point, and think the language has a lot of potential (not changing the
damn language .. I mean having a large eco system of useful libraries around
it). Apple still has an opportunity if they don't screw it up further.

~~~
chrisoverzero
> the removal of traditional for loops […] When I saw it, my reaction was ...
> WHY???

For all of these reasons, at least: [https://github.com/apple/swift-
evolution/blob/master/proposa...](https://github.com/apple/swift-
evolution/blob/master/proposals/0007-remove-c-style-for-loops.md)

~~~
pscarey
Thanks for sharing that link. I found it quite an interesting read. (I much
prefer Swift to ObjC after a conversion of about 10k lines in an iOS app).

C style for loops come pretty early in most programming tutorials, but I
wonder how much non-C programming does actually use them nowadays (from the
Community Responses, it seems not much Swift courtesy of other options).
Usually, a C style for would be to loop over an array, and a safer way to do
that probably could have stopped countless vulnerabilities & bugs occurring
over the years.

~~~
masklinn
> C style for loops come pretty early in most programming tutorials

Meh. Many languages don't have c-style for loops in the first place. Neither
Python nor Ruby do for instance. I don't think Rust ever had them either[0].

[0]
[https://www.reddit.com/r/rust/comments/2957fg/can_i_request_...](https://www.reddit.com/r/rust/comments/2957fg/can_i_request_a_c_style_for_loop/)

~~~
andybak
I agree. Looping over a numeric sequence is simply a specific case of looping
over any collection. A language should reflect this. It feels so natural to
write:

    
    
        for thing in collection: process(thing)
    

and very easy to move from that to a functional style:

    
    
        map(collection, process)
    

or

    
    
        collection.map(process)
    

The number of times I also need a integer counter is fairly small.

~~~
mikeash
When you do need an integer counter, the best way to have it is to create a
new collection consisting of (index, element) pairs. Swift (and many other
languages) make this easy:

    
    
      for (index, element) in collection.enumerated()
    

There are some cases where the C style for loop is the most natural way to
express something. For example, looping over NULL-terminated array of pointers
is nicely expressed with one (Swift 2-ish pseudocode):

    
    
      for var cursor = ptr; cursor.pointee != nil; cursor += 1
    

But these situations are really rare, and when you do encounter them, it's not
a big deal to transform them into a while loop:

    
    
      var cursor = ptr
      while cursor.pointee != nil {
          defer { cursor += 1 }
          ...do stuff...
      }

~~~
masklinn
And you can trivially package the process into an iterator anyway if it's a
case you encounter often.

------
aaronbrethorst
> The biggest travesty was the "Great Renaming" which touched every line of
> Swift code I had and burned a week of my life on tedium

The sheer amount of churn in Swift between v1 and v3 was what has kept me on
the sidelines. It was only that Apple plainly stated last summer that they
were done radically changing the language that I was willing to get into Swift
at all.

------
eggy
Will Kotlin Native be able to compete with Swift on iOS? The syntax is very
similar and it would make for a nice cross platform PL. I was holding off on
Swift to see where it was going, but I'd like to add iOS to my dev targets.
Objective-C was too verbose for me years ago, but I've heard it has changed a
bunch.

~~~
virtualwhys
Kotlin Native doesn't exist beyond pre-alpha software at this point, so the
the question is a bit premature.

In 3-5 years Kotlin might be where Swift is now, but there's nothing
guaranteed, just coming up with a GC solution alone is a gigantic engineering
effort -- Kotlin, like Scala, Clojure, etc. all benefit from world class GCs,
just by being hosted on the JVM. With LLVM you essentially start from scratch,
same for porting Java libraries, there's a ton of work involved.

tl;dr; for now it's separate languages for iOS and Android unless you cut some
corners with React Native to avoid writing the same app twice.

~~~
LeoNatan25
Please nobody cut corners with React "Native" or other some such nonsense.

------
ebbv
The author says they lost a week of their life to the Swift 3 renaming but
wasn't there a utility that helped with that?

I agree that Swift has seemed to been infected with the disease so many open
source projects get; focusing on over polishing instead of big picture and
innovation but it's still my favorite new language.

Edit: I missed the author mentioning the utility sucked. Sorry!

~~~
protomyth
The automated tool couldn't even automate the conversion of the Apple examples
on their developer cleanly. Those examples were fundamental demonstrations
(e.g. table with views), so that indicates a pretty big problem if you are
trying for a complicated app. It also makes it difficult for people just
starting.

------
AlexeyBrin
The biggest problem Swift has is breaking changes from a version to another.
Took me about 10 days to manually convert a Swift 2.5 project to Swift 3 to
find out that Swift 4 will also introduce at least two breaking changes.

I'm all for progress and modern ideas in a programming language, just don't
break my old code!

~~~
timjver
They were pretty clear about this from the beginning... Sometimes you need to
break a few things here and there to make it a more pleasant language for the
decades to come.

~~~
oscargrouch
And for the skeptics, C++ evolution is a strong statement for why keeping old
cruft just for the sake of the early adopters maybe is not the right thing to
do.

I prefer the Swift way, and had to move 2ish to 3ish code myself and it didnt
suck that bad.

------
mpweiher
"Apple's path with Swift doesn't seem to solve the problems I have as a day-
to-day iOS developer. "

That's the key take-away for me.

Of course Swift has an easier time with some syntactic issues than
Objective-C, which is two languages crashed into each other. And yes,
Objective-C was way, way overdue for a better replacement. Heck, just dropping
the "C" part from the language syntax and reducing it to type annotations in a
nice typed Smalltalk (see Strongtalk, or TS) would have fit the bill.

It's not as if there aren't lots of problems (and your list will almost
certainly be different). For example, applications are no longer just code,
non-code resources are just as important, but support for them is at best
rudimentary. So with pluggable scheme handlers and polymorphic identifiers, we
could write

    
    
        checkBoxImage := img:checkbox.
    

And have the "img" scheme handler statically check resource availability
against a list automatically imported from Xcode's resources (pluggable, see
F# type providers). Of course, the internet also happened, so

    
    
        shoppingPage := http://amazon.com/
    

should also work, because why should obtaining resources outside your machine
have so much extra ceremony. Abstracting should of course also work:

    
    
        scheme:amazon := ref:http://amazon.com asScheme
        shoppingPage := amazon:/
    

And of course you can compose scheme handlers, so you add JSON or XML decoding
and then use the resulting scheme handlers as if the original data source

Then there is keeping UI and model in sync. There were bindings, but these
were hacky, somewhat unreliably, undebuggable etc. Much better to generalize
and integrate a constraint mechanism into the language:

    
    
        -<void>setupTemperatureConverter
        {
            ivar:f |= (9.0/5.0) * ivar:c + 32 .
            ivar:c |= (ivar:f - 32) * (5.0/9.0).
            ivar:k |= ivar:c + 273.
            ivar:c |= ivar:k - 273.
    
    
            ivar:c =|= ivar:celsiusTextField/intValue.
            ivar:f =|= ivar:fahrenheitTextField/intValue. 
            ivar:k =|= ivar:kelvinTextField/intValue. 
        }
    

That's actual code for a temperature converter app, setting up relationships
that get automatically maintained. And if you make constraint handling support
pluggable as you should, you also have a proper syntax for writing autolayout
constraints. And Makefiles.

Together with composable scheme handlers (see above), this gets rid of the
vast majority of your view controller code.

Then there's the nib vs code dance. Or storyboards. All semi-solutions to
problems that are largely (but not entirely) architectural in nature. All can
be aided tremendously by good linguistic support, putting to rest many of the
recurring problems we have with these technologies (or conversely with not
adopting them).

Swift does nothing for any of this.

------
RamenJunkie_
No mention of when it manifested human form and became a successful pop
singer.

