Do people use Swift outside of Apple iOS/macOS development in real life? Especially on platforms like Windows/Linux/*BSD?
It’s also weird to include Java and Swift in that list considering both afaik are maintained by a separate foundation. Java from Sun is even predominantly basically OpenJDK with some remaining proprietary Sun / Oracle bits but it’s the reference open source implementation used by most everyone.
Note that Oracle contributes around 90% of the work to OpenJDK. If they decided to stop working on it, there would be a big gap to fill.
I’d say though that Oracle is highly unlikely to stop working on Java and Google is still invested in the JDK even though they’re trying to shift new code in this space towards Kotlin (another “corp owned” language)
For a significant portion of time Python was funded by Google, Meta and Facebook and maybe some other corps.
Zig doesn’t have any serious adoption in the industry yet but if/when it does I’d expect corps to be hiring the language devs.
JS is a consortium but it’s filled primarily with Google and Apple engineers.
Same goes for C/C++ lot of Apple, MS and Google engineers.
Elixir I’m not sure about. Rust was largely turns out employed by Amazon until the most recent culling.
It’s not surprising. This is technically difficult work and if the language is important to a corp they’ll hire the maintainers. There needs to be a funding source and in the industry that typically means a for profit company paying the salary of the people moving things forward. Indeed - it’s one of the things Rust is struggling with for now.
Rust, Julia, Typescript on the other hand are governed by Corps. They are not community projects.
Elixir is BDFL (good one) last I checked. Dont know if they became a company or foundation.
Zig is for all purposes a good example of community governed project. Itcs in production at Bun and TigerBeetle. But also, its not yet production ready (v1.0). So their current trend make sense.
But I could've been wrong with JS and C. Not sure about their governance now that I think about it.
Rust is explicitly a community project having been born out of a non-profit, and if you’re discounting corp-funded but community driven that’s definitely Rust. If not, please indicate the corp that’s driving Rust.
Zig is a BDFL project like Python was (not sure how it is these days) - community contributes sure, but Andrew makes the big calls and directional changes.
Non-profit doesn't mean community project. Rust foundation is a non-profit 501-c(6). Which is a non-profit category for trade unions and stuff. It's not a charity categorization. It's run by corporate members and works only for the members which are - surprise corporates. A community member like you or me doesn't have any say (Unless you have $325k per year to pay) - https://rustfoundation.org/get-involved/. This is the same case with Linux foundation as well. It's NOT a community project. The only difference is, Linus has more say cos trademark is on him.
PSF and Zig foundation are charity / commuinty projects cos they are non-profit 501 c(3). It's categorised as public charity or for the good of people. You and I can have more say in it. NOT THE CASE WITH RUST.
One can argue about that - but probably not in context of the sub-thread:
> With the single commercial party owning it ...
I would like to respectfully disagree with you there as well. The above was the context. I was replying to this which opened the conversation.
Not to mention, end users and consumers don't get a say in the corp funded projects. Everything works as long as it aligns with the goals of the corp. Not otherwise.
Most recently they dropped support for 32 bit Mac and iOS apps. But before that it was dropping support for PPC apps and 68K apps.
On the hardware side, the funniest was they dropped support for my Core 2 Duo Mac Mini and I could still install a supported version of Windows 7 on it.
They do not.
They talk a good game, but the development tools, bright and shiny, but mostly work.
Mostly, is not good enough.
While they have so much mind share in the USA they are unavoidable. But from a developer perspective they are dire
As of two years ago. I find it hard to believe they have changed
Ladybird browser team planned to start using Swift in their codebase, but it hasn't happen yet.
> Ladybird browser team planned to start using Swift in their codebase, but it hasn't happen yet.
But I think “why” remains a valid question when you could make a safe pick like Node, Python etc. I really like Swift as a language but I’d still struggle to justify using it outside of iOS.
Dead projects are
- Kitura https://github.com/Kitura/Kitura
- Perfect https://github.com/PerfectlySoft/Perfect
Don't know of large organizations using it in production, the vibe I get is that it's useful for an iOS developer who wants to deploy a small server for their product without learning Python or Javascript.
You could certainly use it at larger scale, but you have to justify giving up the big ecosystems of its competitors.
I think they were just talking about the language features, not building web services generally
Most of what makes Rust's safety powerful is that lifetime analysis is universal and highly granular. Things like no dangling references to local variables, no 'collection cycles', handling parametric code, etc. are basic features that Swift can't provide. On top of it all, the whole system is ruinously complicated compared to Rust's type system. That's the sad reality of what happens when you try to implement something so fundamental as an extra bolt-on to a language that can't properly accomidate it.
Swift is also more conducive to "old style" retain mode imperative UI frameworks like AppKit (sometimes declarative and/or immediate mode doesn't fit the bill), which has to date been a major weak point for Rust.
> a more gentle learning curve ... and generally more approachable syntax.
This is all the more reason it's not a peer. The heavyweight class Rust belongs to (which includes things like Sepples, ATS, Ada/SPARK, D) are as a rule not approachable things. All of them are serious industrial tools whose target audience are experienced professionals that prioritize extremely broad functionality and flexibility in output. What the input looks like, or the cost of learning to operate these tools is not even a consideration for this audience. Swift doesn't fit this bill. It simply compromises too much for things that this class of language isn't concerned with. People reaching for a new language in this class aren't thinking about how easy it is to learn, or even how nice it is to use. Rust abandoned ML-family syntax to babyduck C++ at massive cost to its "niceness".
On syntax, do you mean semantics? Syntactically they're both generic curly-brace algol stuff with minor differences at best. Semantically Rust is certainly more complicated.
> which has to date been a major weak point for Rust.
It's very ironic, given Rust's original purpose was to replace C++ as the implementation language for Firefox. Retained mode GUIs have unfortunately fallen by the wayside due to a number of factors, it's not just unique to Rust. If a language hasn't inherited a legacy retained mode lib, it's not likely it'll get a decent one unless it's really lucky. Unfortunate, because you're right, retained mode GUIs absolutely have their upsides and web browsers aren't a solid replacement. They're just complicated to implement, and computers are fast enough now that the much simpler immediate mode paradigm is the choice for every new framework being written. It is what it is.
As far as I know there is no clear boundary between safe and unsafe.
It's been two years since I was an iOSSwift programmer, but the concurrent/parallel facilities were quite woeful. Memory protection no nonexsistant
I do not miss it. This might be useful for porting Apple software, but do not start new projects with it.
Rust has a more explicit and strict approach to ownership/borrowing for sure, but I’d argue Swift has worked to be memory safe be default since the start, with ARC, no unchecked pointer arithmetic in normal code, etc. it’s still tightly coupled to Apple platforms, but the swiftlang teams has been hard at work changing that and I think it’s a fine language to start new projects with in 2025.
But what Swift lacked (in my day) was any support for parallelism.
They wrapped `fork` in a lot of mumbo jumbo, but it was just `fork`
May as well use C
Exclusivity is guaranteed by the compiler, and Apple has integrated tagged pointers on arm while Linux/x86 is still thinking about it.
I played around with their threads and found it was trivial to corrupt memory and crash.
Plus, most of the open source libs are one person's weekend projects, from 3 years ago...
It's a great language, but nowadays tooling/ecosystem and build systems are key to success.
Worth noting that Gradle's long list of capabilities can sometimes be as much of a liability (or at least a frustration) as it is a boon. A great many projects don't need even a fifth of its complexity.
I think I have always seen it used in a relatively "simple" way. But that might be... "relative". :)
Basically, as a result of dependencies working only with certain versions of Gradle, it's very easy for an project with moderate to high complexity to wind up in a huge tangled mess when updating anything — updating Gradle might require you to update your dependencies, but all your dependencies might not support the version of Gradle you updated to, and the errors that get thrown as a result will be generic and won't tell you as much, sending you on a goose chase. This chain of events can also be set off by upgrading a single library for some feature you need.
It also makes it a pain to read others' Gradle files since there's no agreed upon standard, with everybody doing it a little bit differently.
In contrast, in the several years after switching my Apple platform projects to Swift Package Manager and away from CocoaPods, it's been rare for either toolchain or library upgrades to cause any sort of problem, and broadly speaking there's only a single correct way to write Swift package files, which makes them easier to read and work on.
[0]: https://vapor.codes
I meant to point out that there is no apple native cloud solution where you can run swift on apple hardware.
So if your iOS app needs to talk to a backend that you want to develop and host, you need to run that backend on an OS with cloud support, like Linux, some other Unix or windows. But not macOS or some other "Apple cloud" hosting.
For reasons stated above, you might in that case choose Swift.
IBM at one point offered Swift "serverless" lambdas/cloud functions, which made me briefly hopeful that Apple could do the same, but that service was deprecated years ago, and Apple has shown no motion there.