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.
But one thing that blows my mind is that if you ever encounter an "index out of range" error, the (massive) error message that you get doesn't tell you anything about where this error occurred... no line number... no nothing...
You have a stack dump, which means you will get all the information if you symbolicate your crash report. Xcode can do it for you automatically, but some manual methods also exist.
that's not related to the symbolizer thing. It seems to just be part of the "index out of range" crash. I get the same thing without using the symbolizer.
zsh: illegal hardware instruction swift main.swift
Swift outside of Xcode is a bit rough around the edges, I think because more attention goes into making Xcode friendly. I opened Xcode, made a new playground, and hit run, the code crashes and highlights the line where the error occurred in red. Not to excuse Swift's jankyness, just saying that the kind of default experience is more an IDE-first design compared to Go's very good unix-first design.
I don't know, I write Swift on a Mac targeting macOS or iOS. I usually have Xcode open to build/run/debug and for documentation lookup, and alternate between that and VSCode for actually writing the code; worst thing about Xcode for me is the find-replace, that's probably the biggest reason I keep VSCode open.
But it is doomed to fail as a general widely adopted language unless apple makes few critical moves including open sourcing everything including XCode, providing support for 3d party IDE developers (because xcode is terrible), creating decent package manager, adopting testing as first class citizen etc.
There is just no economical sense for anyone to invest in swift until all the above (and some more) is done.
For what it's worth, they ship a solid VS Code extension and LSP. Their swift-testing package is the new open source and cross-platform successor to XCTest. The same can be said of swift-foundation as compared to Foundation.
The path they've chosen is not to open source Xcode, but to move the things Swift needs on all platforms to the Swift language project and common implementations.
Personally I think the main problem with the language, besides Apple's earned poor reputation in FOSS circles, is the compile times. In the source-stable era of the language I'm not sure how they can really be fixed to the degree I'd be happy with.
Are there any LLVM langs that have fast compile times? I think that just kinda comes with the territory of having that IR step + all the optimizations that happen at compile time to help runtime performance.
That's a good point. I had in mind that there's some regret about the combination of type inference with type-based overloads, due to the search expense it adds to what ought to be straightforward parsing of long expressions.
Yeah, I think there are definitely parts of the language design / language features that are going to contribute, but when you need to parse to IR and then compile that to machine code, it seems any features you add that are nice for the developer are going to doubly hurt compile times. You see the same with ARC in swift (or the borrow checker in Rust).
AFAIK those language features are all handled in the frontend before outputting LLVM IR. LLVM optimization, code generation, linking, etc. should all be the same regardless of the source language.
Your wishlist seems midly contradictory. Why does Apple need to open-source XCode if they also provide support for 3rd party IDEs (which they already do, btw)? Also what do you not like about cocoapods for package management?
Plenty of people make an incredible amount of money building apps in Swift, so your last sentence is just wrong.
And make it possible to run binaries on macOS/iOS etc without a mandatory subscription and US export controls. Without notarisation, anything made with Swift is practically unusable on Apple OSs
The discussion here reminds me so much of early C# days. It was being touted as open source and cross platform back then, and Microsoft even hired a top GNOME developer to port it to Linux and GNOME was going to be rewritten in C#. It was going to be amazing. Never quite panned out.
I think you might have the history mixed up a bit. The Mono project started without Microsoft's involvement (and they were probably even annoyed by it at the time).
GNOME was betting on their own Vala language, which is still a thing, but never really gained much traction.
Eventually Microsoft bought Mono during their embrace of open source.
Probably talking about Miguel de Icaza. I think his history is wrong though. I don't recall any talk of rewriting GNOME in C# - they were all about their pet language Vala.
And Miguel started Mono way before Microsoft made C# cross-platform. At that point they were antagonists.
Microsoft had a research version of the CLR called Rotor (2002) that predated Mono (2004). Rotor built for Windows, FreeBSD, and macOs, albeit with a not-very-open license.
When Mono came along, the internal position at Microsoft was surprisingly positive. There was a dev slide deck that went into Mono in some depth. And a telling slide that said it wasn't a threat because the performance wasn't competitive at the time.
I have various snapshots of the Rotor 1 and 2 sources around and they have the SSCLI license. There is a file that contains BSD licensed code (pal\rotor_pal.h).
Thank you for the follow up. You know after I posted that my thought was am I mistaking their BSD release for a BSD license, and of course I was. The memory isn’t what it used to be.
I find Xcode completion and especially doc lookup pretty good. It’s not as good as being able to jump straight into framework source code like with Android Studio but better than pretty much anything in VS Code in any language.
That is, as long as there’re no type errors in my code… once I get a little too creative in SwiftUI all bets are off.
Building Swift code for iOS without going through xcodebuild is sort of obnoxious but is possible. You do need to have a copy of Xcode installed regardless of programming language simply because the iOS SDKs aren't distributed separately.
Hence this announcement is great, since it seems to say they’re (going to?) support building GUI apps with SwiftPM and/or the newly open sourced build tool.
I feel like Swift is being held hostage by Apple. I can't get get the next version of Swift, because it's being distributed with a higher version of Xcode that only runs on an OS version I don't want to install (yet), and even if I did, I'd first have to buy a new Mac for that. That trick seems to work with enough developers to make Apple ever more rich and powerful and even more arrogant (if that's possible at all), but it doesn't work with me. As much as I appreciate Swift, I will only ever use it on my terms, not on Apple's.
But you can't expect Apple to support it as a development platform. Especially when they want you to use the latest SDKs which only work on newer machines.
You're moving the goal posts. I'm not interested in SDKs that cannot work on a given OS or CPU, I just want to update the compiler to make use of progress in the language, without being forced by Apple to buy new hardware for that, or install a different OS. You pretending these things cannot be separated looks deeply disingenuous.
> With this release, SwiftPM now has the opportunity to offer a unified build execution engine across all platforms.
this is what the big deal is. it might not achieve much on its own immediately, but this is the key to build a truly multiplatform ecosystem of libraries, tools and applications in Swift. we should expect to see more of that soon.
Apple’s software decisions over the last 15 years have created significant friction for developers trying to build on their platforms. Apple’s approach to software development has felt like it’s prioritizing business interests over the ease and flexibility that developers need to build high-quality, useful software.
Swift is a nice language. I'm glad to see it being released from the clutches of Apple. I can only imagine how large of a task this is. I hope some day to be able to use it. The last time I tried a cross-platform project with it I switched languages due to `URLSession.shared.data` (a network request) being unable to compile on Linux.
Is it really being released? Although some parts of the language and build chains are technically open source (as in, you can see the code), the project is still completely controlled by Apple at the top.
You are wrong about "some parts" - you can browse github.com/swiftlang to find out.
About control - serious question: how is this different from for example Rust, Go, Zig or Python? For each of those you can submit a change proposal through an official process and you can submit code changes through a pull request.
But also for each of those there is a non-zero chance that a smaller group of people who do governance of the project, the core team or leads or module owners, will either tell you that your proposal or code change is not appropriate or compatible with the project's goals or they will help you to merge it. That is exactly the same for Swift.
Why is Apple suddenly a dictator while every other project also has an agenda and strict rules that are being enforced?
Is the expectation to just be able to do whatever you want in a project like Swift?
Go is pretty much controlled by Google
I don't follow it closely but there was a ton of drama around AWS influence on Rust through hiring key Rust devs.
Zig has BDFL
Python had BDFL
> About control - serious question: how is this different from for example Rust, Go, Zig or Python?
You can ask Chris Lattner about how many many changes were forced through the language before they were ready, or even properly designed, because Apple needed them: https://www.youtube.com/watch?v=ovYbgbrQ-v8
Basically, if companies who created language dump it on Github and let open source community take over it is nonviable. Because who will pay for project development that these mega corps dumped on community and washed their hands off.
On the other hand if companies take ownership, provide financing, design, vision, evolution of language, compiler, libraries and ecosystem etc it is nonviable because it is dictatorship now.
Solution is to let drive by commentators to have full commit rights on open source repositories if they want to change any part of language. Anything less unacceptable.
You’re only focusing on access to source code, the comment is about leadership and decision making. Remember the OmniSharp story around VSCode from just two years ago? It’s a very high profile example of what can (and eventually will) happen with corporate-controlled projects.
Swift can’t evolve or even exist without Apple and so unless you’re Apple, then Swift is too great of a risk.
> Swift can’t evolve or even exist without Apple and so unless you’re Apple, then Swift is too great of a risk.
I'm not sure what you're saying here. It's Apache licensed so you can just fork it. It's got pretty active development and a whole lot of software developers that use it-- if Apple decides to somehow lock down the repo and stop accepting PRs, what's stopping a group of developers from just making their own branch? It's got non-Apple cross-platform GUI frameworks, good support in editors... Sure it's 100% not as good off of Apple systems but I'm not sure what they'd be expected to do MORE than open it up with an Apache license?
And OmniSharp works just fine in VSCode from what I see. What am I missing?
They have also been working on a completely open source version of the Foundation library for use on Linux and other platforms. (IIRC the URLSession type is part of Foundation, as are many core building blocks that you need for making a real application.)
Thanks for that link to the examples repo. I had just started looking into embedded Swift for an rp2350 project a couple days ago, but (being a novice in embedded hardware/microcontrollers) I got the impression from the Swift website that the device wasn't supported yet and I'd need an rp2040 instead. It looks like there's an example project for the rp2350 in that repo though, so I'm going to be playing with this tonight!
Swift is unbelievably cool but I wonder about using Swift for an embedded project as opposed to just C or with FreeRTOS for a more capable system. Is interoperability possible - as in FreeRTOS+swift?
For the most part, yes, it should be very achievable. Embedded Swift basically just produces an object file that looks like any object file from a C compiler. The objects mostly rely on very basic primitives like malloc/memcpy so it's pretty freestanding (you can turn off allocations, too). It also has very good support for importing C headers into Swift code so you can interop easily.
Probably the biggest roadbump for something like FreeRTOS is the asynchronous support though. Embedded Swift's async support is still extremely rudimentary and I didn't find much about how to extend it/attach it to other control loops. I think it only supports single-threaded execution right now as well.
> Why should it not, one of the design goals of Swift as C, Objective-C and C++ replacement was painless interop with those languages.
This is actually a very good quality. I'm exploiting that for all it's worth in a job project where I'm gradually (file by file) converting a legacy codebase from Objective-C to Swift.
Providing an exit-strategy for Objective-C is good enough reason for me to at least have a basic working knowledge of the language.
Agreed.
It's not like they didn't have enough time to fix it either.
And they seem semi-capable of creating usable UI's elsewhere.
The thing is, when it comes to applications, both Apple and Microsoft compete with their own customers; which makes a pretty solid motivation for providing shitty developer experiences.
Did something happen with Xcode? I used it around 5 years ago, and it was pretty good and fast. I don't think it had dark mode but that's not too important to me.
No refactoring tools, lack of autocomplete, having multiple targets break compilation, errors in the ui, crashes running unit tests, it freaks out when switching git branches, spm can’t handle proxy servers, never ending indexing… List goes on and on. Xcode used to be good at around version 3. Everything that came after that has been disastrous.
Meanwhile Android Studio or VS Syudio are tools which are a joy to use and are built to help you and not to be constantly on your way
Fact is Apple should do like Google and admit there are better ides out there
Yeah Xcode has its quirks but so does everything else. Nothing is perfect in this world.
What actually bothers me is Apple is now apparently trying to copy other IDEs (poorly) and making theirs worse for it.
E.g. the new commit view which is an atrocity. They had something buggy yes, but at least decent. Now they have something buggy AND with a terrible UX.
Xcode is fine as long as you skip Interface Builder and make a point to keep your SwiftUI views lightweight. For the latter my rule of thumb is to try to cap nesting in any given view at 3 levels and to break code out into new components for anything deeper, which is a good practice since readability starts declining steeply past 2-3 levels deep anyway.
It doesn’t have all the whizbang features of Jetbrains IDEs, but my experience is that those sorts of features only work correctly sometimes and can be as much of a hindrance as they are a help.
Although opinions inside Apple about Swift vary, they seem to be investing in low level Swift for embedded, kernel use, and programming the “Secure Enclave” subsystem.
They certainly have many opportunities to use it for headphones, AirTag, flash driver, etc, beyond the very believable but less embedded use in kernel/Secure Enclave.
Distro packaging for programming language ecosystems is so often hopelessly out of date. I’ve never used a distro toolchain or packages to build production software for any language Python’s age or younger.
Outside of C/C++/Fortran pretty much every project I see on Github prefers things like Rustup or Nix for toolchains to navigate around Debian/Ubuntu/RHEL’s “stability” approach.
Python, Java, C#, JavaScript, Go, Ruby all improve so substantially in 3 years time, I can’t square the advantages of using a distro package for any of them versus using at least the latest LTS from upstream. What is so great about the distro package versus upstream, that it is worth being 2-3 years behind?
Mostly I hear “stability”, but I have encountered far more frustrations dealing with 3 year old software as a developer, than I ever have dealing with 6 month old software. If I have good test coverage, a way to deterministically reproduce my build environment, reliable CI, and a way to release packages and bugfixes to my users quickly, it seems the risk & blast radius of a 6 month old toolchain is quite limited.
I imagine the only case I want an ancient toolchain is if I’m building libraries or software predominantly consumed by Debian stable or RHEL users / system package ecosystem, or I am doing some kind of high-assurance thing involving formal verification where I’m probably using a non-distro verified toolchain instead. I’ve never been too interested in either of those domains though.
And is there any actual need to use those right now? No.
I lived through the C++11 transition (which was the only actually significant improvement C++ has ever had), and as much as GCC 4.6 was enticing, it really wasn't a burden to keep supporting GCC 4.4 in stable software. Only for ground-breaking development (which takes long enough to stabilize that stable distros will have the new GCC) is it worth starting to use the new features unconditionally.
Now, C++ does have a much better source-level compatibility story than most languages (e.g. `#if ... #define constexpr /* compiler too old */`), but that just means that newer languages have no excuse for refusing to learn from its successes.
I just picked a random, notable feature (std::format) and the LTS my systems are currently on (22.04). The current Clang in universe is 14, which doesn't have a complete std::format implementation. That's one of the most popular features from a 5 year old language standard that many people are using today and yet it's still not available on a common LTS version without adding the LLVM repos.
Bringing synopsis here for those who may not click:
swiftly is a CLI tool for installing, managing, and switching between Swift toolchains, written in Swift. swiftly itself is designed to be extremely easy to install and get running, and its command interface is intended to be flexible while also being simple to use. The overall experience is inspired by and meant to feel reminiscent of the Rust toolchain manager rustup.
But people will probably mention some distro not listed and say the mainstream distro support is a farce. For some reason people have set the bar for Swift incredibly unrealistically high and there will always be something wrong it.
Your loss though. Swift is amazing. Both on MacOS and Linux.
If you actually click through, there is exactly one actual distro package there, and it is labeled "experimental". Everything else is exactly what I complained about - something that does not integrate into a real system.
That's not what I call "actually usable on non-Apple systems".
Apple probably has use cases for this and they’re bringing it into the open as a nice marketing thing. I wouldn’t count on long term support or compatibility beyond current priorities for Apple (same as their other SDKs for iOS, macOS etc).
This is great, if for no other reason that it will give people the ability to debug build issues on their own and get access to fixes without having to wait for the next Xcode release.
Reading this it’s not clear - how well integrated is swift build with swift’s tooling and language server? I know the language server has been open source for a while now. Having them be separate seems like it would create issues with duplicate code.
The article doesn't mention the differences with current swift package manager build system. The repository doesn't mention it either, just saying that swiftpm can use the new build system by adding an argument. Anybody does what does this actually changes? Does it improve something for non-Apple platforms?
“There’s a big difference between mostly dead and all dead. Mostly dead is slightly alive. With all dead, well, with all dead there’s usually only one thing you can do.”
I wish they would stop adding anything to the language and document what they have. I constantly need to reverse engineer how things work. For example, I just had to integrate AccessorySetupKit and the docs are laughable.
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.