
What makes code “Swifty”? - Austin_Conlon
https://www.swiftbysundell.com/articles/what-makes-code-swifty
======
setpatchaddress
The title here is misleading. Most of this applies to Objective-C. There's
nothing wrong with the article as far as programming advice goes, but it has
nothing to do with Swift idioms.

> So, to make our code more “Swifty” from a performance point of view,
> sometimes all that we have to do [is literally the same thing we would do in
> Objective-C]

Is anyone writing consistently good, up-to-date Swift documentation for
experienced programmers? Some of the early books haven't been updated since
the earliest Swift versions.

SwiftUI is very poorly documented by Apple and much of the third-party SwiftUI
docs are for the obsolete WWDC version.

~~~
saagarjha
> Most of this applies to Objective-C.

Objective-C’s type system is much poorer than Swift’s, and it lacks a number
of expressive operations. The “before” examples are generally how a lot of
people would actually write code in Objective-C.

~~~
refulgentis
Which ones?

I wrote ObjC for 7 years, Swift for 3. I only looked at the first two
examples, they both were generic programming advice, nothing to do with the
language

~~~
saagarjha
The first three. Objective-C doesn't have enums with associated values and
it's common to store things in heterogeneous collections or stringly-keyed
collections. Creating protocols for generic constraints is also rare–informal
protocols (respondsToSelector, anyone?) are instead quite prevalent. And
Objective-C's "collection" APIs are much less powerful than Swift's: I might
use a regex replacement instead of four calls to
replacingOccurrences(of:with:), but it's the same principle.

------
iddan
Oh how wonderful will it be to program front end and backend web apps with
Swift, I just can’t wait

~~~
jamil7
I'm hoping apple starts to take the cross platform story more seriously. It
sounds like it's a big topic for the release of 6. I find it to be a really
pleasant and productive language to work in.

------
skohan
Performance is not really a USP of Swift. It's certainly possible to write
high-performance Swift code (with the help of a lot of profiling) but if your
main concern is performance, you would be much better served reaching for Rust
or C/C++.

IMO the most important things about Swift code is that it has nice safety
features, and it is easy to write clear, self-documenting code.

------
MR4D
I’d love to see Sundell go and optimize the code on the Computer Language
Shootout so we could see its potential in a swifty way.

------
bsaul
there's always been something i wondered about swift : how does it compare to
other PL in terms of performance ?

The initial promise was to have it be comparable to other compiled languages (
java , c++, whatever), but i've yet to find a real benchmark.

Or rather, the ones i've seen made it look more on the range of
interpreted/dynamic languages ( ruby / python or node), at least for server
side projects. Which came as a surprise to me.

Has any real work been work on that issue somewhere ?

~~~
pjmlp
Rather slow currently, thanks ARC.

[https://github.com/ixy-languages/ixy-languages](https://github.com/ixy-
languages/ixy-languages)

~~~
skohan
This is not a good representative benchmark for Swift. It uses lots of
reference counted objects within tight loops, which is a worst-case for Swift.
It's also not idiomatic Swift - classes are used in many places where they
should not be.

Also, it's a benchmark which needs special hardware to be run, so it's not
easy to try to reproduce or improve on this result.

~~~
pjmlp
The same conditions apply to all languages.

~~~
skohan
No they don't. GC language, for example, are more sensitive to memory pressure
to reference counting overhead.

~~~
pjmlp
First, Swift is also a GC language.

Secondly, with exception of Java, the remaining ones on that benchmark support
value types and native heap allocations.

~~~
skohan
We can get into semantics all day, but the point still stands that different
languages are going to perform differently on any given benchmarks due to the
performance constraints of that language.

Also I would love to see an implementation of the swift benchmark which
doesn't lean on reference types, which is not idiomatic swift and is likely
the reason the ARC penalty is so high here.

