Not Swift by default

I really recommend reading how Maxim made his FlatBuffer library 10 thousand times faster Swift.

The interesting part is when he realized how much faster the C implementation was compared with Swift. And how the profiler showed that a big chunk of the time was in memory management code done by ARC.

Is in this cases were I think that Swift still has to do a big leap to be what we want it to be, a language that can be used for scripts, user applications and low level systems. And having to deal with the penalty of ARC being always there is not the best for a language that claims to be a system level language.

Granted, with some effort and knowing where the issue is, one can shape Swift code in a way that reduces or even eliminates that performance penalty.

We saw that allocating memory and retain release calls where dominating when profiling. So why not just do the same bare bone thing that C does. Write a bunch of functions which read data from a byte array without allocating any objects.

I’m honestly happy that this can be done. That, at least, we have the option to opt-out of ARC and its performance implications. And luckily is not that hard, you just have to know what to use and what to avoid.

Looking where the bast majority of Swift code is written is logical that the default for it more on the side of removing the burden of memory management for the developers at the cost of a performance penalty.

I just wish that in the future Swift can help us a little more on being performant by default. Otherwise will be harder to remove the stigma of it being only useful for iOS Apps.

The hope is in some Chris Lattner comments. The idea of using Rust approach is in the air, but it will probably look quite different, being an opt-in feature as it is right now.