The Decade of Swift

https://www.swiftbysundell.com/articles/the-decade-of-swift/

by ingve • 7 years ago

55 139 7 years ago

swiftbysundell.com

hajile• 7 years ago

Can someone sell me on Swift over dart or kotlin? They seem to be direct competitors.

Since we're talking about the future of programming, can someone sell me on Swift instead of ocaml, SML, or F#?

I don't see a good reason to pick it outside of targeting Apple devices.

tambourine_man• 7 years ago

At the moment, there isn’t.

pjmlp13• 7 years ago

Many developers focus on a single platform, so for those living on Apple world, Swift is an welcomed improvement over Objective-C.

Outside of Apple platforms it is pretty much WIP.

biggestdecision• 7 years ago

I mean, that is the only reason. It's a first party language in the Apple ecosystem. If you are working outside that ecosystem, there are better choices.

RandallBrown3• 7 years ago

Outside of targeting Apple devices, the biggest upside would probably be that way more people are using and writing about Swift than those other languages.

zozbot2343• 7 years ago

The nice thing about Swift is that many broad programming patterns will ultimately be shared between Swift and Rust, and Swift has better support on Apple platforms. That's quite nice if everything you've had available before was Objective C or Objective/C++.

rb8082• 7 years ago

dart or kotlin? ... ocaml, SML, or F#

+ scala, go, rust, elixir/erlang

Yeah its so much time to learn all this stuff. Its a good reason they probably will all fade, better stick to js/python/java/C#/C++ like everyone else and wait.

leonidasv2• 7 years ago

better stick to js/python/java/C#/C++ like everyone else

I would change Java to Kotlin here, since Kotlin has a 1:1 interop with Java while having goodies like null safety, type inference and functional programming without the academicism of Scala (and its slow compilation time).

If you also account for the smooth learning, Kotlin is probably the safest bet from these 9 mentioned.

A lot of businesses with Java codebases are already messing with it (and not only for Android).

twblalock• 7 years ago

Since we're talking about the future of programming, can someone sell me on Swift instead of ocaml, SML, or F#?

I don't think the industry is likely to adopt functional languages. What people in the industry seem to want are safer programs with better null handling (e.g. optionals), friendly handling of async programming (e.g. futures/promises/async await), map/filter/reduce, immutable data types, and similar features that make programs safer and easier to write. Yet, the industry does not want to give up the object-oriented paradigm or the ability to do non-functional-programming stuff.

I think the future of programming languages is going to be hybrid languages rather than functional languages, simply because they are easier to adopt. In some cases, existing languages are absorbing those new features, so many companies are benefitting from them without switching languages.

Of the alternatives you mentioned, F# is the closest to being a hybrid language because of its integration with the .NET platform. Similar languages include Scala, JavaScript, Java since Java 8, Swift, Kotlin, etc. Python now has some of this stuff too.

On the other hand, Go is notable for rejecting functional features and it is also growing in popularity.

leonidasv2• 7 years ago

Excuse me, but what makes you think of OCaml, SML and F# as "future of programming"?

As much as I like OCaml, for example, I don't see it being mass-adopted in the near future, nor its tooling reaching the state of more established languages. All those languages you mentioned are most likely to continue being just niche ones.

The only mostly-functional language I can see being mass-adopted right now is Elixir, and it still has a long way to go.

lostmsu2• 7 years ago

What is Elixir?

Gibbon1• 7 years ago

One of Swift's design goals is a stable ABI. That's worth something.

m_ke5• 7 years ago

With Chris Lattner's move to Google and the state of Java it would interesting to see Google embrace Swift and add official support for it to Android.

innagadadavida• 7 years ago

Google will be making making it easier for devs to write portable mobile apps. But it will also need android deva to learn new language.

3fe9a03ccd14ca5• 7 years ago

From what I understand they’ve put their chips on Kotlin.

lostmsu2• 7 years ago

The fight of single platform gardens?

67004178• 7 years ago

This seems very unlikely to me.

They would need it to interoperate with their existing stack. They chose Kotlin where they reasonably could have chosen Swift and then worked to extend it to work with their existing stack.

Judging by what I would argue has been a lukewarm reception to Swift for Tensorflow, I think it would a very hard sell to convince people within Google to support Swift as a first-class language in the rest of their ecosystem.

They could for example start by adopting Swift for server-side programming for Google cloud and they seem to be putting no effort into that, at least public-facing effort.

m_ke5• 7 years ago

I'm pretty sure they went with Kotlin before Swift was open sourced, but I agree with you that the likelihood of them doing it is very low.

Swift for Tensorflow hasn't gotten much traction because the overlap between programmers who know swift and machine learning engineers is super tiny. Making the core language differentiable sounds very promising though .

endorphone2• 7 years ago

Just to clarify Google's choice of Kotlin -- the maker of their IDE invented and did all of the heavy lifting with Kotlin, including building the JVM targeting compiler, and the IDE to develop it in (which is the foundation of Android Studio). Adopting Kotlin was very close to free for Android, and was really just rubber stamping what a lot of developers were doing regardless.

adonese• 7 years ago

Are not they use c++/GO for their server side programming?

ardit33• 7 years ago

I hate to say this, but Swift is to Objective-c, what Scala is to Java....

It was very exiting and promising at first, but it became bogged down due to its sheer run-away complexity and over-academic approach to programming....

To an outsider, or iOS new comer, Swift looks much better than Objective-c, (due to Objective-c weird syntax), but to many insiders, Swift seems like a huge missed opportunity...

The use of Swift, outside Apple's ecosystem is going to be limited.

shmerl2• 7 years ago

I think Rust supersedes it in most aspects, especially in not being Apple driven.

skohan24• 7 years ago

I would kill for a language with Swift's productivity and usibility and Rust's tooling and ecosystem.

jbverschoor3• 7 years ago

So we’ll refuse go, typescript and react?

Apple has the best engineering talent of all tech companies.

saagarjha6• 7 years ago

I find Swift to be significantly more usable and less academic than Scala, and I like it much more as a result. Sure, it takes a number of cues from Scala, but it takes care to not fall into the same traps.

melling• 7 years ago

Nah, Swift is an easy language.

I have a Cookbook here:

http://www.h4labs.com/dev/ios/swift_cookbook.html

I’m in the process of putting it on Github.

https://github.com/melling/SwiftCookBook

SwiftUI probably means that millions of apps will eventually move to Swift, making Swift a top 10 language.

https://www.tiobe.com/tiobe-index/

RandallBrown3• 7 years ago

Swift is already a top 10 language according to TIOBE.

pavlov• 7 years ago

For a language whose nearly exclusive use case is writing Cocoa applications, it’s odd how Swift ignored most of what had made Obj-C so good for GUI apps. Instead they just doubled down on everything that C++ was and Obj-C actively had tried to avoid.

jzelinskie• 7 years ago

Would you mind expanding on these feature sets a bit more?

Because I just started playing with SwiftUI/Combine without ever using ObjC/UIKit, I don't know what parts of ObjC shined.

jcelerier• 7 years ago

That is the first time in my life I hear objc and good in the same sentence. Every UI developer I know who has worked in it actively despised it.

skohan24• 7 years ago

Can you go into any specifics? Personally I've found Swift to be incredibly easy to read and write, and that it largely delivers in terms of rolling out complexity through progressive disclosure. Most of the complexity is only there if you need it in my experience.

ken• 7 years ago

I keep hearing about this concept of "progressive disclosure", but I can't say I've seen it in Swift. Even the simplest functions I want to write, I tug on a little thread of an idea that I have, and pretty soon I'm pulling out this giant tangle that's got 3/4 of the Swift type system dangling off of it.

What you're saying may be technically true. My issue is with the "if you need it" part. Unfortunately, I don't get to choose what I think I need. The compiler does.

For example, every beginning Swift programmer runs into "Protocol can only be used as a generic constraint because it has Self or associatedType requirements" [1]. You start by thinking, I'm going to write a simple little type!, and then 30 seconds later you're digging through the least-documented parts of the Swift manual trying to figure out if there's a simple fix for this. (There isn't.) It's not like Objective-C where you write an -isEqualTo:(id) method and call it a day.

This happens all over the place. Swift lambdas are weirder than Objective-C blocks. Swift errors are weirder than Objective-C exceptions. Swift strings are weirder than Objective-C strings. Ultimately, there is always a reason for the complexity (often: performance), but the upshot is that for any Swift feature I've wanted to use, I always had to learn a lot of extra details before I was able to use it.

I feel there are a lot of other languages which are both easier to read and write, and do a much better job at progressive disclosure.

[1] https://www.youtube.com/watch?v=XWoNjiSPqI8&t=53s

developer2• 7 years ago

Has Swift improved their text handling? Last time I looked, it took way too many lines of code and temporary variables just to extract a substring range from a string. Their convoluted idea that a string can't be directly sliced with integer indexes–by bytes, let alone by Unicode code points or graphemes–was so frustrating I swore I would never look in Swift's general direction again. It was such a joke just to try to extract x UTF-8 characters starting from position y. I liked the overall feel of the language, but the fact I ran into such a horrible wall trying to perform the most basic of string manipulations was unforgivable.

Swift came out at a time where UTF-8 was already the standard. They talked a lot of talk about grapheme clusters being the most accurate representation, and then failed to deliver a coherent API to back it up. Any chance that has changed?

chc• 7 years ago

I don't think there's any world where Swift is popular outside Apple's ecosystem. It's not anything wrong with the language that's the problem, it's that the primary reason you'd use Swift over similar languages like Rust or Nim is its integration into Apple's ecosystem. It has some unique features outside of that, but not enough to make up for how deep in the wilderness you'd be running Swift on non-Apple platforms. Rust, for example, is probably more complex then Swift — but I'd still choose it over Swift for cross-platform development because the language has a strong cross-platform story.

skohan24• 7 years ago

I don't think there's any world where Swift is popular outside Apple's ecosystem.

I wouldn't go quite that far. I agree that Swift's cross-platform story is lacking, but as someone who follows the language closely, the story is improving all the time.

I see it as largely a chicken-and-egg problem: i.e. there's not enough activity outside the Apple ecosystem to improve the situation quickly, but I don't think it's impossible for it to get there.

For instance, it's already possible to use Swift in AWS Lambda, and some support for Azure's alternative offering, as well as Google's work on Swift for Tensorflow. All of these cases involve running Swift code in a very controlled environment, like a container, and this is very tenable even in Swift's current state. So even if it might be a bit of a pain to get Swift up and running on whatever exotic linux distro you run on your workstation, there are already starting to be some "easy" use-cases for Swift outside of Apple platforms. As the scope of these one-off use-cases grows, I think it's likely there will be increased demand to improve the cross-platform story in general.

Personally this is appealing to me, because while I agree that Rust is miles ahead in terms of cross-platform support, I find Swift so much more productive and pleasant to work with that I welcome more opportunities to use it.

dmitriid5• 7 years ago

That’s why Swift’s expressive and very lightweight syntax

And a few paragraphs later:

  extension Array {
    func sorted<T: Comparable>(
        by keyPath: KeyPath<Element, T>
    ) -> Self {
        sorted { $0[keyPath: keyPath] < $1[keyPath: keyPath] }
    }
  }

I can't say this is lightweight any longer.

My greatest gripe with Swift comes not from Swift itself but from its standard library. When most new languages start with their own standard libraries that are usually interfaces towards C APIs or POSIX, Swift's Foundation is half of MacOS and then some.

I recently needed to read some data from a file in Swift, and it took me quite some time to realise there was no fopen equivalent. Read/write files is a function on String? And getting a file handle is an excercise in figuring out proper dir names and user enums? [1]

There are a few other weird things in the language itself like guards which IMO are an entirely unnecessary construct that can be as easily solved with regular ifs. Or Optionals that have no way of working with them except unwrapping them (either with ! or via guards).

SwiftUI, however, is a very interesting approach, and I hope there are more frameworks (especially UI frameworks) like this.

[1] https://twitter.com/dmitriid/status/1201441652507844608

saagarjha6• 7 years ago

I can't say this is lightweight any longer.

Swift optimizes for lightness at the call site, but even the definition is quite short for the constraints it imposes.

I recently needed to read some data from a file in Swift, and it took me quite some time to realise there was no fopen equivalent.

You can import Darwin or Glibc to get direct access to fopen. It’s a bit unergonomic to use, though.

Read/write files is a function on String?

NSString, as a deprecated holdover from Foundation.

There are a few other weird things in the language itself like guards which IMO are an entirely unnecessary construct that can be as easily solved with regular ifs.

That’s the whole point of syntactic sugar and constructs which make your intent clear.

Or Optionals that have no way of working with them except unwrapping them (either with ! or via guards).

There’s also the nil-coalescing operator, but the whole point is that you can’t sweep an Optional under the rug.

dmitriid5• 7 years ago

but even the definition is quite short for the constraints it imposes.

I'd have to look up how extension method would look in this case in C#, but my hunch is that it would be more lightweight and readable, with the same contstraints.

You can import Darwin or Glibc to get direct access to fopen. It’s a bit unergonomic to use, though.

FileManager.default, .appendingPath etc. isn't ergonomic either ;)

NSString, as a deprecated holdover from Foundation.

1. How is it deprecated if that's clearly the way to read/write files?

2. Foundation is the standard lib for Swift, and the way it's designed hurts Swift-the-language immensely, IMO. If that's deprecated, what's not deprecated and how can anyone figure that out?

There’s also the nil-coalescing operator, but the whole point is that you can’t sweep an Optional under the rug.

There are several languages with Optionals, and they don't let you sweep them under the rug, and they provide better facilities to handle them.

IMO optionals the way they are (and a few other decisions) come precisely from the constraints of Foundation and original goals of Swift: to be a replacement for Obj-C when creating iPhone apps. That's why the NSStrings, and the awkward APIs, and the astonishingly large number of nullable parameters in API calls and nullable results from API calls.

cableshaft6• 7 years ago

The directory thing is more due to sandboxing than anything else. They don't want someone to be able to write an app that can read anything anywhere on your phone, so it has specific directories that have different levels of access and temporality (i.e. one is a temp folder that gets flushed each time you quit the app, if I remember correctly).

It's not that complicated once you look it up, and like most of this stuff, you can mostly write wrapper classes one time to hide the gnarly bits and call your wrapper class to do what you need to do the way you like to do it.

It's been several years since I've had it read from a file, and I actually thought I would click that twitter link and see something super complicated, but it's actually pretty straight-forward. Not a one-liner like some languages, no, but as soon as you want to open something with options (like the encoding in this one), most other languages start looking more complicated like this as well.

Like python's open looks more like this with options: "open(filename, mode='r', buffering=-1, encoding=None, errors=None, newline=None, closefd=True, opener=None)". I've opened many a file in Python scripts, but I'd have to look up buffering, encoding, errors, closefd, and opener right now if I wanted to use them (I haven't really in the past)

And Python has 11 different access modes that I often have to look up to remember what all my options are again: r+,w,wb,w+,wb+,a,ab,a+, and ab+

dmitriid5• 7 years ago

They don't want someone to be able to write an app that can read anything anywhere on your phone,

And that's the main problem with Foundation which hurts Swift as a language: it was made for iPhone apps, and hardly anything else. I was trying to make a CLI app on the desktop. I gave up and used something else.

It's not that complicated once you look it up, and like most of this stuff

Yeah, I tried to look it up. It's extremely complicated, and it doesn't help that the documentation tends to spread all the knowledge across dozens of pages with very terse documentation and next to zero examples.

I've opened many a file in Python scripts, but I'd have to look up buffering, encoding, errors, closefd, and opener right now if I wanted to use them

My example doesn't have any buffering, or encoding, or anything. It's just reading a file. There's no chance in hell you can deduce those lines from the documnentation, or find out where to put the files to read from, or find out that it's not the file's job to read/write data, but String type's (wat?) etc.

It doesn't help that the only real example of reading and writing files isn't in the docs, but in a StackOverflow answer (most other examples are either outdated, or use calls to Obj-C libs etc.)

fauigerzigerk4• 7 years ago

I can't say this is lightweight any longer.

Compared to what? What this code does can be rather convoluted and/or unsafe in many statically typed languages.

cableshaft6• 7 years ago

Swift has come a long way. I remember first trying it and XCode acting like it couldn't figure anything out in Swift, and you could almost never bring up an autocomplete or search for references or jump to definitions or any nice feature in an IDE that worked just fine with Objective-C. I decided to give it another shot years later, and I'm working on a simple game in Swift right now, and it's been a much, much smoother experience.

Although admittedly there's still some bizarre behavior. Like this morning while iterating over a simple for loop, XCode decided it was just going to stay on the final item in the collection and keep looping until my memory ran out, over and over again, and I couldn't find anyone talking about this online, but eventually decided to do a "Clean Build Folder" and then Build, and that fixed it (but why did it happen in the first place? So odd!).

And it still doesn't always think a class I wrote or renamed is valid when referencing it in another class, but a rebuild or quitting and restarting tends to fix that.

Still, I'm liking it a lot, and having a lot of fun with Swift now. SpriteKit is great for making games, except for the lack of cross-platform capability, but if the game somehow manages to take off, I can write some wrapper classes to have the same behavior as most of the SpriteKit classes I use and port it easily enough.

Andrex• 7 years ago

Most of these all sound like improvements to XCode, not Swift?

cableshaft6• 7 years ago

I guess I should say "My experience in working with Swift has come a long way", because XCode being so crap with it made it a pain in the ass to code in Swift back then, for me, especially considering how rock solid Visual Studio is in comparison.

To be more specific about Swift, though, there used to be a ton of things you had to bridge to Objective-C in order to do back then, and now it seems like there's almost nothing you have to bridge to Objective-C to do unless you want to work with your legacy code (all of their libraries now have Swift support, at least those that I use), and there's now a cool new SwiftUI framework that is very easy to use and very powerful.

saagarjha6• 7 years ago

Swift is quite strongly tied to Xcode because most people use it and that’s where Apple puts most of its tooling effort.

ncmncm• 7 years ago

I can't really imagine Swift ever breaking out of Apple's walled garden. It's a pretty big garden, but the language concedes so much to Objective-C compatibility, it is hard to see any role for it where Objective-C never got a foothold.

Where am I wrong?

OberstKrueger• 7 years ago

Is this necessarily a bad thing? ObjC did fine as a mostly Apple-centric language. Swift is generally a lot nicer to use than ObjC, even if it wasn't a clean break from backwards compatibility.

gnachman• 7 years ago

One of my projects is pure Swift and I haven’t felt any Objective-C-based pain. Mostly this is because it doesn’t have a UI. When you touch UIKit then the legacy stuff rears its head and you have to deal with selectors and NSObject and such. I think SwiftUI is supposed to be the answer to that. We ought to know whether it works out in a decade or so :). But as long as you’re looking for a general-purpose programming language, Swift is a good choice. The type system is excellent and makes a lot of things easier. I like ARC better than GC, which is the biggest selling point in my opinion.

willyt2• 7 years ago

To install swift on a raspberry pi:

curl -s <https://packagecloud.io/install/repositories/swift-arm/relea... | sudo bash

sudo apt-get install swift5=5.0.2-v0.4

[0] https://lickability.com/blog/swift-on-raspberry-pi/

wlesieutre• 7 years ago

HN truncates long URLs, you’ll need to indent with spaces for a code block to show the whole thing

skohan24• 7 years ago

the language concedes so much to Objective-C compatibility

Such as?

Personally I've taken to using Swift basically in every use-case where I can, largely because it's so nice to work with. It strikes a very nice balance between productivity (lack of tedium) and strong compile-time guarantees of correctness.

From my perspective, there are a few obstacles preventing Swift from achieving wide adoption:

1. Tooling and support outside Apple platforms has a long way to go. The story is better than it was even a year or two ago, but when compared to Rust, for example, Swift is massively lacking in this area.

2. Swift is still viewed as an iOS-only language. Even though there are now mature libraries for things like writing a webserver, and it's quite possible to write software for Linux using Swift, the developer perception is not there, and thus adoption is slow. This contributes to the lack of tooling and support.

3. Performance needs some improvement. ARC and copy-on-write are great for writing correct code easily, but they lead to some serious and sometimes unpredictable performance cliffs with Swift. There is a lot of low-hanging fruit here, but this needs to be addressed before Swift could ever find a place as a systems programming language for example.

So I would not quite say I'm bullish with respect to Swift's chances of breaking out as a general purpose programming language, but objectively speaking I would say that all the problems preventing Swift reaching that state are solvable problems, and Objective-C compatibility has little to do with it.

sys_64738• 7 years ago

due to Objective-c weird syntax

Objective-C is simply regular C with Smalltalk objects added. If you know Smalltalk and you know C then you're golden.

lazyjones• 7 years ago

Swift doesn't seem to be a bad language, but during my brief adventures with it I encountered a major drawback: differences between versions are so great, that searching the web for examples is problematic and you end up with many fruitless attempts and compiler errors. Apple's documentation isn't nearly as useful and readable as that of the Go team.

cableshaft6• 7 years ago

This was definitely true in the past, and might still be true now, I'm not sure, but XCode does a good job of catching Swift errors now and can fix several of them for you, and for those that don't, there mostly seems to be useful StackOverflow answers for the error messages online now.

I took a long break from working with Swift and just started diving into it again, and even though there was two major versions since I last messed with it, it was pretty easy to settle into it, and I've only had to look up how to do things on a case by case basis periodically. Maybe that's just my experience, though, and others have a harder time with it.

skohan24• 7 years ago

This is not nearly as much of a problem as it once was. Especially with ABI stability, a lot of the language feels much more "nailed down" and language changes now tend to be additive rather than breaking.

geophile3• 7 years ago

I like a lot about Swift: strong typing, good support for closures, reasonable abstractions. But there's a lot that I dislike too. A lot. In general, I find the language to be far too trendy and fussy. I get the impression the design was guided by the goal of streamlining snippets of code meant to highlight cool features, gaining undesirable complexity as a result. One example: Do we really need $n function parameters? In just about every other language, a function has parameters, period. Those names are used inside the function. Depending on the language they may be used outside the function too. Swift separates those inside and outside views, permitting different names for both. And then allows for no names at all! I don't care. $n parameters seem to come from primitive languages like sh, and should have stayed there.

get/set/didSet introduces ridiculous complications just so we can pretend that a large number of function invocations look like assignment statements. This was a cool idea in C++, briefly, and then we discovered that having arbitrary code hide behind what looks like an ordinary assignment statement was a bad idea.

Extensions also remind me of C++ excesses. It is difficult to look at a piece of code involving a variable some type and be sure that I understand how that type works. The problem is that the code implementing the type is not in one place. There is the type definition, but then there are extensions. Possibly many of them. Defined all over the place.

I really dislike the irregularity surrounding let. In one context in unwraps an Optional. In another context it does not. Why?

I got off the Swift train at the release in which associated types were introduced. I'm sure it solves some actual problem, but it sure wasn't clear at the time. (The project ended -- it's not that I decided to go back to Objective C.)

Reference counting is far too intrusive, and it is easy to get it wrong in subtle ways. I find Java's (!) memory model relatively simple, and that's saying something. I understand why reference counting was chosen over GC. I don't have a good answer, but reference counting is just ugly. I actually think I prefer the C/C++ model of explicitly freeing memory.

setpatchaddress• 7 years ago

I certainly don't disagree that there's too much C++ in Swift (the Swift architects write C++ for a living, not ObjC, so it's hardly surprising) but it's not due to trendiness. Most of the features you mention derive from direct experience with Objective-C. Function arguments, property accessors (get/set/didSet), extensions (categories), etc. Every one of these things solves a real problem in the field.

I don't understand your comment about reference counting being intrusive. Apple's implementation, ARC, used in Swift and modern ObjC, is essentially invisible to you if you're using native objects.

geophile3• 7 years ago

I don't agree that get/set/didSet solve actual problems. Languages without property accessors do just fine, but then they don't overload the getting and setting of variables. I would much rather right thing.setField(123), and have setField do whatever actions need to accompany the assignment; than write thing.field = 123, and then have the actions be hidden. What is so f'ing special about x = thing.field and thing.field = x syntax? Why is it so important to stuff additional semantics into that syntax?

As for reference counting: I'm referring to capture lists, and the "unowned self" hack needed with closures. E.g. https://www.raywenderlich.com/966538-arc-and-memory-manageme.... And it gets more complicated with @escaping. I sure don't view all these subtle interactions of closures and ARC to be invisible. This stuff is subtle. Get it wrong and you have leaks.

fauigerzigerk4• 7 years ago

I don't understand your comment about reference counting being intrusive.

It's intrusive because you can never really stop thinking about it if you want to write correct code. Here's an example from a very interesting article by Mark Sands [1]:

How quickly can you tell whether or not this piece of code has a reference cycle?

    class ServiceLayer {
        // ...
        private var task: URLSessionDataTask?

        func foo(url: URL) {
            task = URLSession.shared.dataTask(with: url) { data, response, error in
                let result = // process data
                DispatchQueue.main.async { [weak self] in
                    self?.handleResult(result)
                }
            }
            task?.resume()
        }

        deinit {
            task?.cancel()
        }
    }

In my view, reference counting does not combine very well with heavy use of closures.

[1] This is an interesting read: http://marksands.github.io/2018/05/15/an-exhaustive-look-at-...

skohan24• 7 years ago

Swift separates those inside and outside views, permitting different names for both.

The named parameter handling is one of my favorite features of Swift. It makes Swift code self-documenting in a way most languages aren't.

geophile3• 7 years ago

I actually don't mind that feature too much. I do appreciate that it clarifies code with even a few arguments of the same type. Although there are other ways to clarify such situations in other languages. The Swift approach does lead to exceptionally verbose code, but that's obviously subjective.

It's the $n syntax that I think is overkill. Do we really need three different ways to name parameters?

lokedhs5• 7 years ago

Why was refcounting chosen? It seems to me it was only done because the designers were so used to C++ that they don't understand the drawbacks of not having it.

pjmlp13• 7 years ago

Easy, interoperability with Objective-C runtime and Cocoa refcounting patterns.

bsaul• 7 years ago

I’ve recentried tried google trends to see if swift was gaining popularity overall :

https://trends.google.com/trends/explore?date=all&q=%2Fm%2F0...

Imho There’s definitely an issue in the strategy for this language ( or for ios native development since the two are tied).

My guess is cross platform development is eating mobile, and swift has nothing in that area.

carlhung• 7 years ago

I love swift. but i think it is getting lack of traction.

The Decade of Swift

Related Stories