[eddythompson80]

Apple has something with Swift similar to what Google has with Go. The language has a lot of desirable features for server development very much like Go and Rust. Especially when compared to Java and C#.

It makes sense for them to build their services using Swift instead of something like Go and the Swift-on-server team has been doing a lot of work to get swift in a usable state on Linux. Having a thriving opensource (starting with a package index) makes a lot of sense to them for that.

My only problem with Swift is personal taste and experience. I tried it on linux few times (admittingly few years ago now) and generally I wasn't a fan. Go and Rust solve all the problems that Swift could have solved for me, so I didn't bother. But just like node got an entire class of developers into server side programming, Swift could be apples approach to get their iOS and MacOS developers a way to easily write server side code in swift as well

[frizlab]

Swift on Linux has changed since a few years ago. A lot.

I prefer Swift over rust as it has the same memory-safety guarantees with a much more approachable syntax, and is generally easier to work with.

[hocuspocus]

Easy and approachable sound pretty subjective to say the least; feature and syntax wise, Swift has become an absolute monster of a language. Rust's tooling and ecosystem are ahead and these points matter to me more than the raw syntax in the age of LLMs.

[frizlab]

As per my experience, the learning curve of Swift is easier than rust’s. Yes, obviously, it’s subjective. Yes, if you want to do complex things in Swift (e.g. generic packs), the syntax is more complex, but that’s not needed every day.

As per the tooling, idk enough to report on that.

As per the LLMs remark, I do not use that at all, still, and hopefully never will, though I already know I won’t have the choice at some point, sadly.

[tialaramex]

The same condition is still true as the first time I was told "Swift on Linux" is somehow a first class experience:

> Documentation for the standard library is presently hosted on the Apple Developer website.

Sure enough, by Apple policy, the documentation pretends no non-Apple platforms exist. What happens for an API which could be different if your system isn't fruit-flavoured? They don't care and won't talk about it.

Is the feature I need available for this Linux device? No idea, but it does work with watchOS and tvOS made by Apple...

[frizlab]

> Is the feature I need available for this Linux device?

If it’s in Foundation, yes. Swift 6 on Apple OSes now (since a while ago actually) uses the same open-source foundation as Linux. If it’s a proprietary framework (e.g. TabularData), no. It’s simple.

For the rest, almost all Swift packages developed by Apple are fully compatible with Linux, and the documentation of said packages is usually explicit wrt. platform specifics, AFAIK.

[tialaramex]

What a mess. A standard library and then apparently on top of that a Core and that's where they put a Foundation, you can imagine Apple architects arguing with the elevator contractors, "No, no, the Ground floor of our building is below our Foundation, it's very straight forward..."

But although that's enough for me to want no part of it, that's not what I was gesturing at. When we dig under the "Foundation" to look at the standard library we find that contrary to your assurance what works and how it works varies from one platform to another, just Apple only care about Apple platforms and so as usual they don't think that's worth mentioning.

They do have this information, they just don't publish it on their Apple pages because they're Apple and yet they insist this counts as the Swift documentation - and that should be all the reason you need not to take such "support" seriously.

[dhosek]

Isn’t there a performance cost though with runtime binding of functions? (I’ve not looked too closely at Swift since the first couple of years when Objective C compatibility was essential, so maybe that’s less of a default than it was in the early days).

[anextio]

Runtime binding only occurs for Objective-C interop.

Swift functions are bound at compile time when statically known. Dynamic dispatch is done through vtables for native Swift classes, and through witness tables for protocol existentials.