Swift Evolution acceptances: The big three

http://ericasadun.com/2016/03/03/swift-evolution-acceptances-the-big-three/

by acire • 10 years ago

82 36 10 years ago

melling3• 10 years ago

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

mrdrozdov• 10 years ago

Wouldn't code released be a better measuring stick?

melling3• 10 years ago

There are a lot of a Swift GitHub projects.

http://www.h4labs.com/dev/ios/swift.html?q=github.com&age=10...

clouddrover4• 10 years ago

RedMonk publishes a language index which charts a language's GitHub and Stack Overflow ranking. Swift has risen quickly in the rankings: https://redmonk.com/sogrady/2016/02/19/language-rankings-1-1...

themartorana• 10 years ago

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.

pjmlp3• 10 years ago

Sadly many of us don't get to chose what languages are used at work.

alblue2• 10 years ago

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

The presentations are being recorded and will be published at 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/ if you're interested).

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

pjmlp3• 10 years ago

For that to happen, they need to have the compiler target more than just OS X, iOS and GNU/Linux.

clouddrover4• 10 years ago

There are some porting efforts underway in the early stages of development.

SwiftAndroid: https://github.com/SwiftAndroid

Swift for Cygwin: https://github.com/tinysun212/swift-cygwin-bin

alblue2• 10 years ago

You have my Swift Essentials book listed (one of the first, published in 2014) but the second edition came out covering Swift 2 last month:

https://www.packtpub.com/application-development/swift-essen...

There's a discount available until 20th March:

50% on eBook: SSEE50 30% on Print: SSEE30

ebbv• 10 years ago

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.

kuiper83• 10 years ago

Link was down for me here is the google cached version http://webcache.googleusercontent.com/search?q=cache:B3qA4jq...

minionslave• 10 years ago

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

bobbles• 10 years ago

I think you meant to reply to bigdubs

nine_k2• 10 years ago

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.

cballard2• 10 years ago

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.

whateveracct• 10 years ago

Swift protocols are begging for HKTs.

zoul• 10 years ago

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

cballard2• 10 years ago

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

fleshweasel• 10 years ago

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• 10 years ago

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• 10 years ago

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.

bigdubs2• 10 years ago

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

nostrademons2• 10 years ago

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

AlexeyBrin• 10 years ago

Use a cache plugin or migrate to a static site (works really well for blogs).

K0nserv2• 10 years ago

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.

BjoernKW• 10 years ago

Why wouldn't you? Most websites run on some sort of database. Technology can fail, especially when facing a higher load than expected but generally relational databases are among the most mature technologies in computing.

Removing technical dependencies to avoid such problems is throwing the baby out with the bathwater.

Besides, WordPress is dead simple to set up on almost any shared hosting plan. The static blogging solutions you probably have in mind for the most part aren't.

bigdubs2• 10 years ago

A static compiled blog system like Jekyll, or a simple caching system in-front of the blog.

Swift Evolution acceptances: The big three

Related Stories