Apple’s use of Swift in iOS 12

Not saying that it's an unsolvable problem elsewhere, it's just an anecdotal benefit we got

This is, in many ways, the diametric opposite of what this thread is discussing: pushing out nominally "stable" versions to the outside world, breaking things, but not committing internally.

In Swift, this is currently not stable, meaning it changes with each version. The result is that you can't use a library compiled with version X of Swift with version Y of Swift. From version 5 onward the ABI will be compatible between version 5 and versions >5.

By doing optional chaining you can do something like: if let name = result.person?.firstName { ... } which only evaluates firstName if person is not nil, and then stores the result in name which is immutable.

It's easier to avoid mutable code in Swift than in many other languages. For this reason I would love to start working with Swift on the backend at some point in the future.

I like extensions, being able to extend any class I want by just typing it into any file I want. This helps with iterative development and trying something out.

Speaking of iteratively, if I want to try something quick, I can also drop down to a shell and start the Swift REPL to experiment.

I like how built-in functions like zip and mapValues are available, so it in some ways has a Pythonic feel. I like the syntax of building strings by just taking a variable name and going let s = "Hi there \(name)!".

There are lots of other things I enjoy, such as subscripts (see why here: https://docs.swift.org/swift-book/LanguageGuide/Subscripts.h...) and

Some things I would like to see improved is Xcode itself and also Swift's capabilities in the backend.

- rich enums - (https://appventure.me/2015/10/17/advanced-practical-enum-exa...) Much of my code is now encapsulated in the enum, where it logically belongs, instead of distributed throughout some class that consumes the enum.

- highly expressive pattern matching - (https://appventure.me/2015/08/20/swift-pattern-matching-in-d...) Swift's pattern matching is especially powerful with a switch statement. I frequently bundle multiple values into a tuple and switch across them, which allows me to flatten many if-else pyramids, and makes control flow more obvious up front.

- Optional - (https://developer.apple.com/documentation/swift/optional)

- Protocol extensions - (https://docs.swift.org/swift-book/LanguageGuide/Extensions.h...) Other languages use things like abstract classes or traits to implement this behavior, but I find protocols to be much more composable.

- The standard library - Swift's standard library is really well thought out. Many standard types have been built on top of highly reusable (and easy to reason about) types or interfaces that provide enormous utility when I adopt them in my custom types. Examples of this are: Codable (https://developer.apple.com/documentation/foundation/archive...), Equatable and Hashable (https://developer.apple.com/documentation/swift/adopting_com...)

There's more than that, and Swift is definitely not without it's shortcomings, but those features have fundamentally changed how I reason about code. I frequently find myself wishing I could reach for similar tools in other languages.

But most new languages has some variant of this stuff: kotlin, scala, rust.

I program a lot in Julia which is a script language and it does not have allow you to use null freely either. May seem odd for a language that does not type check at compile time. But it actually makes sense.

Also, take into account that in Objective-C you can send any message to a nil pointer, and the result will be nil or 0 (for scalar types), as defined by the language standard.

Foo was rewritten in Swift, and bar was super buggy. Why would you blame that on Swift?

However if you adopt different patterns with Swift you can exclude a lot of optionals, for example if you give every View a State enum with associated values you can avoid quite a lot of optionals:

    class PersonView: UIView {
        enum State {
            case empty
            case loading(personId: String)
            case loaded(person: Person)
        }

        var state: State = .empty {
            didSet {
                switch state {
                /* handle all different states */
                }
            }
        }
    }

And it's applicable almost everywhere. I barely use optionals anymore unless I really can't replace them with an emum.

Swift is not defensive, Swift can be defensive, but it can not if you don't want to.

It's much more "offensive" than Objective-C, for example.

Just a "!" and it's the same as Null Pointer Exception == Fatal Error.

https://en.wikipedia.org/wiki/SQL_Server_Management_Studio

Are you sure you're not talking about storage space? I don't know what memory diagnostic app you're talking about.

Sure it's not 'the memory diagnostic app' that's wrong?

Don’t forget to update your anti-virus too!

How's that so? An app doesn't have to leak OS memory, just leak its own memory.