This... is actually pretty great to have. Very cool.
That said... It really just makes me bummed about the lack of good support for container and sandboxing technology on macOS. I know, totally different thing. But still, we'll probably never have a "native" Docker/Podman/etc. on macOS, and things like the Bazel or Nix sandbox are significantly less effective on macOS due to there just being less kernel APIs for isolating resources. e.g. There are no network namespaces. I get why, but it's surprising how limiting not having network namespaces is once you have used a platform that has an equivalent to this. For Nix it's really tricky since a lot of things need at least a working localhost inside the sandbox. I am sure increasing the surface area of XNU is not a serious consideration, for good reasons, but it's a bit of a shame.
sandbox the cli util included with macOS allows you to conure basically anything
Then, using docker/orbstack, I’ve created an easy chroot shell on steroids. It mounts the current dir to a container. Great for development or sandboxing
There are Windows containers and I don't think that most developers using Docker on Windows are even aware of them.
IMO it's kind of good to have Linux as a unified container platform. It's easy to run Linux application in Windows or macOS VM. It's hard form the licensing perspective to run Windows VM and it's very hard to run macOS VM.
I think it's just that Windows Containers are a lot unlike Linux Docker containers; they're not useless, but they're very different. I don't think Darwin containers have to be so different from Linux containers, not the least of which because Darwin is UNIX. It would be a lot more like if you ported Docker to run natively on BSD than Windows, since it basically is that.
An easy solution to the licensing issue is just having an open source userland that you can use, which Darwin sorta does. That said, since XNU syscalls are not stable, there is some awkwardness here. Either they would need to be made stable somehow (e.g. by providing something like personalities, where different processes get different syscall behavior) or the runtime would need to drop libc/base libraries in from the sky and containers would just need to assume they're available at a specific location. Either thing seems quite viable if Apple wanted to do it, IMO.
I dont love the idea of Apple eco system for server side development. I trust them to try make a great eco system for their own OSes based on their self interrest. I do not trust them to drive and maintain a server side eco system, because I don’t see how the effort is directly linked to making money.
That said, Swift and SwiftUI is super nice, so I know they know how to make great software for their OS-es. Almost. Once they fix XCode.
IMHO it's the best language I've used a significant amount, without a close second (where my sample size of extant languages is Swift, ObjC, Python, JS, TS, PHP, Java, Kotlin, C#, Haskell).
It's the only language I've used where I have never asked "but why?". Every language feature and stdlib API just does what it says and acts in the way that makes the most sense. You're basically forced to handle every case (null, any type of error, switch cases, etc). It's highly dynamic, yet code tends to stay understandable. Apple is thoughtful about naming things and designing APIs. It's the only language I almost never need to write utility functions for - generally the type you're operating on has a method to do what you want, which you can easily discover with auto completion. Strings are sequences of graphemes, not code units or code points, and their API reflects this.
It's not perfect, but nothing else comes as close. One of the most prominent complaints - compile time explosion - really only happens in contrived examples where you're using a bunch of literals in one expression, which isn't realistic.
However, it's stuck in a single ecosystem. And let's not talk about some of the newer frameworks. Oh, and Xcode is a joke.
And the typesystem is built in a way that it does not really help you due to typechecking being so slow.
Make an error/begin refactoring in ocaml: just follow the typechecker until you’re done.
Make an error/begin refactoring in swift: you plan ahead because the typechecker will crash with a timeout or give you non-root-cause errors.
Yesterday I changed the signature of a method, and instead of complaining at the callsites I got a ”ambiguous method” error for a built in SwiftUI view modifier. Kinda hard to track down if you’re not completely aware of the changes you’ve made
This falls under the "new frameworks" category I glossed over. SwiftUI, SwiftData, etc, are failures in my opinion. SwiftUI in particular abuses the type system. In your own code the type system is very helpful.
Yep. If you’re writing good code that avoids common smells things are perfectly speedy. Usually if you’re making the compiler grumpy you should be sitting back and reconsidering your design anyway.
XCode (and other tooling) being a joke and compile issues make it tough for me to think of it as my favorite, but the language itself is definitely nice to work with.
The compile time issues I have mainly come from TCA, but I still see them from time to time in normal code.
I have a few other syntax gripes, but largely see it as competitive with Typescript and Rust in terms of how nice it is to use. TS and Rust blow it out of the water with tooling, though.
Not my experience at all. I develop daily in Xcode and compile times are excellent. One can't really compare between TS/JS interpreted languages and machine code generation. Apples and oranges. Swift compiler is fast, faster than C++. In my experience the Golang compiler is the fastest but the language is much simpler. Rust compiler is slower than C++.
As a side note, for some reason people like to bitch Xcode just out of habit perhaps. It's a kind of base line statement. Not my experience either. It's an excellent IDE for the current year of 2025. Helps me a lot and I build end-user facing apps, the proof is the love that users give to my apps. In other words, I have skin in the game.
Xcode regularly crashes and/or ends up leaving garbage in its garbage xml files. The un-reviewable xml stuff is also a garbage of its own making. The build system is intractable. Xcode does not lend itself to segregating builds from dependency fetching, i.e. do all the internet things on one machine and donthe building on a different one. The debugger cocks out at least weekly. Sure, you can make goods app with it. We’ve been making good apps with less for decades too. Other platforms/editors are not as painful, it is as simple as that.
The compile times are ok, but slower than Rust and C++ in my personal experience. What I was referring to with "compile time issues" is the occasional type resolution issue that hangs the compiler for seconds/minutes, and requires some refactoring to mitigate. This does happen a lot less with Swift 6 than it did with 1-4 though.
I've used a lot of IDEs, and spend plenty of time using XCode. It's the worst I've used by far, and the only one where I feel it necessary to edit the majority of code in a separate editor.
Writing apps that people love makes you a good developer, but says little about the tools you use.
I'm optimistic about Rust and look forward to trying it.
TS to me is just an awkward patch on top of JS. It's really great! But only compared to JS. The mental model of its type system is difficult to form completely.
It might be due to the convenience of familiarity, but I disagree about TS. If you forbid any/unknown it doesn't feel at all like an awkward patch, and as far as I can tell the type system is much more powerful than Swift's.
The main problem with TS is that your types are compile-time. You can have 0 uses of any/unknown, but you can still stuff a number into a string at runtime without any issues until it blows up.
I know you should have defined validators for every single external API, library and database, but at some level it feels silly to do all of this extra work.
Of course, but that comes with the territory. I just think it's really impressive how far TS has come, and doesn't feel like an "awkward patch over javascript" at all these days.
In new projects, I've found that it's now very rare to come across a library that doesn't provide typings, or violates the interface.
It is not stuck on a single ecosystem and VSCode has an extension to use Swift in it. The Linux ecosystem is actually getting quite interesting tbh, and they even support embedded targets!
"Liking" is irrelevant to me. I do use it thoroughly though – I have written Linux containers (web apps) as well as native macOS and iOS apps. I am end-product creator and want my ideas to become end-user products and see the light of day. Delivery is everything.
Swift offers convincing ease for writing abstractions that underpin the app layer. You can be as clever or as simple as you wish, it's up to you. I prefer to keep it simple.
The other huge win for me is its ability to combine multiple language codebases at the SOURCE CODE LEVEL under a single project umbrella.
Many of my projects use a mix of:
- Swift
- C++
- C
The whole thing gets compiled from a bunch of source code folders with a single command. No wrappers or binary wrangling, simply call C++/C from Swift.
Compile time is really fast for me with Swift 6 onwards.
I use Xcode (and I am fine with it, it compiles really fast in year 2025) or VSCode (with Swift plugin) — both achieve the same thing in my experience.
Want to build a Docker Linux container? Very simple too. I fine tune and debug the project on dev macOS machine then use a Docker Linux container to build it for Linux (on a Mac or Linux) and deploy the binary. It's a single binary file by default, all libs inside. Then copy it to my NAS or deploy to remote Linux server and enjoy the speed.
Low friction, easy abstraction, fast delivery and binary machine code executable. That's what speaks to me.
Personally I initially come from the « Apple world » but now I use Swift on the server and it’s a joy. By far my favorite language ever. I even wrote a tool to be able to run Swift scripts that have non-system dependencies![1]
I find it intriguing but have so far been unwilling to convince myself to give it a try on anything. It has a lot of good ideas, but I think Apple needs to relinquish more control over its future and direction for me to feel like a future plan change at Apple won't jeopardize its usefulness outside of Apple platforms. Presumably the reason why they want to keep it under their own organization is specifically so they can control their own destiny better, since Apple is heavily using Swift themselves; totally understandable, but trusting it for something that needs to be crossplatform in the long term seems potentially unwise.
It's not fool-proof either. Microsoft started the .NET Foundation, but that hasn't stopped them from causing drama by pushing self-serving decisions from the top-down. I don't really fear the same sort of behavior from Apple very much, but I definitely worry that Apple might eventually lose interest on the cross platform part for sure.
This is especially troubling because it is a fairly innovative language. If you get trapped on an unmaintained port of it, moving off of it seems like it might be hard. It's got a lot of clever ideas I haven't seen elsewhere.
Swift evolution and governance is open and publicly documented. It will always be dominated by Apple engineers, but the evolution of the language is largely orthogonal to Apple's OS releases.
I'm not sure how much of the standard library is available on the server side.
However, I it's more about the engineers' interest than it is Apple's, and in that respect, the Swift ecosystem has been evolving constantly, e.g., the Swift toolchain was entirely divested from Xcode a month ago.
I can't speak for the .NET ecosystem, but your fears are unfounded. Whether Swift is useful in a cross-platform context is another question, however.
Orthogonal? Odd thing to say given Swift's evolution and release timeline are entirely constrained by Apple's OS release schedule. We're currently going through the spike in evolution proposals by Apple engineers in preparation for the branching of Swift 6.2 next month before WWDC in June.
As for server side, the standard library is entirely available on other platforms, with a subset available for embedded Swift. However, it's fairly limited when compared to something like Python, and cross platform support for the other libraries like swift-foundation or SwiftNIO is more limited (IIRC SwiftNIO still doesn't support Windows properly).
I'm not sure what you're talking about with the tool chain. Apple has been producing toolchains that can run on macOS outside Xcode for years. Do you mean integration of swiftly? I think that just brought swiftly support to macOS for the first time.
Ultimately I agree with jchw; Swift would be in a much better position if it wasn't controlled by Apple's process. Features could get more than a few months work at a time. We could have dedicated teams for maintenance intensive parts of the compiler, like the type checker or the diagnostics engine, rather than a single person, or a few people that switch between focus areas.
Firstly, I believe the fears are founded; these fears are a good starting point, since learning and adopting a programming language is a big investment, and you should be careful when making big investments. To say they're unfounded suggests that they have no basis. Disagreed.
Secondly, I don't really feel like this sort of analysis does much to assuage fears, as Apple's business strategy is always going to take priority over what its engineers individually want. Apple of today doesn't have any obvious reason to just go and axe cross-platform Swift, but if that ever changes in the future, they could do it overnight, like it was never there. Could do it tomorrow. It's not much different than an employee getting laid off abruptly.
This is especially true because in truth Apple doesn't really have a strong incentive in the grand scheme of things to support Swift on non-Apple platforms. Even if they use it in this way today, it's certainly not core to their business, and it costs them to maintain, costs that they may eventually decide benefits their competitors more than it helps them.
There's no exact heuristic here, either. Go is entirely controlled by Google and does just fine, though it has the advantage of no conflict-of-interest regarding platforms. Nobody writing Go on Linux servers really has much reason to be concerned about its future; Partly because Google has quite a lot of Go running on Linux today, and given how long it took them to e.g. transition to Python 3 internally, I can just about guarantee you that if Go died it would probably not be abrupt. Even if it was, because of the massive amount of external stakeholders there are, it would quickly be picked up by some of the large orgs that have adopted it, like Uber or Digital Ocean. The risk analysis with Go is solid: Google has no particular conflict of interest here, as they don't control the platforms that Go is primarily used on; Google has business reasons to not abruptly discontinue it and especially not on Linux servers; there are multiple massive stakeholders with a lot of skin in the game who could pick up the pieces if they called it quits.
I believe Apple could also get to that point with Swift, but they might need a different route to get there, as Swift is still largely seen as "That Apple Thing" for now, by a lot of outsiders, and that's why I think they need to cede some control. Even if they did fund a Swift foundation, they could still remain substantially in control of the language; but at least having other stakeholders with skin in the game having a seat at the table would do a lot to assuage fears about Swift's future and decouple aspects of governance from Apple in ways that would probably ultimately benefit Swift for everyone.
P.S.: And I'm not singling Apple out here, because I think any rational company has to make tough decisions sometimes, but it's obvious from their past that they definitely don't fear changes of plan. Look all the way back to OpenDoc. Being willing to make bold changes of plan feels like it's a part of their company DNA.
It's a great language for Application-level software on a single platform (could be Linux).
It has some challenges that it needs to solve to do great as a cross platform "general-purpose" programming language.
It's paradoxically high level with its syntax and ergonomics but is tied down to the same cross platform headaches like in low level languages (e.g. cpp). Linking across cross platforms requires lots of careful thought and testing. Unlike cpp, it's not super portable. It requires a hefty 30 MB runtime for some features of the language to work. Try static executable hello world.
That being said, it's possible. You can build cross platform applications with Swift, but you'd still have some of the same kinds of portability issues like in cpp but with nicer syntax and ergonomics.
Yes. I speculate they are actually working on this internally but I have no proof (they must have thought about it!). All the advances in the virtualization they are currently doing makes me think they will eventually release a built in container technology.
I love Swift, but it has the only compiler that ever told me to rewrite my code because it cannot analyze it in a reasonable length of time.
It's a contender for a "best idea and worst execution" award for programming languages in the last 20 years.
I'd like to think that if things went just a little bit better it would have beed the ideal programming language for anything cloud / backend related.
This... is actually pretty great to have. Very cool.
That said... It really just makes me bummed about the lack of good support for container and sandboxing technology on macOS. I know, totally different thing. But still, we'll probably never have a "native" Docker/Podman/etc. on macOS, and things like the Bazel or Nix sandbox are significantly less effective on macOS due to there just being less kernel APIs for isolating resources. e.g. There are no network namespaces. I get why, but it's surprising how limiting not having network namespaces is once you have used a platform that has an equivalent to this. For Nix it's really tricky since a lot of things need at least a working localhost inside the sandbox. I am sure increasing the surface area of XNU is not a serious consideration, for good reasons, but it's a bit of a shame.
sandbox the cli util included with macOS allows you to conure basically anything
Then, using docker/orbstack, I’ve created an easy chroot shell on steroids. It mounts the current dir to a container. Great for development or sandboxing
https://github.com/jrz/container-shell
There are Windows containers and I don't think that most developers using Docker on Windows are even aware of them.
IMO it's kind of good to have Linux as a unified container platform. It's easy to run Linux application in Windows or macOS VM. It's hard form the licensing perspective to run Windows VM and it's very hard to run macOS VM.
I think it's just that Windows Containers are a lot unlike Linux Docker containers; they're not useless, but they're very different. I don't think Darwin containers have to be so different from Linux containers, not the least of which because Darwin is UNIX. It would be a lot more like if you ported Docker to run natively on BSD than Windows, since it basically is that.
An easy solution to the licensing issue is just having an open source userland that you can use, which Darwin sorta does. That said, since XNU syscalls are not stable, there is some awkwardness here. Either they would need to be made stable somehow (e.g. by providing something like personalities, where different processes get different syscall behavior) or the runtime would need to drop libc/base libraries in from the sky and containers would just need to assume they're available at a specific location. Either thing seems quite viable if Apple wanted to do it, IMO.
We are very much aware, they are commonly used on deployments used in Windows Server.
Typical examples, Sitecore, Sharepoint, Dynamics, Optimizelly, COM services, SQL Server.
I dont love the idea of Apple eco system for server side development. I trust them to try make a great eco system for their own OSes based on their self interrest. I do not trust them to drive and maintain a server side eco system, because I don’t see how the effort is directly linked to making money.
That said, Swift and SwiftUI is super nice, so I know they know how to make great software for their OS-es. Almost. Once they fix XCode.
What’s the general sentiment on Swift?
It’s 11-years old and I don’t see it talked about much on HN (except for discussion on Apple libraries & bugs).
Do people like it as a language, and why?
IMHO it's the best language I've used a significant amount, without a close second (where my sample size of extant languages is Swift, ObjC, Python, JS, TS, PHP, Java, Kotlin, C#, Haskell).
It's the only language I've used where I have never asked "but why?". Every language feature and stdlib API just does what it says and acts in the way that makes the most sense. You're basically forced to handle every case (null, any type of error, switch cases, etc). It's highly dynamic, yet code tends to stay understandable. Apple is thoughtful about naming things and designing APIs. It's the only language I almost never need to write utility functions for - generally the type you're operating on has a method to do what you want, which you can easily discover with auto completion. Strings are sequences of graphemes, not code units or code points, and their API reflects this.
It's not perfect, but nothing else comes as close. One of the most prominent complaints - compile time explosion - really only happens in contrived examples where you're using a bunch of literals in one expression, which isn't realistic.
However, it's stuck in a single ecosystem. And let's not talk about some of the newer frameworks. Oh, and Xcode is a joke.
And the typesystem is built in a way that it does not really help you due to typechecking being so slow. Make an error/begin refactoring in ocaml: just follow the typechecker until you’re done. Make an error/begin refactoring in swift: you plan ahead because the typechecker will crash with a timeout or give you non-root-cause errors.
Yesterday I changed the signature of a method, and instead of complaining at the callsites I got a ”ambiguous method” error for a built in SwiftUI view modifier. Kinda hard to track down if you’re not completely aware of the changes you’ve made
This falls under the "new frameworks" category I glossed over. SwiftUI, SwiftData, etc, are failures in my opinion. SwiftUI in particular abuses the type system. In your own code the type system is very helpful.
If just about every big new framework in a language is a failure, what does that say about the language?
If you do a lot with combine publishers, then you might also have a hard time with the type system
Yep. If you’re writing good code that avoids common smells things are perfectly speedy. Usually if you’re making the compiler grumpy you should be sitting back and reconsidering your design anyway.
It has nothing to do with code quality: https://danielchasehooper.com/posts/why-swift-is-slow/
Hmm...getting strong "you're holding it wrong" vibes here.
XCode (and other tooling) being a joke and compile issues make it tough for me to think of it as my favorite, but the language itself is definitely nice to work with.
The compile time issues I have mainly come from TCA, but I still see them from time to time in normal code.
I have a few other syntax gripes, but largely see it as competitive with Typescript and Rust in terms of how nice it is to use. TS and Rust blow it out of the water with tooling, though.
Not my experience at all. I develop daily in Xcode and compile times are excellent. One can't really compare between TS/JS interpreted languages and machine code generation. Apples and oranges. Swift compiler is fast, faster than C++. In my experience the Golang compiler is the fastest but the language is much simpler. Rust compiler is slower than C++.
As a side note, for some reason people like to bitch Xcode just out of habit perhaps. It's a kind of base line statement. Not my experience either. It's an excellent IDE for the current year of 2025. Helps me a lot and I build end-user facing apps, the proof is the love that users give to my apps. In other words, I have skin in the game.
Xcode regularly crashes and/or ends up leaving garbage in its garbage xml files. The un-reviewable xml stuff is also a garbage of its own making. The build system is intractable. Xcode does not lend itself to segregating builds from dependency fetching, i.e. do all the internet things on one machine and donthe building on a different one. The debugger cocks out at least weekly. Sure, you can make goods app with it. We’ve been making good apps with less for decades too. Other platforms/editors are not as painful, it is as simple as that.
The compile times are ok, but slower than Rust and C++ in my personal experience. What I was referring to with "compile time issues" is the occasional type resolution issue that hangs the compiler for seconds/minutes, and requires some refactoring to mitigate. This does happen a lot less with Swift 6 than it did with 1-4 though.
I've used a lot of IDEs, and spend plenty of time using XCode. It's the worst I've used by far, and the only one where I feel it necessary to edit the majority of code in a separate editor.
Writing apps that people love makes you a good developer, but says little about the tools you use.
I'm optimistic about Rust and look forward to trying it.
TS to me is just an awkward patch on top of JS. It's really great! But only compared to JS. The mental model of its type system is difficult to form completely.
But yes, Swift's tooling doesn't compare.
It might be due to the convenience of familiarity, but I disagree about TS. If you forbid any/unknown it doesn't feel at all like an awkward patch, and as far as I can tell the type system is much more powerful than Swift's.
The main problem with TS is that your types are compile-time. You can have 0 uses of any/unknown, but you can still stuff a number into a string at runtime without any issues until it blows up.
I know you should have defined validators for every single external API, library and database, but at some level it feels silly to do all of this extra work.
Of course, but that comes with the territory. I just think it's really impressive how far TS has come, and doesn't feel like an "awkward patch over javascript" at all these days.
In new projects, I've found that it's now very rare to come across a library that doesn't provide typings, or violates the interface.
> It's the only language I've used where I have never asked "but why?"
* But why I cannot use @Published and other decorators in protocol declarations?
* But why must generics always be a pain in the ass, compared to .net, even in the most recent versions? 5 ways to do things, never the one you need
* But why is the person that designed the if case let value = .variable syntax not flagellated in a public square?
* But why is modern concurrency and SPM so undocumented?
My two mains "why tf is this not built-in" are:
"Why are tuple not Hashable ?!"
Which means that you cannot have a tuple of Int `(1, 1)` as a key in a dict, and you have to make a struct that implement Hashable instead.
And
"Why do they not have a `.sum()` and I have to do `.reduce(0, +)` every time instead."
Or implement it yourself
I think tuples will be (soon-ish) Hashable but cannot as of now because they want to do it right and need something before they can do it.
Why do you feel the stdlib needs a .sum() if using .reduce() is so simple?
It is not stuck on a single ecosystem and VSCode has an extension to use Swift in it. The Linux ecosystem is actually getting quite interesting tbh, and they even support embedded targets!
"Liking" is irrelevant to me. I do use it thoroughly though – I have written Linux containers (web apps) as well as native macOS and iOS apps. I am end-product creator and want my ideas to become end-user products and see the light of day. Delivery is everything.
Swift offers convincing ease for writing abstractions that underpin the app layer. You can be as clever or as simple as you wish, it's up to you. I prefer to keep it simple.
The other huge win for me is its ability to combine multiple language codebases at the SOURCE CODE LEVEL under a single project umbrella. Many of my projects use a mix of:
The whole thing gets compiled from a bunch of source code folders with a single command. No wrappers or binary wrangling, simply call C++/C from Swift.Compile time is really fast for me with Swift 6 onwards.
I use Xcode (and I am fine with it, it compiles really fast in year 2025) or VSCode (with Swift plugin) — both achieve the same thing in my experience.
Want to build a Docker Linux container? Very simple too. I fine tune and debug the project on dev macOS machine then use a Docker Linux container to build it for Linux (on a Mac or Linux) and deploy the binary. It's a single binary file by default, all libs inside. Then copy it to my NAS or deploy to remote Linux server and enjoy the speed.
Low friction, easy abstraction, fast delivery and binary machine code executable. That's what speaks to me.
Personally I initially come from the « Apple world » but now I use Swift on the server and it’s a joy. By far my favorite language ever. I even wrote a tool to be able to run Swift scripts that have non-system dependencies![1]
[1] https://github.com/xcode-actions/swift-sh
PS: Yes, it’s a fork, but at the point I’m at there is nothing left from the original implementation. Even the way the program works is different.
Probably almost every developer working professionally on iOS uses Swift at this point.
I, personally, don't like it and I prefer Objective C. But I'm not professional iOS developer, so take my words with grain of salt.
It is a great language for developers on Apple ecosystem, for portable code not so much.
It stands with .NET on Windows, or Kotlin on Android, however outside Apple is at tooling level of .NET Core early days, think .NET Core 2.0.
Mostly usable for Apple shops that need to deploy into Linux servers for their app backends, and share code.
I find it intriguing but have so far been unwilling to convince myself to give it a try on anything. It has a lot of good ideas, but I think Apple needs to relinquish more control over its future and direction for me to feel like a future plan change at Apple won't jeopardize its usefulness outside of Apple platforms. Presumably the reason why they want to keep it under their own organization is specifically so they can control their own destiny better, since Apple is heavily using Swift themselves; totally understandable, but trusting it for something that needs to be crossplatform in the long term seems potentially unwise.
It's not fool-proof either. Microsoft started the .NET Foundation, but that hasn't stopped them from causing drama by pushing self-serving decisions from the top-down. I don't really fear the same sort of behavior from Apple very much, but I definitely worry that Apple might eventually lose interest on the cross platform part for sure.
This is especially troubling because it is a fairly innovative language. If you get trapped on an unmaintained port of it, moving off of it seems like it might be hard. It's got a lot of clever ideas I haven't seen elsewhere.
Swift evolution and governance is open and publicly documented. It will always be dominated by Apple engineers, but the evolution of the language is largely orthogonal to Apple's OS releases.
I'm not sure how much of the standard library is available on the server side. However, I it's more about the engineers' interest than it is Apple's, and in that respect, the Swift ecosystem has been evolving constantly, e.g., the Swift toolchain was entirely divested from Xcode a month ago.
I can't speak for the .NET ecosystem, but your fears are unfounded. Whether Swift is useful in a cross-platform context is another question, however.
Orthogonal? Odd thing to say given Swift's evolution and release timeline are entirely constrained by Apple's OS release schedule. We're currently going through the spike in evolution proposals by Apple engineers in preparation for the branching of Swift 6.2 next month before WWDC in June.
As for server side, the standard library is entirely available on other platforms, with a subset available for embedded Swift. However, it's fairly limited when compared to something like Python, and cross platform support for the other libraries like swift-foundation or SwiftNIO is more limited (IIRC SwiftNIO still doesn't support Windows properly).
I'm not sure what you're talking about with the tool chain. Apple has been producing toolchains that can run on macOS outside Xcode for years. Do you mean integration of swiftly? I think that just brought swiftly support to macOS for the first time.
Ultimately I agree with jchw; Swift would be in a much better position if it wasn't controlled by Apple's process. Features could get more than a few months work at a time. We could have dedicated teams for maintenance intensive parts of the compiler, like the type checker or the diagnostics engine, rather than a single person, or a few people that switch between focus areas.
Firstly, I believe the fears are founded; these fears are a good starting point, since learning and adopting a programming language is a big investment, and you should be careful when making big investments. To say they're unfounded suggests that they have no basis. Disagreed.
Secondly, I don't really feel like this sort of analysis does much to assuage fears, as Apple's business strategy is always going to take priority over what its engineers individually want. Apple of today doesn't have any obvious reason to just go and axe cross-platform Swift, but if that ever changes in the future, they could do it overnight, like it was never there. Could do it tomorrow. It's not much different than an employee getting laid off abruptly.
This is especially true because in truth Apple doesn't really have a strong incentive in the grand scheme of things to support Swift on non-Apple platforms. Even if they use it in this way today, it's certainly not core to their business, and it costs them to maintain, costs that they may eventually decide benefits their competitors more than it helps them.
There's no exact heuristic here, either. Go is entirely controlled by Google and does just fine, though it has the advantage of no conflict-of-interest regarding platforms. Nobody writing Go on Linux servers really has much reason to be concerned about its future; Partly because Google has quite a lot of Go running on Linux today, and given how long it took them to e.g. transition to Python 3 internally, I can just about guarantee you that if Go died it would probably not be abrupt. Even if it was, because of the massive amount of external stakeholders there are, it would quickly be picked up by some of the large orgs that have adopted it, like Uber or Digital Ocean. The risk analysis with Go is solid: Google has no particular conflict of interest here, as they don't control the platforms that Go is primarily used on; Google has business reasons to not abruptly discontinue it and especially not on Linux servers; there are multiple massive stakeholders with a lot of skin in the game who could pick up the pieces if they called it quits.
I believe Apple could also get to that point with Swift, but they might need a different route to get there, as Swift is still largely seen as "That Apple Thing" for now, by a lot of outsiders, and that's why I think they need to cede some control. Even if they did fund a Swift foundation, they could still remain substantially in control of the language; but at least having other stakeholders with skin in the game having a seat at the table would do a lot to assuage fears about Swift's future and decouple aspects of governance from Apple in ways that would probably ultimately benefit Swift for everyone.
P.S.: And I'm not singling Apple out here, because I think any rational company has to make tough decisions sometimes, but it's obvious from their past that they definitely don't fear changes of plan. Look all the way back to OpenDoc. Being willing to make bold changes of plan feels like it's a part of their company DNA.
It's a great language for Application-level software on a single platform (could be Linux).
It has some challenges that it needs to solve to do great as a cross platform "general-purpose" programming language.
It's paradoxically high level with its syntax and ergonomics but is tied down to the same cross platform headaches like in low level languages (e.g. cpp). Linking across cross platforms requires lots of careful thought and testing. Unlike cpp, it's not super portable. It requires a hefty 30 MB runtime for some features of the language to work. Try static executable hello world.
That being said, it's possible. You can build cross platform applications with Swift, but you'd still have some of the same kinds of portability issues like in cpp but with nicer syntax and ergonomics.
Its popularity is steadily dropping over time since more and more people are moving to cross platform frameworks like Flutter.
> Container images are the standard way to package cloud software today.
Shame there's no macos native container system or way to make one (my understanding is the kernel isolation primitives are not there)
Yes. I speculate they are actually working on this internally but I have no proof (they must have thought about it!). All the advances in the virtualization they are currently doing makes me think they will eventually release a built in container technology.
Interesting! Does it run on macOS hosts only, or does it install any macOS inside the container?