Why would they use Swift? It doesn't seem like the most fitting replacement for C level infrastructure.

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.

Swift’s performance isn’t really up for high-performance network processing, at least not yet.

Swift is a LLVM front-end just like Rust.

That doesn't magically make Swift and Rust equally performant.

You are saying that like it must then be as fast as Rust by this virtue.

No, semantics and idiomatic code matters but I don't think performance oriented Swift code would be significantly slower than Rust. I might be wrong though - feel free to share relevant benchmarks.

There are some benchmarks that I think you should give them a look: https://github.com/ixy-languages/ixy-languages https://benchmarksgame-team.pages.debian.net/benchmarksgame/...

Interesting, thanks! Ref counting has an overhead, of course. I wonder about the performance of the "performance oriented Swift code" - i.e. it would be non-idiomatic, but to avoid ref-counting - something you would write in your inner loop or other similar hot points.

Yes, they're programs from the benchmarks game that use a lot of UnsafeMutablePointer, which is: > provides no automated memory management or alignment guarantees. You are responsible for handling the life cycle of any memory you work with through unsafe pointers to avoid leaks or undefined behavior. [1]

So I think they're "performance oriented Swift code". I'm not familiar with Swift, so sorry if I'm wrong. [1]: https://developer.apple.com/documentation/swift/unsafemutabl...

Rust has more safety features and better runtime performance. So either or both of those reasons.

Swift is not yet a zero-abstraction-cost language like C or Rust which might be one of their concerns.

C is far from zero-abstraction-cost. For example you can't do a generic qsort supporting user defined types with zero overhead, other than with preprocessor macros (ugly, unsafe, unmaintainable).

This sort of standard seems hard to meet for any language, if the bar is "all abstractions should be included and zero-cost." In practice, you probably write a specialized quicksort for a given type in C to work around the lack of generic quicksort. You do this in the same way you manually convert your suspendable forkable computations into a struct that has all your "local variables" and an "instruction counter" inside to work around the lack of copyable coroutines in almost every language.

Depending on your choice of compiler, a more legitimate concern with C is maybe the lack of computed goto. See here about the nonzero cost of missing this feature: https://eli.thegreenplace.net/2012/07/12/computed-goto-for-e...

So there's an intrinsic cost to abstractions: namely that by using an abstraction, you're not specializing to the optimal extent possible; your general-purpose algorithm may well be close to ideal, but various details will not be; and even in languages that support specialization, you're likely to end up in a not quite optimal solution.

But that's not what people usually mean with zero-cost, right? They mean that assuming you do use the same algorithm, then the abstracted version is just as fast and memory efficient as the specialized version.

And that is a bar that C++ at least clearly meets, and, by the looks of it, rust is in practice much closer than C. Other languages have various features that address this need too; it's not that rare. C really is particularly poor here, but even C has macros, and although it's horrible in terms of usability, people nevertheless manage to do some pretty nifty stuff with macros.

Still; it's fair to say C is pretty bad at zero-cost abstractions, and that widely used alternatives support that a lot better (even C++ alone is a solid chunk of the market, more than C - https://redmonk.com/sogrady/2020/02/28/language-rankings-1-2...) Implementing a custom quicksort in C is a pain, enough pain that I expect most hand-tuned special case quicksorts are likely slower than general versions available for C++ simply because people aren't going to bother doing a good job; it's too much work. And that's just quicksort; the same goes for lots and lots and lots of other things too; reimplementing everything from scratch is just too much pain - in practice people are likely to not bother, and just pay the costs.

So while "zero-cost" abstractions are a slightly nebulous goal, clearly C in particular is worse at providing those than all of its low level competitors and wannabe competitors (C++, Rust, D, Nim, etc).

This is a great comment and I endorse it.

Lots of other languages make it way easier than C to write "fused quicksort". Although it doesn't pay much regard to programming language theory, Jai is another interesting language in this area, made by a guy who's mostly concerned with being able to express the fully specialized/fused version of everything without creating extra work for the programmer.

Here is a widely-used example of a zero abstraction cost, type safe red black tree in C:

http://libredblack.sourceforge.net/

It supports a few modes of operation, including codegen, and preprocessor tricks. It’s clearly maintainable, given its age and continued use.

Your third complaint is that C with preprocessor macros is ugly. That’s subjective.

I think C++ is more elegant than C + macros, but the GTK people clearly disagree.

I think you've inverted the meaning of "zero abstraction cost" here. It's not that writing abstract code is well-supported and free; it's that the language basics aren't built upon a stack of expensive abstractions.

When I’ve seen “zero abstraction cost” used, it generally has meant that writing high-level abstract code is the idiomatic way to use the language, and that it comes with zero runtime overhead. (This is the main selling point of modern C++.)

Why is this downvoted? It's a valid question. Chris Lattner, the creator of Swift, has stated many times his goal of Swift being the best language for all uses.

Maybe one guy's goal isn't the same as 100% corporate buy-in.

Either you misquote him or he has no idea what he is talking about. Maybe in a walled garden as Apple's it could come pretty close in many instances but One Language To Rule Them All is naive at best.

>Either you misquote him......

Not parent but no, I wish that was the case, he stated it numerous times and he compare it to scaling from Low Level C to Javascript. That was 3 - 4 years ago.

I was extremely sceptical of it because it was unrealistic, that is of course very much against the silicon valley optimistic view so it wasn't a popular opinion. But in a recent interview he has definitely rephrase and said it doesn't need to be the best in everything.

Now I have another problem, It is not the best at anything, what is it actually good at?

That is why I still think Objective-c is going stay for at least a few more years.

Ah yes, a creator of a language wanting his pet language to be the best language for everything. That's a first

Reference counting.