I hope for this too. I did a personal project in Swift on Linux and found that I loved the language. However, I was greatly frustrated by the lack of libraries. For Swift to reach the mainstream, IMHO, the Swift Foundation needs to move much more of the ecosystem to platforms other than Apple's. I would vote for that even ahead of adding new features to the language.
I suspect Apple is trying to do this for straightforward reasons like wanting to remain relevant and foster community growth as to retain credibility… while also subtly trying to not encourage the use of Swift as a language for any other GUI framework/platform than Cocoa + macOS. Obviously I don’t have any evidence to support my fantasy speculation (well, X11 for macOS is dead) - but consider how Apple is so very protective of their UX moat (and PWAs be damned). It’s not in Apple’s interests to facilitate and support any kind of true cross-platform UI framework: remember how Java AWT/Swing apps were like on OS X? The majority of dispassionate (I.e. not Panic Inc) devs are never going to optimise a cross-platform UI for macOS because the whole point of using an xplat UI is so you don’t need to spend time on platform-specific code. Those two reasons combine form a vicious-cycle negative feedback loop that devalues their platform.
But with the web finally becoming the true, real, cross-platform that Microsoft was then-irrationally terrified of 25 years ago, I don’t know what Apple’s strategy is to remain the best provider of the best UX when everyone is going to be using Chromium in some form. And if Apple keeps pushing their own native apps devs to their hostile App Store while everyone else moves to the web, then the value-prop of an Apple computer looks bad compared to a Chromebook which is essentially just-as-locked-down and just-as-capable, just without iOS integration and a modest selection of (albeit) high-quality boutique Mac App Store apps.
————
On a related note: Apple does not have long-term support commitments as a matter of policy - which means enterprise/slow-moving/blue-chips won’t be interested in using Swift at all (compared to ISO-backed C++, Oracle’s Java, or MS’ .NET). Apple is going to have to maintain Swift’s support for Win32 and *nix in the long-run if they need to build their credibility and win-over large programming projects - but it’s just so against their corporate culture. It reminds me of their middling support for Safari for Windows. I know Apple gets Win32 and nix support for Swift “for free” by piggybacking off Clang+LLVM, but that’s basically the same as making Swift more like Java (“xplat for free”) but that’s just the bare-minimum they need to do: without Apple actively investing significantly in the developer experience for non-Apple platforms it just isn’t going to take-off. And they can’t do that for fear that a critical-mass of hackers will port Cocoa to Win32.
Swift is basically analogue to Google’s Dart+Flutter but it wants to be like Go.
The app I was working on was CLI-based that generated a log; and even for that non-UI use case, basic libraries were effectively missing.
It's a shame because it's truly an elegant language.
Swift does not have an incorporated "Swift Foundation", instead Swift.org's about-us page is surprisingly frank about Apple's control over the language and ecosystem ( https://swift.org/community/ ):
> Apple Inc. is the project lead and serves as the arbiter for the project. The project lead makes senior appointments to leadership roles, with those leaders coming from the worldwide Swift community of contributors
And the site's footnote reminds us that Swift.org is not separate from Apple, but again, owned by Apple Inc.
--------------
On an unrelated note, the .NET Foundation had an upset a few weeks ago: https://www.theregister.com/2021/10/11/dotnet_foundation_com...
Frankly, this distributed actors thing is more of the same -- it's something that someone at Apple thinks is important, so, despite it being just a library, it gets active support from the compiler and OS teams. There's absolutely no way that an outsider could have gotten anywhere proposing anything like this.
I like Apple's platforms and enjoy working with the language as well, but the openness is rather a charade.
EDIT: It looks like there is a plan to remove the SPM plugin and make it a first class feature. This work just started and is going through a normal evolution process.
I said from the compiler and OS teams -- there are at least two compiler engineers listed on the proposal.
But this is insupportable nonsense anyways: `distributed` is a brand new keyword, there are new rules about how inits work, magic property behavior... I haven't followed the proposal carefully, but there are also new toolchains being generated to enable the feature.
This certainly seems to be the case for desktop apps but not so much for mobile. Personally I'm rooting for the mobile web but the momentum seems to be on Apple's side right now.
I don’t think this is nefarious. X11 is a klunky GUI, at best, compared with pretty much everything else out there. It really can’t hold a candle to more developed GUI systems.
I was never interested in Swift as a server language, but that’s mainly because of the “chicken-and-egg” thing, as it was not supported by server infrastructure. I love the language, itself.
That's the problem: I see you're being dismissive of X due to its ergonomics and aesthetics despite the fact that X just-works and is still a vital component in computing: the same reason Windows retains both cmd.exe and PowerShell - I feel that your kind of reasoning is why we think Apple is so capricious with their consumer products (removing iPhone headphone ports, deliberately making HomePod incompatible with Android and non-Apple Bluetooth devices, the Trash-can MacPro, etc) they're roistering their own kind of paternalistic computing vision on their users).
People that need reliable, dependable computing experiences need to be able to use all the tools out there: old-but-good, tried-and-tested, no matter how "clunky" they are - and this doesn't neatly fit into the Apple way(TM). While I appreciate and respect Apple immensely for significantly and successfully driving the standards for user-experience and overall product industrial design, it isn't perfect... if only they'd tone-down their institutionalist corporate arrogance.
> compared with pretty much everything else out there. It really can’t hold a candle to more developed GUI systems.
X is a windowing system, it isn't a complete GUI system. Consider that, in fact, what Apple and Microsoft have both done quite successfully since the very beginning of macOS and MS Windows is how they have completely hidden the fact that widget/control libraries, the window-manger, the windowing-system, the compositor, are all completely separate and independent components that actually have no dependencies on each other at all. Having that visual and design consistency between those functionally separate components is what made Windows 95, and MacOS 8 (and especially OS X) so usable and approachable to _normal people_.
Now as X and Wayland are just one component in an entire GUI system, there really isn't a strong argument in removing vital components from their own systems just because they just don't like the way it looks - as though Apple is trying to avoid looking like a HP-UX CDE desktop from the mid-1990s.
I'm rambling, it's 3am now argh.
If they want to implement something that may interfere with X (usually they do this kind of thing because security), should they cripple the experience for half a billion users, to appease a small minority of techies?
I’ve been writing software for Apple devices since 1986, which means that I’ve had lots of rugs pulled out from under me, and have been incandescent with rage at Apple, many times.
That said, I’ve never regretted choosing it as my preferred platform, despite thirty years of insults and put-downs from other tech folks.
Yes and no.
So POSIX and the Unix Specification(TM) are standards thanks to the US federal government putting their foot-down and mandating that major contractors (like IBM, Sun, HP, etc) stop being incompatible with each other - and in-practice this also means having to support X.
When OS X launched Apple loved to tell everyone that it was a true Unix(TM) system - (after-all, they did spend the money to get it certified as a real Unix system), and this meant that OS X-based systems were suddenly candidates for major US and international scientific and research contracts and gigs - which dovtailed nicely with the hype around their boasts of the PowerMac G5's literal supercomputer performance (and indeed: literal supercomputers comprised of racks of G5 machines in a bunch of US Navy Labs).
Now, in the 2020s, it's clear that since the iPhone dominated their revenue that Apple is no-longer really interested in being part of government supercomputing and scientific computing contracts - the positive PR and technical credibility they gain from all of those government projects is insignificant compared to the cash revenue value of simply running another iPhone ad-campaign. The 2013 Mac Pro was solid proof that Apple does not value the high-end desktop and workstation computing markets anymore. Apple seems content to even let Windows take away their previously impentrable hold on the desktop video-editing market: whoever was using FCP on a MP in 2006 is almost certainly using Adobe Premier on Windows today.
...having said all of that, I was surprised to see that macOS 12.0 Monterey is still an official Unix(TM) certified product: https://www.opengroup.org/openbrand/register/brand3673.htm - despite Apple's deprecation (and obsolescence?) of their support for X.
-------------
So my point, if anything, is that if Apple wants to maintain its credibility as a high-end computing systems provider, it needs to revert back to doing far more than paying lip-service to being a Unix vendor - and that includes bringing native support for X (and some form of compatibility with the rest of the Unix/Linux GUI ecosystem) back into macOS - but if Apple continues to remain uninterested in selling themselves as a professional workstation vendor (which I feel is implicit in how they've been locking-down macOS and their Apple Silicon-based machines) then you're right, they don't have any responsibility to maintain compatibility with X.
As it is, I don't know what Apple wants - or even what Apple would do in the event they lose their cash-cow and grip on the world when the iPhone is somehow obsoleted by a competitor. Of course if that happens then they'll quickly reverse-course and try to make-up for all of their substandard devX moments.
-------------
> That said, I’ve never regretted choosing it as my preferred platform, despite thirty years of insults and put-downs from other tech folks.
Pardon my asking, but I'm especially curious - what kind of software do you write? Unless you work for major creative-tools companies like Adobe - or a boutique Mac shop like Panic nor indie Mac App Store dev - I have trouble imagining what market there is for other types of software on the Mac. Whatever native macOS / Cocoa line-of-business software there was over the past couple of decades will have certainly transitions over to being a SaaS web-app by now.
No one fully supports POSIX.
Aside from server systems like AIX or HP-UX Apple is literally the only company that has a POSIX-certified consumer OS (OS X since 10.5 Leopard [1]).
> So my point, if anything, is that if Apple wants to maintain its credibility as a high-end computing systems provider, it needs to revert back to doing far more than paying lip-service to being a Unix vendor - and that includes bringing native support for X
What's "high-end computing systems provider"? Apple is doing really fine as is. Why should they do "far more", and why does this "far more" specifically includes support for X? They supported X for years (OS X 10.2 to 10.7), and then decided it wasn't worth it (and it isn't).
[1] https://www.opengroup.org/openbrand/register/index2.html
Suffice it to say that a few folks (and I don’t claim to have a huge fanbase) seem to like the stuff I write.
As fas as SaaS… Well, let’s just say that this is a familiar tune. That ol’ “thin client” zombie just keeps lurching out of the grave…
Imagine if Apple /Microsoft would invest some dev hours in Java/Qt so it keeps up with the updates they put out, we could get decent cross platform apps but Apple/Microsoft don't want cross platform apps/games.
It is no surprise that the only UNIX clones that had a good desktop user experience always did their own thing instead of pursuing the X11/Motif path.
Really curious what success story they are about to tell me.
As far as adoption goes, many large codebases are likely still ObjC; simply because of hysteresis. Major architectural shifts take a lot of time, money and risk. That’s one reason I don’t feel that much urgency to jump on the SwiftUI/Async stuff (but I like what I see). I’m interested in shipping, and shipping is almost always a couple (or more) steps back from “the bleeding edge.”
In my experience, there’s not much of a downside to waiting for tech to mature and stabilize, other than not having jargon on my CV.
Swift was unusual for me. I started learning it, and releasing apps in it, right away. It was a gamble, and it paid off. There’s lots of folks that are probably just getting started with Swift, now.
I am still writing Swift despite being retired but as part of my art generation work now.
I've been "retired" for four years, and work more, every day, than I ever did, as a grunt.
I write Swift 7 days a week. I really like the language.
Anything publicly available? I’m always looking for more generative art!
not selling yet, but there is lots there
I imagine this has gotten a lot better since, particularly with stuff like Swift UI. That said, I’d personally find Swift more compelling to use as a server language.
SwiftUI was developed from the ground, up, to use FP concepts, and things like Protocol-Oriented Programming.
I’m looking forward to learning it, but the fact that most of the Apple world runs on tech from a design that was developed in the 1980s, should be an object lesson in the structural integrity of “classic” OO, and the MVC pattern.
We rubbish the past at our peril.
It’s not as if functional programming is newer or untested. The reason most of the Apple world continues to use these paradigms is because the codebases which do continue to exist. Inertia alone would keep ObjC around for another 20 years, and the software industry is almost totally rewrite-averse.
Anyway, the rest of your comment is exactly what I’m talking about: Swift and its value propositions just don’t match up with the things it has had to interop with. I’m hoping Apple actually dedicates resources to SwiftUI documentation and adoption, and that gradual uptake is enough to stop worrying about fitting Swift to highly stateful OOP APIs that weren’t designed for it.
It's not about maturity. It's about suitability for the purpose.
FP is probably not ever going to be easier to use, but it is safer, and can be used to safely implement algorithms of greater complexity than other paradigms.
It needs to be coupled with a reactive, event-driven system (that has state, but the state can be hidden in end nodes or a model), in order to deliver a great UX; which, at the end of the day, is what this is all about.
You can't have UX without state. It's all about where the state is maintained, and how many copies of it need to be made, as the program executes.
For example, say we have a checkbox that reflects/controls the state of a variable in our calculation. The on/off state is important. If it is on, let's say that we will introduce a compensating coefficient. If it is off, that coefficient is not applied to the function.
The state is not a part of the function, so it doesn't make sense to incorporate it (or even knowledge of the existence of that state) into the function.
Nevertheless, it is a crucial component of the user experience, and needs to be maintained somewhere.
The best bet may be to try to keep the state in the checkbox object, itself, and query it at runtime, or use a messaging system to be informed of state changes. I've always found a central model to be annoying. If the UX is at all complex, the model can get crazy, and turn into a richly productive bug farm.
Federated/franchised state can have its own issues, like when there's a lot of interaction/dependency between state nodes. That can get crazy, too, and difficult to debug.
So far, no one has come up with a perfect pattern, but I kind of like the idea of a "composer" pattern, that queries federated states, and "weaves" them together, at runtime, as opposed to a model that sends directives out to a set of nodes.
The issue that lots of folks have with OO, is polymorphism. That is not really the same thing. It can make discovering an algorithm difficult, as functionality can cascade through a whole bunch of levels, and debugging can be a real pain in the butt. If anyone has had sticky CSS specificity issues, they have an idea of what it can be like to grope around in a polymorphic codebase.
Protocol-oriented programming is not a panacea, either. This is especially true, when mixed with polymorphism. I wrote about a strange issue I encountered, here[0].
But polymorphism isn't bad. It's just a tool, and we don't use a nailgun as a hammer. Like so many tools, people have tried to shoehorn it into unsuitable configurations, and refuse to consider other, more suitable tools. I see FP proponents, doing the same thing.
Swift is nice, because it has a rich toolbox, allowing us to select the right tool, for the right job, without having to do complex linking games between libraries of different languages.
[0] https://littlegreenviper.com/miscellany/swiftwater/the-curio...