I believe that this long game of Swift being "good for everything" but "better for Apple platforms" will be detrimental to the language. This does not help the language nor seems to bring more people to the ecosystem.
Competitors seems to have a combination of:
- Being more open-source
- Have more contributors
- Have a narrower scope
Maybe they should consider open sourcing all the tooling (like Xcode) otherwise the gap will only grow over time when compared to other languages.
Apple: here, we're open-sourcing this previously closed-source Apple-specific thing that made Swift better on Apple platforms. We're moving the Apple stuff into a plugin so Windows and Linux can be equal peers to Apple in the new system. We've implemented preliminary support for Windows & Linux and plan to continue work to bring them up to parity.
Hacker News: I believe that this long game of Swift being "good for everything" but "better for Apple platforms" will be detrimental to the language. This does not help the language nor seems to bring more people to the ecosystem.
Like, what more do you want from them? For them to only open-source Swift Build once they've fully implemented complete parity for Windows and Linux? In the years you'd be waiting for full parity, we'd still see this same kind of comment on every story about swift, asking when they're going to open source a production-level build system.
Swift announced Linux support in 2015 when it went open source. Aspects of parity have taken years, and the Objective-C interop that isn't relevant outside Apple platforms but made adoption take off at all occupied a lot of early effort, but every Swift talk at FOSDEM today was about embedded or Linux server applications, or platform-agnostic C++ and Java interop. What can you possibly mean by "Mac only" or "bare minimum"?
Yeah I jumped into swift on Linux a while back having mostly used it on apple platforms and I couldn’t even tell anything was different. A few years ago I would’ve had to struggle with SwiftNIO but not nowadays. URLSession, Codable, etc. all there on Linux (not sure about Combine but Combine is stupid in the Swift 6 world IMO. Swift concurrency is better in almost every way).
Swift on Linux (except NixOS) is actually very good nowadays. There’s even a libadwaita library that feels a LOT like writing SwiftUI.
Feels like a lot of folks were turned off early on, found something else, and never bothered to try again (which is fair).
Swift Concurrency as a feature set includes async/await and async for, which solve a large part of Combine's same problem with better safety and less setup/teardown. These days Combine is still useful, specifically for multiple observers and several cases of adapting to older event publishing sources.
Foundation wasn't made to be part of the Swift project until recently. 25 years ago it was the "foundation" of Cocoa, the Mac OS X API derived from NEXTSTEP. It was an Apple platform thing explicitly—now it is remade in Swift and is part of the Swift project.
Side note, I think it was hilarious that Swift was allowed on FOSDEM. Even “free” (as in you probably don’t have to pay for a developer account to use it, *unless you want to ship some binary), Swift remains an Apple product.
You don't need an Apple developer account for Swift on server, Windows and Linux.
You need one only to ship apps on Apple platforms, but that's unrelated to Swift. It applies also to apps written in Objective-C, C/C++, and multi-platform language/frameworks like Dart/Flutter.
The Swift compiler, LLVM, Swift Standard Library, CoreDispatch, the Swift Package Manager and the Swift LLDB debugger are all FOSS and allow you to compile, debug, deploy, sell, buy and ship any binary you want under the terms of the Apache License 2.0.
Deployment of any software (unrelated to Swift) on Apple's platforms is entirely unrelated (and even then, at least on macOS you and any other user can install, sell, buy (...) any binary as desired).
Is it dying? I think it's still pretty popular for app development isn't it?
I was pretty excited to hear that Ladybird is doing a lot of stuff in Swift, because I think it's a pretty decent and fast language and I think it'd be pretty neat to see a browser written in it.
Well if you wonder you should conduct some simple research, but be prepared to have your opinion challenged. Swift ist doing very fine and much more popular than ObjC (again, if you don't believe it, invest 5 minutes into research).
What's your point? That's what Apple makes available. I'd use the C# API if that's how they provided it.
If not dominating the games on those plarforms, Unity and C# have a strong footing to say the least. Swift doesn't seem to be making very much headway on platforms where APIs are available in anything else.
Maybe that can chance. It seems like a neat language but "it's popular because apple forces you to use it" is more damning than reassuring.
The point is that they are guest languages on Apple ecosystem and need Apple tooling and languages as means being available.
I may also add that I dislike Microsoft doesn't give to the .NET ecosystem the same care for games developers as Apple does for Swift and existing OS SDKs.
As far as DirectX team is concerned, only C++ exists, and .NET team lets third party folks do the needful.
Had it not been for MonoGame, Unity would never picked C# in first place, gone were the days of Managed DirectX and XNA, when the decision came to be as Unity did their cross-platform rewrite out of OS X.
The specifics of C# are fairly irrelevant. Point is that even if swift is forced, middleware can and will just plaster over that. Even if Metal is forced, tools can plaster over that.
Apple forcing an API is not enough to sustain a language's popularity.
When the language is required for one of two mobile ecosystems, and second major desktop ecosystem, popularity is relative.
For decades C# was only relevant on Windows, outside Unity never got wide adoption among AAA studios after Unreal became free, and after their license debacle less so, Godot favors C++ and GDScript even with C# support it isn't what most folks reach for, and Microsoft keeps having an adoption (popularity) problem on UNIX culture oriented startups.
While just like Swift on Apple's ecosystem, C# is doing just fine on Microsoft culture environments.
There's a lot more buzz and activity around Swift than many other languages. It's literally up there with Rust, in terms of excitement (perhaps not quite as high). But I think if they get excitement outside of the Apple ecosystem, things should start to get super interesting.
Some are already adopting it like Ladybird browser.
If we're trading anecdotes, I'll share mine as someone's who's completely outside of Apple ecosystem and is not interested in it in the slightest: I only ever hear about Swift on HN, nowhere else. Most of my colleagues, friends and acquaintances (who is in IT, but none of whom are Apple users) don't even know it exist, while everyone has at least heard about Rust. We all live in bubbles, admit it.
Sorry to be mood killer, but I think that might be your bubble. That's a first news about Swift I've seen in a long time and I don't see a reason to try it, given alternatives. Nowhere near Rust level of presence in discussion.
You know what we want from them. If Apple wants to be accepted by the Open Source community, they can't reprise the Microsoft playbook with a smug "Think Different" twist. This is basically a beat-for-beat rerun of the C#/Dotnet situation with a different font and Corinthian leather.
The internet at-large is sick and tired of tending to Apple's scraps at their obscure whims. If you are a developer that isn't already implicated to use Swift for iOS development, you'd be wasting your time doing Cupertino's work bringing up their language for them. They do not care, and only want to exploit your time and productivity like they do with the App Store. Much like C#, this is a scenario where everyone but the main benefactor will be thrown under the bus.
They don't embrace Open Source, that's the problem. I don't even have to invoke the Halloween Documents to erode faith in FAANG as an Open Source steward, half this thread retched at the idea of using Swift out of principle.
Apple is welcome to head down the same road they're going if they think it's working out for Swift. Developers aren't going to magically warm to it any more than they trusted C# unless Apple makes some unprecedented change in their attitude towards Open Source. The world doesn't owe them shit.
Go ahead. Free Software has no obligation to satisfy the criteria of FAANG's business units, I'd actually find it quite funny to hear the litany of complaints you've compiled for a group of people that barely knows you exist.
Swift is compatible with WASM and embedded systems. It has a well-defined concurrency standard, and as a compiler, it's been tested with massive codebases worldwide.
The community is incredibly supportive (Ted Kremenek's team is super active, attending community conferences and supporting the Server Side Workgroup). They also have an open swift-evolution process that mostly works.
Xcode not being open-sourced? Not a big deal. It's an older codebase optimized for different use cases. Their approach is to break Swift down into smaller, focused components (Package Manager, LSP server, a formatter, etc.)
JetBrains didn't open-source their IDEs either, and people don't complain about it. So, it's the same story, but it's better since you don't have any historical issues like "Oracle JVM" lurking around, causing trouble for the community.
> I'm a bit confused about the "don't trust Apple" sentiment here.
Let me help you out; replace "Apple" with "Microsoft" and it will make a lot of sense suddenly.
The Open Source community has heard all this before. We've seen Sun Microsystems "generously" publish their Java spec to the public, we've seen Microsoft "give" their community C#. In the end, it's always more trouble than it's worth to cooperate with these language stewards and someone (either the business or community) ends up getting burned. I don't think many developers look at Swift with optimism that it won't end in the same Dotnet/Mono nightmare we've seen in the past.
You can lead a horse to water, but you can't make them drink. Apple has invested heavily in a language that, like C#, has a bunch of incredible features. Unfortunately they have yet to invest in the developer relations requisite for making such a language popular. Lord only knows that I'm not wasting my time to do Apple's work for them just to get a cross-platform app to compile with upstream LLVM and Clang. I could use any other language - nobody is going to commit to an ecosystem that treats them as a second-class citizen.
This has been my experience for a long time. Swift is nice but why would I waste my time working on a language that is too tied to the Apple platform even if it's open-source when we have more universal scripting languages like Python, or languages like Kotlin that are compiled but have more support (because I trust JetBrains way more than Apple at the moment), or languages that are most strict like Rust but have more momentum and safety?
They painted themselves in a corner. Apple being the best computing platform while trying to please everyone can never be a serious proposition. Either they are the best and everyone uses macOS, or we have to be so careful that any alternative is more interesting that what they propose.
> why would I waste my time working on a language that is too tied to the Apple platform
This might work the other way round: starting from people familiar with macos or ios development who want to write for other platforms.
Then the question becomes: why would a developer learn a different open source language when they can use what they already know. And sure, depending on the context they might still go with Python/Kotlin/Rust/etc.
Xcode gives me such a hard time that I started considering writing in Kotlin for macOS, just to have a normal IDE. We used to have AppCode (from JetBrains) and it was great. I wonder why Apple didn't support JetBrains, after all, it would have been to Apple's benefit.
Personally, I never liked AppCode. It was too much like Eclipse (which I also never liked).
Me not liking something, does not make it bad. It’s just not my choice. I’m glad it existed, because it probably prompted Apple to do better with Xcode. Lots of people that I respect, used it.
These days, Xcode is Big Bug Ranch. When “Delete the DerivedData folder” is S. O. P. for developers, and Apple tweaked Xcode to reduce its impact on the project, you know that they have waved a white flag to bugs.
Since Apple has moved themselves out of the server market, folks need to at least be able to target BSD/Linux server workloads, and naturally using Swift as well instead of another language is a desired option.
That crowd has the disadvantage of not being primarily interested in the other platforms, so they won't be much invested in optimizing or better matching the target capabilities.
That's the same dynamic as web devs writing React Native apps: you won't expect them to contribute extensions that manipulate local apfs metadata for instance.
So while it's nice to have them use the tools, you still need people who primarily care for non Apple platform and embrance swift for their purpose to have it expand.
Hmm Snowflake and Apple are rewriting FoundationDB in Swift. Swift has pretty good dev. ergonomics and good interop with C/C++ so it might find it's niche outside of Apple.
Can only speak for myself, but I’d love to be able to use Swift elsewhere so I don’t need to drag around a JVM and all the things that come with it (Kotlin) or have to wrestle with Rust’s sematics and disinclination towards old style imperative desktop UI development. Swift isn't perfect of course, but it’s the closest I’ve come to a language feeling “comfy”.
Kotlin Multiplatform (KMP) is neat for android devs that want to be able to code for both platforms using a toolset/language they are familiar with, but for iOS development KMP is a hassle (personal opinion). I’d rather just write the code twice. Also, I actually like Xcode. As for Android Studio, up until the more recent versions the GUI felt really clunky to me (which made working in it a bit of a slog).
Have heard of it, haven’t investigated it deeply. Looks to still have some of the less-great points of the Java ecosystem on the build side of things (gradle) which is a detractor for me.
Kotlin’s syntax is also weird/quirky in some ways.
> Either they are the best and everyone uses macOS
"Best" obviously means different things to different people, but at least by market share, macOS has never been the best. Modern Apple doesn't seem to care about market share outside of the iPhone (and even then, they are still more interested in the iPhone being a premium product than winning on market share).
I used to like macOS, 15-20 years ago, but now it's just power-user-hostile and considerably more locked down and buggy. That's not the way to be "best", by any metric I can think of.
> but now it's just power-user-hostile and considerably more locked down and buggy.
Sure, macOS has continued to secure more and more elements of the OS. They have taken a different approach than Windows and Linux, which both keep large swaths of the OS woefully insecure from third-party apps for legacy reasons. But for each and every new lock, there is a key. An incredibly secure OS that gives you the power to control what third-party apps access on your computer is the best power-user feature.
Mac OS does some amazing things for security. An immutable root OS, sandboxing, very user friendly disk encryption.
But there are certainly decisions that hold back the platform.
Their business decisions have driven most developers away from the App Store.
There is a notarization process, but it imposes a burden that many small open source projects can not bear.
They don't have an easy way to run untrusted software in a containerized way (compare Fedora toolbox). Installing things globally via homebrew or a random install script is still the way to go.
When Apple secured the OS from third party, they also purposefully closed the door on deeper third party integration to privilege their ecosystem.
macOS only being half as useful for Android users makes it harder to be the "best" for that swath of users. iPadOS being the only tablet form in the ecosystem will also distance other users etc. They just can't please everyone while locking them in a limited ecosystem.
Kotlin is compiled in the sense that it compiles down to bytecode read by the JVM. It's not machine code level but it is still compiled to a certain degree.
And Kotlin can compile natively for multiple targets including macOS and iOS without need for the JVM. There's also WASM support too.
This feels similar to C# and Microsoft's other CLR/.NET languages. Sure, they've broken away a bit and aren't exclusively used to run things on MS platforms, but still.
And Swift is even more tied to Apple, at least to my inexperienced eye. I'm not really an Apple person (Linux, Android), even though I once really enjoyed their hardware... Swift is so far down on my list of languages to look at that I probably will never get to it.
Amazing that you comment that on an announcement that is one large effort of many that Apple have been doing to build an open-source ecosystem over many years...
> This feels similar to C# and Microsoft's other CLR/.NET languages. Sure, they've broken away a bit and aren't exclusively used to run things on MS platforms, but still.
A wrong and quite outdated statement. You can develop and run C# on Linux only using open source tooling perfectly fine. I'm using Ubuntu, LazyVim with Omnisharp, dotnet CLI for scaffolding and package management. It's in the same ballpark as Go and Rust in terms of dev experience. I don't have numbers, but I guess a large fraction of new deployments is on Linux.
I don't understand what "broken away a bit" means. We use C#/.Net pretty much exclusively to build the backend of our web apps).
Most of the devs use Mac, with some Linux. Everything is run in Kubernetes (OpenShift). we use JetBrains Rider as our IDE.
C# is a very nice, very performant (faster than Go) language, the platform is mature and robust. the tooling is excellent. It gives you good garbage collection, strong type safety, etc. All the things you need to build out the logic of business applications. And it's fully open source.
I have looked at Swift. By comparison, the tooling is 10 years behind and the performance is not even close. I struggle to see what Swift brings to the table over C#.
If you want to use Visual Studio Code the 'DevKit' extension which provides essential features (language server) is proprietary and requires a Visual Studio licence regardless of platform.
Also I find since C# is an 'enterprise' language developers take the p--s in what they want to charge for, as enterprise will pay as a 'cost of doing business'. Recently FluentAssertions, a freakin test assertion library decided they wanted to charge for newer versions. You don't get that in other languages like Python/Ruby etc.
The language server is part of the SDK itself. The language server integration, debugger and all the features that make VS Code a good tool to write C# in are a part of base C# extension which is MIT-licensed and has no commercial restrictions whatsoever.
The only "wart" is that "vsdbg" - debugger it ships with is closed-source because it is essentially the same debugger as in Visual Studio but extracted into a standalone cross-platform component. There is an open alternative "NetCoreDbg" used by the extension fork for VSCodium (and various DAP bridges to Neovim, Emacs, etc.).
I used C# on .NET framework (the old .NET running only on Windows) 10 years ago at work. Then I had to use it 2 years ago again, and man, did it change! ASP.NET Minimal API is absolutely awesome, as the Generic Host integrating config, logging and DI is a great too. A very mature and complete framework.
It brings everything to the table a great modern language and ecosystem needs. Even null safety.
Regarding error handling, I don't have a strong opinion yet. I think Rust has nailed it, but C# (with unchecked exceptions) didn't create any issues in the projects I worked on.
Because not having hundreds of keywords means that either you have some parts of the language that are "this has a special meaning please don't touch" (double underscores are good enough, right guys?) or "we reassigned 10 different things to the same keyword to keep the number low" (ahem, static).
I’ve spent some time looking into swift as well and was quite pleased with the overall language, it really contained some really good ideas. This makes it a bit of a shame that it is tied so closely to Apple
I doubt Apple really cares much about competing with other languages, tooling, or platforms when it comes to Swift or Xcode. They have a completely captured audience and ecosystem, and anything beyond that isn’t even a "best effort" — it's more like, "You're welcome to see if it works for you, but don’t bother us if it doesn't."
I don't know about Xcode, but Swift is open source with an active community so if it doesn't work for you then you can definitely bother the Swift Open-Source project with a pull request or a proposal for a language or tooling improvement. You can also have a discussion on the forums or in the bug tracker with fellow contributors.
You can also make the change in your own fork and use that.
This is exactly how for example the Rust or Python open source projects work. And like those projects you can look at the Swift proposals and code to see _numerous_ cases where people did bother to bother the team with change requests or directly contributed to those improvements.
a) If Apple didn't care about competition they wouldn't have created Swift.
b) They don't have a captured ecosystem at all. You can write iOS/macOS apps using Flutter, React Native etc. All of which are detrimental to Apple because they force apps to adopt a lowest common denominator approach and not use the latest Apple technologies.
> All of which are detrimental to Apple because they force apps to adopt a lowest common denominator approach and not use the latest Apple technologies.
I think you might have this backwards. What you say used to be true back in the days of phonegap, where the hardware was abstracted far away, but all of the frameworks you mention provide pretty easy paths to access new APIs and hardware features. But companies that are drawn to cross-platform tooling already want a uniform experience across devices - and that's why you get the lowest common denominator being used with tools like react native.
Ehhh, I don't know, whoever's designing and implementing Swift and Xcode etc clearly genuinely care on a personal level about quality. I get that there's going to be taste involved but the amount of thought and effort that's gone into the ecosystem is very high.
Whatever Apple's goal is being, the result is written on the wall: Swift's brand is strongly associated to Apple ecosystem for most programmers. They won't adopt it unless they're already targeting Apple's platforms.
See C#/.Net Core. It runs on Linux for so many years. But people still treat it as "Microsoft's thing".
Frankly, it makes me feel bad for Chris Lattner. This guy's been worked his ass off to create a genuinely new language with all the bells and whistles he can fit, and his employer is the one that held him back the most. It took years for Foundation framework to get serious multiplatform commitment, and unless something changes drastically I think that's going to be the sour taste that developers have in their mouths.
Apple in general seems to only understand software development through the lens of oppressive control. Maybe that's a security imperative for consumer products, but in Open Source it is an outright suicide pact. You have to treat every major platform as a first-class target, otherwise the major platforms will all switch to something better.
Competitors seems to have a combination of: - Being more open-source - Have more contributors - Have a narrower scope
Maybe they should consider open sourcing all the tooling (like Xcode) otherwise the gap will only grow over time when compared to other languages.