> Sad but true, performance is possible in swift but it’s not very idiomatic and usually not safe.

There's nothing sad about it. You pick the right tool for the job. Swift is not designed to be a reference tool in performance-sensitive applications, thus you pick the tools that are.

There is no need to shoe-horn the wrong tool just because it's popular of fancy. A tool is just a way for technicians to express their skills, and just because someone is skilled at developing front-ends that doesn't mean he is a competent at developing performant systems-level application. Specialization matters, not only in tools.

> There's nothing sad about it.

Why? It's a drop-in replacement for Objective-C that allowed you to dip into C and C++ code in the same code file, even in one function.

Now Swift is faster for most higher level scenarios a front-end developer deals with but it's slower than the C performance Objective-C allowed.

I.e. it isn't a drop-in replacement. There is nothing wrong about a language not being good at something. When you want to have everything, you get C++. And working with C++ is just sad.

> you want to have everything, you get C++.

C++ is an excellent example on the perils of developing a tool that's good at everything, because the cognitive load to do anything with it is simply not manageable.

Picking the right tool for the job is always the solution.