
Swift Programming Language Evolution - rufus42
https://github.com/apple/swift-evolution
======
twoodfin
To me, the most interesting empirical result of the Swift language evolution
so far is the lack of urgency on language-level concurrency.

If they think they can be competitive for years (at the very least vs.
Objective-C) with only platform-level concurrency support, it makes me wonder
whether concurrency is generally better provided by the platform instead of
the language for most needs.

Conventional wisdom would have it that for a systems & application language
designed in 2014, a good concurrency story would be close to job #1.

~~~
lobster_johnson
Go (which I think you're alluding to) has language-level concurrency because
its syntax is extremely rigid. Swift's syntax is flexible enough that this
isn't needed.

Specifically:

* Support for annotations; the compiler/runtime can be informed about safety and marshaling concerns. * Anonymous function bodies. You can implement Go's "go func() { ... }()" pattern yourself, and a concurrency runtime can implement it. Rust uses the exact same pattern. * Generic iterators/streams. No need for channels as language primitive since you can write a generic channel implementation.

Go is nice, but its language-level concurrency is very much a side-effect of
its intentionally impoverished type system. For example, the built-in "chan"
type exists because otherwise a generic channel implementation would have to
use interface{}, which is not type-safe and would be hell to work with.

Here's what's lining up to become Swift 4.0's concurrency support (all the
concurrency models!):
[https://github.com/apple/swift/blob/master/docs/proposals/Co...](https://github.com/apple/swift/blob/master/docs/proposals/Concurrency.rst).

~~~
Razengan
I like this particular example of how easy it can be to make Swift act like it
has language-level concurrency features:
[https://github.com/beeth0ven/BNQueue/blob/master/BNQueue/BNQ...](https://github.com/beeth0ven/BNQueue/blob/master/BNQueue/BNQueue/BNQueue.swift)

Some enum and extension magic easily lets you write things like:

    
    
      Queue.UserInitiated.execute {
        let url = NSURL(string: "http://image.jpg")!
        let data = NSData(contentsOfURL: url)!
        let image = UIImage(data: data)
    
        Queue.Main.execute {
          imageView.image = image
        }
      }

~~~
lobster_johnson
That's awesome. Blocks were always my favourite part of Ruby, and I think it's
really cool that it has been adopted into Swift and (to a lesser extent) Rust.

------
Someone1234
So Swift has been out awhile, what do people think of it? What other language
would you compare it to (e.g. C#, C, C++, etc)? What about the libraries are
they well laid out?

~~~
kris-s
My favorite thing about Swift is that is seems to get out of the way - and
when it gets in the way it's usually with a nifty language feature (like the {
$0 + $1 } closure syntax). I'm very excited for the future - between Go and
Swift we now have two compiled fast languages that are almost as expressive as
their slower dynamic/interpreted cousins.

As an aside, I like that Apple is betting the farm on ARC. I wish I could have
been a fly on the wall when they were discussing ARC versus GC.

~~~
dalbin
There is a pretty good comment from Chris Lattner about ARC versus GC :
[https://lists.swift.org/pipermail/swift-evolution/Week-of-
Mo...](https://lists.swift.org/pipermail/swift-evolution/Week-of-
Mon-20160208/009422.html)

~~~
shiny
I really like the `deinit` construct that comes with ARC, which lets you know
when an object is about to be deallocated. Makes it much easier to find memory
leaks, imo.

~~~
Razengan
Indeed. `deinit` has saved me from things that would have caused much greater
problems later on. It's probably one of the more subtle features that one
would miss the most when moving to a language that doesn't have it.

------
rezashirazian
Swift is fun. I'm having a great time playing around with it. There are some
nuances that take some getting used to, but overall, it's a powerful, fast and
fun language to work with.

If you are interested, I have taken on implementing all major design patterns
in Swift. I've gone through about 10 of them right now, (7 published on my
blog).

If you've never worked with Swift but wish to get a feel for it without going
through overly simple tutorials, check them out:
[https://shirazian.wordpress.com/2016/04/11/design-
patterns-i...](https://shirazian.wordpress.com/2016/04/11/design-patterns-in-
swift/)

------
Karunamon
Are there any plans in place for locking down the syntax? Major release 3 is
coming and developers are still being expected to hit a moving target.

One of the nice things about C is that K&R era C is just as valid as C written
nowadays, but Swift appears to be going in the opposite direction, every major
release adding and removing bits of syntax.

As someone unfamiliar with the language, it makes me not want to pick it up,
since guides and documentation I read now will be incompatible with the newer
release when it happens. Some early toying around during Swift's original
announcement led to hard-to-debug errors (in part, caused by terribly useless
error messages) when trying identical code on newer releases.

~~~
mikeash
C got started in 1972, and K&R C dates from 1978 and includes compatibility-
breaking changes.

You want a young language to change a lot, because you don't really know what
it needs until you get it out there and people use it. You want to make
necessary changes as early as possible to cause the least pain. Major changes
at the two-year mark will be a lot easier than major changes at the five or
ten year mark, and waiting too long to fix a bad decision will probably mean
it sticks around forever.

I would expect Swift 3 to be the last release with major source-breaking
changes.

~~~
teacup50
However:

\- Almost nobody actually _used_ C prior to 1978.

\- Most C compilers have supported both current and previous versions of the C
standard via _-std_ flags.

\- Other languages with breaking changes, like Java, are similar. Java has
always supported specifying the source language level via _-src_.

Swift is unique in breaking old code completely, without recourse other than
semi-functional code rewriting tools.

~~~
mikeash
Almost nobody actually used Swift prior to mid-2014. Did any 1978 C compilers
offer both K&R and prior as options?

IMO the example of Java is a great illustration of why Swift shouldn't be tied
to source compatibility too soon. You don't want to be stuck supporting your
1.0 syntax until the end of time, or you'll end up like Java!

~~~
teacup50
Used everywhere, with decades old libraries that still function fine?

------
b123400
While the language is nice, I find it hard to work with existing frameworks,
given they are designed for a language as dynamic as objective-c. For example,
NSError, NSNotification's userInfo is a `[AnyObject:AnyObject]`, but its
member types are specified in documentation. It would be nice if we can have
specific error will typed userInfo. Working with storyboard is the same story,
there is no type check for VC and segue because identifier is a string,
instead of something like `R.id.view` on android. Working with this kind of
API requires lots of casting, I wonder will Apple design Swift-centric API
later.

~~~
rsmoz
Apple has already done a lot to make this sort of thing nicer. They added
lightweight generics to Objective-C, so arrays are typed now. NSError bridges
to ErrorType. They've also announced further plans to Swift-ify existing
Objective-C APIs.

------
bouiaw
Quite surprised to see no mention of Kotlin here since both languages are very
similar, main difference is Swift is LLVM based while Kotlin run on the JVM
and has excellent Java interoperability.

See [http://fr.slideshare.net/andrzej_sitek/swift-and-kotlin-
pres...](http://fr.slideshare.net/andrzej_sitek/swift-and-kotlin-presentation)
for more details ...

------
ryandev
I've never understood the fascination with Swift. What's wrong with Objective
C?

~~~
mikeash
Objective-C has no safe collections for non-object values. If you want an
array of ints, for example, you either get to use a C array with lots of
manual management and potential for error, or you use an NSArray of NSNumbers
and pay for a bunch of overhead.

It has very poor support for custom value types. Objective-C structs basically
can't contain object pointers, so they're limited to simple things like
CGRect. They also can't contain methods, so you end up writing associated code
in global functions.

Protocols are extremely limited. They're basically just collections of method
declarations. There's no way to add functionality to every class which
conforms to a protocol.

Objective-C is often verbose to the point of painful redundancy. Consider:

    
    
        NSString *x = [NSString stringWithFormat: @"%d", number];
    

Versus:

    
    
        let x = String(format: "%d", number)
    

Other examples include having to write the signature of every public method
twice (once in the header and once in the implementation) and the need to do
an annoying `self = [super init]` dance in every initializer.

There's almost no functional programming stuff available, like map and reduce.
This is not strictly a language complaint, but since the standard libraries
are pretty tightly woven in, I think it still counts.

Generics support is really limited. What's there was only added to
interoperate better with Swift, anyway!

That's a quick overview of some of the ways Swift improves on ObjC. I'm sure
there's more.

~~~
hedgehog
I'd add typed enums to the list of notable bug-avoiding improvements in Swift.
I sometimes describe Objective-C as "all of the memory safety of C with the
type safety of SmallTalk".

~~~
thevibesman
I may steal that quote; I think I like it better than calling Objective-C the
"wild west of OOP".

------
itsbits
Am I the only one as a JS dev, who find it hard with types & casting in Swift?

~~~
matthewmacleod
Probably not. Types and casting seem complex to people coming from more
dynamic languages – that's okay though! It formalises something that you
generally don't have to think about in Javascript – the tradeoff being that
you have more consistent, less buggy software at the expense of more effort
while writing it.

~~~
itsbits
Agreed. I am yet to formally make my app available but had tough times mainly
while doing Ajax calls, typecasting the JSON i got. Infact took time to
understand some concepts like ARC, Optional Chaining when you are from JS
background.

~~~
jallmann
> typecasting the JSON i got

This is where a typed serialization comes in handy. (Protobufs, Thrift, Cap'n
Proto, etc.) It is also possible to use an IDL to generate a type-safe API to
deal with JSON -- although I don't know of any tools that emit Swift.
Interfacing with third-party JSON APIs can be a pain though.

------
tyingq
Does "will be portable" include any notion of a cross-platform UI?

~~~
matthewmacleod
Languages don't have UIs - frameworks do. I realise it's a pedantic
distinction, but it's an important one.

~~~
tyingq
I get the distinction, but there appears to be a deliberate direction to make
Swift more portable. Thus, I was curious if that effort might include
something UI related in the future. The interest level would certainly spike
up if something were available.

~~~
allsystemsgo
But, that wouldn't make any sense to include UI components in a programming
language. And I think the interest level is already "spiked".

~~~
tyingq
Okay. I was under the (perhaps not true) impression that the vast majority of
swift apps were iphone apps, with the apple specific UI bindings. Such that
one of the first questions on a new platform (Linux, Android, etc) would be
"how do I create the UI?".

It sounds like instead, the cross platform appeal is that back end or
background services can now be written on non-apple platforms?

~~~
allsystemsgo
That's correct. UIKit isn't like, baked into Swift. Whatever platform you're
writing for would need to provide to you UI components and then some.

------
merb
It would still be great if everything would be a value.

------
DonFromWyoming
The removal of prefix and postfix ++ and -- operators and the removal of
C-style for loops are mistakes, IMO.

~~~
lanestp
I gotta disagree with this one. Those operators have always been confusing and
unnecessary. j = i++ being different from j = ++i alone is enough to convince
me it's gotta go.

~~~
gagege
Exactly. I am disappointed they're removing function currying/partial
application syntax though :(

~~~
thevibesman
This was my first reaction as well, but then I realized I hadn't done much
currying in Swift and half forgot it was a feature.

Maybe you can bring it back when we get hygienic macros (Swift 4.0? _fingers
crossed_ )

------
bitL
How does Swift compare to D?

------
dang
Submitters: Please don't rewrite titles to say what you think is important
about an article. Cherry-picking a single detail is a form of editorializing,
which HN doesn't allow in story titles. The guidelines ask you to change
titles only when they're misleading or linkbait, which wasn't the case here.

If you think one detail is most important, you're welcome to comment on that
in the thread. Then your opinion is on the same level as other users'.

(Submitted title was 'Swift 3 will be portable / be able to run on more
platforms'.)

~~~
grayrest
Enforcement of this particular policy is one of the things I dislike most
about HN. The current title is awful. It gives no information that the URL
itself does not and doesn't explain why I'd care about the contents _now_
given I've visited the repo in the past. I'm not opposed to the removal of
editorializing but it should get replaced with something neutral that still
captures why the URL was submitted, e.g. "Swift 3 Roadmap Update".

------
astazangasta
There are too many projects named 'swift'.

------
Keyframe
A bit too late for wider adoption, isn't it? Are there examples of similar
path to openness?

~~~
matthewmacleod
I don't see why that would be the case. The language has been public for less
than two years, and I don't see any reason it wouldn't become widely adopted
for situations where it's a good fit.

------
jsonninja
Swift is great language and an enormous leap forward in the apple-sphere. I'd
like to see a bigger investment in JavaScript everywhere. I'd like to see
apple make a push to allow writing 100% javascript apps for iOS and mac. I
think it could be a huge differentiator for iOS and Mac development and it
would bring to Apple the largest developer base out there.

~~~
DerekL
Starting with OS X Yosemite, you can use JavaScript for writing Mac apps and
scripts.
[https://developer.apple.com/library/mac/releasenotes/Interap...](https://developer.apple.com/library/mac/releasenotes/InterapplicationCommunication/RN-
JavaScriptForAutomation/Articles/Introduction.html)

~~~
jsonninja
Using JS for automation is a great start. I don't think they have a way to
build a JS app that leverages the full capabilities of either Mac or iOS yet.

~~~
robterrell
You can write full OS X apps in JavaScript:

[http://tylergaw.com/articles/building-osx-apps-with-
js](http://tylergaw.com/articles/building-osx-apps-with-js)

JavaScript bridging works on iOS too!

