[Klonoar]

All of the following:

- As malleable as JavaScript when you need it to be

- As typed as your favorite language when you need it to be

- Able to drop to much more arcane levels if you need to for certain performance-intensive places, without requiring some crazy setup (e.g, C/C++ are right there if you need them)

- ARC is IMO one of the best approaches to memory management out there

- The verbosity can be annoying at first, but it forces you to think hard about everything, and when I come back to Objective-C code years later, I've no issue remembering what the hell I was doing there

- People complain about brackets, but they just... don't matter. It's a syntax. You either deal with it or don't - you don't see me writing Lisp because I find the syntax annoying, which is fine.

- Message passing in ObjC is so optimized that it probably can't get much faster, and anyone acting like it's slow has a potentially skewed understanding of this

Swift is nicer for me in only two distinct ways:

- No more header files, because man was that annoying

- The stricter nil handling is overall better, if not a mental shift from some ObjC counterparts

[jchb]

> - Message passing in ObjC is so optimized that it probably can't get much faster, and anyone acting like it's slow has a potentially skewed understanding of this

The problem with Objc message passing is not the absolute execution time involved in passing a message. The problem is that the dynamism involved completely disables the compiler from performing any code-inlining. Typically inlining small functions is what enables the compiler to unlock further optimisations. From simple things such as merging duplicate loads from same address, to auto-vectorization.

[Klonoar]

Consider the following: the smoothest UI/UX platform of the past decade has been iOS, which was pretty much built on ObjC.

These types of speedups just aren't necessary in that world. You'd drop to C or C++ if you needed it, which is trading convenience for complexity.

You could want it to be faster, but it's not going to materially show itself in common workloads.

[coliveira]

If you need this level of optimization you can always use pure C functions, which is exactly why Objective-C was created as a C extension.

[kccqzy]

If you want inlining don't use message passing. Just define your function as if you were writing C. Simple. Use message passing when you need the dynamism.

[apple4ever]

> - The verbosity can be annoying at first, but it forces you to think hard about everything, and when I come back to Objective-C code years later, I've no issue remembering what the hell I was doing there

This this this. I love how it forces the verbosity. It makes it so easy to understand.

> - People complain about brackets, but they just... don't matter. It's a syntax. You either deal with it or don't - you don't see me writing Lisp because I find the syntax annoying, which is fine.

I really don't mind the brackets. If you structure your code right, is not even that big of a deal.

> - Message passing in ObjC is so optimized that it probably can't get much faster, and anyone acting like it's slow has a potentially skewed understanding of this

Not just this, but I love how you can send messages to nil and it doesn't crash, or you can define a method in code and it runs.

[pjmlp]

Reference counting is the slowest way of doing automatic memory management, the only thing about it is being the easiest to implement.

And it shows, Swift gets slammed on the ixy paper by all tracing GC languages, spending an huge amount handling counters.

It makes sense for Swift though, because it is the easiest way to integrate with Objective-C, given the failure of its GC experience , having to deal with C semantics and non-GC enabled frameworks, that lead to constant crashes.