I don't see any obvious arguments why. It integrates very well with existing C code, a lot can be done with structs and static dispatch, there are pointers, etc.

Not Rust level capabilities, but pretty good.

> Not Rust level capabilities

And you answered your own question.

If you aim for performance, "pretty good" doesn't cut it.

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

Rust still looks like Rust and it’s still safe when you have performant code.

> 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.

> If you aim for performance, "pretty good" doesn't cut it.

It does in the overwhelming majority of real cases.

But not at the trillion dollar company that is Apple, which is what we are talking about

Even for Apple, if "pretty good" performance were the price of avoiding another "goto fail" then it should be more than worth it.

Sure, for some hypothetical tradeoff you just made up then sure ¯\_(ツ)_/¯

But the reason companies as large as apple care so much about performance is because at their scale a 10% difference can easily mean 100,000 physical servers. So they do go to insane lengths to avoid "pretty good"

> If you aim for performance, "pretty good" doesn't cut it.

"Performance" isn't an absolute, and, going by the fact C++ is apparently acceptable in some "performance" codebases, there's more to it than directly controlling every single RAM allocation and making every single use of memory take maximal advantage of cache. You can't even get that in C without deep knowledge of internal compiler details.

Rust gives no finer control than C does, overall, but it installs some guard rails to make the language less accidentally unsafe. That's proof that "performance" isn't the primary goal with this codebase; if it were, it would be re-written in assembly, and the guard rails be damned.

So Swift isn't immediately out, unless profiling deems it so.