Swift does not seem suitable for OS development, at least not as much as C or C++.[0] Swift handles by default a lot of memory by using reference counting, as I understand it, which is not always suitable for OS development.

[0]: Rust, while no longer officially experimental in the Linux kernel, does not yet have major OSs written purely in it.

What matters is what Apple thinks, and officially it is, to the point it is explicitly written on the documentation.

The practical reality is arguably more important than beliefs. Apple has, as it turns out, invested in trying to make Swift more suitable for kernel and similar development, like trying to automate away reference counting when possible, and also offering Embedded Swift[0], an experimental subset of Swift with significant restrictions on what is allowed in the language. Maybe Embedded Swift will be great in the future, and it is true that Apple investing into that is significant, but it doesn't seem like it's there.

> Embedded Swift support is available in the Swift development snapshots.

And considering Apple made Embedded Swift, even Apple does not believe that regular Swift is suitable. Meaning that you're undeniably completely wrong.

[0]:

https://github.com/swiftlang/swift-evolution/blob/main/visio...

You show a lack of awareness that ISO C and C++ are also not applicable, because on those domains the full ISO language standard isn't available, which is why freestanding is a thing.

But freestanding is not experimental, unlike Embedded Swift according to Apple. And there are full, large OS kernels written in C and C++.

You continue being undeniably, completely wrong.

Is it really? It always depends on which specific C compiler, and target platform we are talking about.

For Apple it suffices that it is fit for purpose for Apple itself, it is experimental for the rest of the world.

I love to be rightly wrong.

Nothing wrong with using reference counting for OS development.

Even kernel development? Do you know of kernels where reference counting is the norm? Please do mention examples.

Is this even a fair question? A common response to pointing out that Oberon and the other Wirth languages where used to write several OS’s (using full GC in some cases) is that they don’t count, just like Minix doesn’t count for proof of microkernels. The prime objection being they are not large commercial OS’s. So, if the only two examples allowed are Linux and Windows (and maybe MacOS) then ‘no’ there are no wide spread, production sized OS’s that use GC or reference counting.

The big sticking point for me is that for desktop and server style computing, the hardware capabilities have increased so much that a good GC would for most users be acceptable at the kernel level. The other side to that coin is that then OS’s would need to be made on different kernels for large embedded/tablet/low-power/smart phone use cases. I think tech development has benefitted from Linux being used at so many levels.

A push to develop a new breed of OS, with a microkernel and using some sort of ‘safe’ language should be on the table for developers. But outside of proprietary military/finance/industrial (and a lot of the work in these fields are just using Linux) areas there doesn’t seem to be any movement toward movement toward a less monolithic OS situation.

Linux? http://oldvger.kernel.org/~davem/skb.html

There's an allocation-free subset.

https://www.swift.org/get-started/embedded/

Rust's approach is overkill, I think. A lot of reference counting and stuff is just fine in a kernel.

But at least a lot of tasks in a kernel would require something else than reference counting, unless it can be guaranteed that the reference counting is optimized away or something, right?

There are some allocations where it doesn't make sense for them to have multiple owners (strong references) but I wouldn't say it makes sense to think about it as being optimized away or not.

Apple is extending Swift specifically for kernel development.