
Swift Evolution acceptances: The big three - acire
http://ericasadun.com/2016/03/03/swift-evolution-acceptances-the-big-three/
======
melling
Swift is changing fast. Chris Lattner has stated that Apple will have a good
migration solution to update current Swift code. If Apple does it right, Swift
will be a major cross platform language within a few years.

You can argue that Rust, Nim, or Go are better, for example, but the community
and support Apple give Swift give it a big advantage. Simply look at the
number of Swift books published in the first 18 months:

[http://www.h4labs.com/dev/ios/books](http://www.h4labs.com/dev/ios/books)

~~~
themartorana
If anything, I'd argue that we're in the middle of a fantastic time for
languages. I have at my disposal Go, Rust, Swift, and Nim, not to mention a
re-emergence of Erlang (and birth of Elixir), Clojure on the JVM (and what the
heck, Java)...

There's so much happening in languages now, it's a wonderful time to be a
developer! People will always argue about which is the best, why Go needs
generics, etc., but when you're a "right tool for the job" kind of developer,
your toolbox is looking pretty sweet right about now.

~~~
alblue
We are indeed in a great space right now.

At QConLondon next week, I'm hosting the "Modern Native Langauges" track which
will have presentations on Rust, Go, Pony and Swift:

[https://qconlondon.com/track/modern-native-
languages](https://qconlondon.com/track/modern-native-languages)

The presentations are being recorded and will be published at
[http://www.infoq.com/qcon-london-2016/](http://www.infoq.com/qcon-
london-2016/) over the next few months (you can see last year's conference
content at [http://www.infoq.com/qcon-london-2015/](http://www.infoq.com/qcon-
london-2015/) if you're interested).

It's certainly a great time to be a developer with an interest in languages!

------
ebbv
I recently did a game jam with my brother where we wrote a small OS X game in
a weekend in Swift using SpriteKit. It was quite fun, and Swift was really
pleasurable to write in.

These changes look great and will really improve the clarity of the standard
API, and are just good coding guidelines in general.

I write web applications all day, and no current web language is as fun to
write in as Swift.

------
cballard
Big things missing from Swift IMO:

\- Higher-kinded types

\- Strictly-typed "throw"

I'm not sure about dropping "Type" from protocols because it's pretty commonly
used to separate the protocol definition (which is extended to provide most of
the implementation) from the concrete base implementation, e.g. RAC's
SignalProducerType/SignalProducer.

~~~
zoul
Would you have an example for someone who doesn’t know anything about higher-
kinded types?

~~~
cballard
Both Optional and Array have flatMap, i.e.

    
    
        T?.flatMap(T -> R?) -> R?
        [T].flatMap(T -> [R]) -> [R]
    

However, you cannot write a protocol for "things that can be flatMapped",
because you cannot refer to a Self<T> specialized with a different type
(Self<R>). With HKTs, you can do that, which would let you write something
like this:

    
    
        protocol FlatMappable
        {
            typealias Value
            func flatMap<R>(Value -> Self<where Value == R>) -> Self<where Value == R>
        }
    

That's not useful on its own, but it means that you can now write functions
and extensions that reason about the general concept of _anything_
FlatMappable (this is most of the way to what is known as monads, FWIW).

------
kuiper83
Link was down for me here is the google cached version
[http://webcache.googleusercontent.com/search?q=cache:B3qA4jq...](http://webcache.googleusercontent.com/search?q=cache:B3qA4jq-
nwMJ:ericasadun.com/2016/03/03/swift-evolution-acceptances-the-big-
three/+&cd=1&hl=en&ct=clnk&gl=us&client=safari)

~~~
minionslave
What's the alternative? I actually thought databases were the cutting edge. Or
maybe I've been out of the loop.

~~~
nine_k
Databases are fine, but blogs change infrequently and mostly serve the same
static content. Caching the database-generated pages, or just serving static
files, if much more efficient, especially when a crowd comes.

~~~
melling
Can better blogs be built on top of Google's App Engine? I've been building on
top of it with Go but I don't use app engine's data store, and I'm not sure
that I want to. My little database is a pregenerated Go variable.

[http://www.h4labs.com/dev/ios/swift.html](http://www.h4labs.com/dev/ios/swift.html)

I'd like to add more features but I don't want to reinvent everything. Anyway,
Go and App Engine handle the load well and so far it has been free.

~~~
nine_k
You can run a blog on a cloud platform, set up auto-scaling, and withstand a
reddit / hn / slashdot crowd.

You will likely run out of the free tier and into significant spending during
the spike pretty soon.

If you ran a highly interactive page that required a lot of non-trivial
server-side processing, I'd understand.

But blogs serve the same static content to almost every request. I don't see
why burning a whole lot of CPU and IO on it by running python/php/ruby and
hitting a database many times is worth it. Serving a set of static files
automatically generated by a blog engine (like Jekyll) seems much more
reasonable to me.

Regarding comments: Disqus or something like that could help. Or you could
turn the comments off during a spike: seeing the content without comments is a
much better user experience than seeing a 500 Server Error page.

------
fleshweasel
I'm basically glad to see the Type suffix removed from the standard library
protocols. I'm hoping that they'll have a solution to make it so writing a
function over a generic sequence isn't such a mouthful.

I'm a little flummoxed by the new effort for first argument labels. Function
names often imply the meaning of their first arguments very effectively and
the new splits in function names seem arbitrary at times. Labeling subsequent
arguments is an excellent feature of Swift but first argument labels often
seem to complicate the syntax, especially labels like of: which don't always
imply much about the meaning of the argument by themselves.

~~~
mikeash
The function name often includes the name of the first argument just by virtue
of it being spelled out. Current Swift function names are usually two parts,
one part for the function itself, and one part that indicates the meaning of
the first argument. For example, consider removeAtIndex, substringWithRange,
or joinWithSeparator.

To me, it makes a lot more sense to just call these remove, substring, and
join, and label the first argument to express what's removed, substringed, or
joined with. This makes the first parameter consistent with subsequent
parameters, and makes the actual function name purely about the function's,
uh, function.

~~~
memco
In my brief experience with Swift the first argument convention struck me as a
little weird. I ended up adding labels anyhow as it made more sense to me.
Glad to see this being embraced.

------
bigdubs
Meta Commentary: that people are still serving blogs out of a database boggles
my mind (as I write this the blog is down because of database issues).

~~~
nostrademons
What's the alternative? The blog (according to the HTML source) is pretty
stock WordPress, which is database-backed.

~~~
K0nserv
Just a regular github.io page, or if you wanna be a bit more fancy
[https://hugotunius.se/2016/01/10/the-one-cent-
blog.html](https://hugotunius.se/2016/01/10/the-one-cent-blog.html).

~~~
nostrademons
There's a pretty massive difference in the amount of effort needed to publish
a post with either of those approaches vs. just typing it into the WYSIWYG
editor on WordPress. If your time is worth $60/hour then you're looking at
around ~$10/ _post_ in additional time spent. You also lose a bunch of
features: comments, trackbacks, RSS, etc.

~~~
K0nserv
Git commit and push takes a minute or two tops I fail to see how that is less
efficient than clicking save in a WYIWYG editor. The setup time between the
two options is probably very similar.

