Or, What, 10 years from now, would you be glad Swift did?
That question aims to identify the biggest values Swift can deliver.
A way to start is to rank the things Swift did in the last 10 years that have proven valuable (albeit painful):
Objective-C inter-op
Correcting String (even if it isn't downscaling now)
Generics
I believe some known initiatives will be very well received by the future:
Avoiding data races, actors, and atomics
C and C++ inter-op
Embedded + Foundation, i.e., language & library factoring
But it's clear that Swift is entering a time of complexity:
the language and type system
the runtime model of concurrent and distributed systems
the platforms
AI driving developer ergonomics as IDE's/content-assist have
So to manage this complexity my vote for the next manifesto in Swift would be on intelligibility, making things both observable and understandable.
You should be able to see and understand what's happening, what happened, and what broke. "Progressive disclosure" would not just be adopting more powerful language features, but building a clear and correct programming model apparent in any decision-making situation. Reactively you'd get a quicker response; proactively, better design. Mutual understanding is the baseline for community goodwill.
Milestones would include
(more/better) compiler errors with explanations and fixes
debugging that just works
crash data-capture and interpretation automated
computable models for data in transit, concurrency and ownership, for visual rendering and what-if
ability to quantify library or language usage/breakage
exposing types as we do syntax for downstream analysis and program transformations (and making syntax more usable)
It's not Swift's job to do all that; most it need only make possible with the right metadata, and perhaps some controllability: user-extensible error handling (for dynamic fixes), on-demand (or -trigger) semantic re-analysis to surface more type information, etc.
Swift is easy like Java but efficient like C, enabling it to scale developers and devices. If it were a bit more (programmatically) understandable, it would help manage the complexity and form the basis for new ergonomics.
C# also faced this problem with the native compiler. Our approach with Roslyn was to rearchitect the compiler as a mechanization of the C# specification. We essentially lifted the entire specification into the object model. Roslyn now has two separate semantic trees: the public surface area, defined by interfaces, that represent the spec view of a program, and the internal trees. The internal trees have no public surface area and are used to implement the public interface, but can be arbitrarily refactored.
Implement a proof checker expressive enough to encode (1).
Re-implement (1) in (2).
A silly troll accusation I’ve seen leveled against almost every language is “<> was clearly designed by compiler developers, who optimized it for their use case at the expense of everything else”.
But in all seriousness, I’d love to see someone attempt a DSL for implementing statically typed language frontends, even just toy ones, in terms of some kind of “executable language spec”.
You mean type-based overloading specifically, right? Two functions that differ not in their names (including the names of their parameters) but their parameter and/or return types?
I know things like filter(by:) + filter(where:) have been a point of contention for some folks, but I think by and large they've proven to be popular and a net win.
Tangentially, I feel like official support for formal overload priorities (re. @_disfavoredOverload) might help, especially with overloads on return type only. I don't know if that'd aid compile times necessarily, but it'd at least make overloaded functions easier to use, by reducing or eliminating how often the compiler aborts because it finds multiple technically viable overloads.
we have 10 different binaries in the app (for 10 different Swifts)
those binaries could be generated and provided by AppStore (I remember there was an option like that that involves byte code being submitted as part of app submission and that byte code converted to the actual binary for the given device)
on platforms with no appstore the binaries will be provided explicitly (like FAT binaries). When the app is deployed to the target device unused binaries could be deleted. Alternatively the thin version for the specific Swift version could be downloaded.
However, I was being somewhat loose in my terminology as I was using formalisms to hint at a general approach, that is in reality much more loose than the terms. In broad strokes I want to think about the Roslyn compiler as a kind of a mechanized theory, but in practice the C# spec is just a very loose English-language description.
Building an even more expressive metatheory, and then mechanizing that metatheory as hinted in (3), is, you know, fascinating, but in practice not that useful.
As designers we would love to ask probing metatheoretic questions about the soundness of particular constructs, but the actual questions asked by users are questions on programs, answered by the theory itself.
So, all this to say that the very pragmatic way of this is to just write down a reasonable sketch of the language semantics, call that a spec, and then expose APIs that mirror that "spec" in executable format. It leaves a lot of questions unanswered -- or ambiguously answered -- but it ends up being useful enough to get like 80% of the value.
I'm curious, how big is the performance difference? Swift performs similarly to Rust for me when I profile it. Does it only show up in the most optimized code?
The most optimized code performs about the same in every language, because people who know how to navigate their way through the language idioms and compiler quirks have optimized it. It’s the other code where you can see a difference between languages (especially code written by people who are very used to the optimization idioms and compiler quirks of language B, and naively expect the same techniques to apply to language A).
I haven't seen this in other languages I'm familiar with, but I wish Swift made it possible to easily spawn/control os processes (akin to communicating sequential processes) with both synchronous and asynchronous I/O ports to make it easier to compose large, resilient systems out of smaller ones.
FWIW, we did try something similar to Swift in the first incarnation of our native compilation technology (.NET Native, used for UWP apps). The problems and expense of maintaining this implementation caused us to drop support in Native AOT, and right now it looks unlikely that we will ever bring it back.
At least for C#, the tradeoffs don't seem worth it.
Completely agree with your point. I think swift 6 may be the last chance for this language to really become mainstream. I've been doing native mobile development for the last 15 years (ios 3), and i know for sure that my next project will only use swift as a DSL for the UI layer, and that's it (unless swift truly becomes multi-platform by this time). Despite the fact that i really love the language original core features.
My feeling is that swift steering committee should have been much more involved in making sure other large companies beyond apple sponsor the language, and use it for their own projects. It would surely have helped improve the overall ecosystem. The beginnings with IBM and later Google being involved was really promising. Something may have been missed back then.
As someone already expressed here, parameter labels for closures—
When occasionally I need recursion—it's hard to say if it will be tailed and compiler will optimise it or not. Even if you do the requirements, sometimes it's still not tailrec
Maybe also type level whenLocal for distributed actors But this is fixable.
Guess overall I'm ok with language evolution. But think there could have been more work done by making language more mainstream:
Contrary, but think Swift is doing ok with introducing new features and keywords, especially comparing with other languages (e.g. Rust, Scala and etc.). It's not perfect though, pain point for me—features are spread out across different directions and sometimes it's hard to get a broader picture where Swift is going. Seen some folks are also confused.
Also agree with the comment about making sure not only Apple is using Swift:
a) Overall Swift is still considered by many as Apple platform language only, even with all the efforts to support different platforms. Feels like this will land in C#/F# state where it's mostly used with .NET (or Unity). Love F#, but tbh will prefer to use Ocaml if I need some functional language, as it's supported by smaller, but broader community.
b) Sometimes Swift is not there from performance perspective, even though it's advertised as a fast language (and it is). For example just seen this comment lately. Could have been already covered and improved, or proper examples/patterns provided if more companies would have been involved.
c) Even though Apple is fully committed to Swift, it's usage could be limited to legacy, management decision and etc. Personal example—out of curiosity learning and invested into distributed actors topic, and feels like Apple is not interested in it atm. Even though from job openings see there is tech stack that could benefit from it.
Btw, regarding last topic—always wonder if there some discussion inside Apple on how to use Swift more beside iOS/macOS or main focus atm is to replace C++?
Swift is already one of the most platform independent high level languages out there and has best in class C interoperability, there is little friction to use it anywhere one would like, especially now with the embedded mode.
Competing languages like Kotlin have much worse interoperability, cross platform compatibility and tooling but are seen as more "multi-platform" when they really just abstract their shortcomings away with large pre-made frameworks. Trying to actually do something non standard tends to be very painful, and you're quite dependent on large companies, far more than with Swift, which is ironic considering it's the language seen it as an exclusively Apple language .
There's nothing stopping multi-platform app libraries from being developed by anyone, Swift makes doing so more accessible than any other language, it just can't seem to escape the connection to Apple, likely because it's a company known for building very tall walls around anything it creates. Swift should communicate its strengths better, and maybe make it obvious that "no this is not a language tied to Apple platforms" in bold text ot something .
Clearly it's not obvious enough as is, and the website is not helping this misconception by advertising "Apple Platforms" as the first use case without mentioning the interoperability anywhere.
Maybe removing (or at least documenting) the boilerplate required to cross compile and use system libraries would help. The build system is not good, and some features like Resource.embedInCode() are so broken I'm surprised they exist.
I'm not sure if that comparison of reading into a String in Swift and using open in Python is fair. There is at least twice more work done in terms of just reading - first into String object, and then enumeration line by line, while in Python it is done in more optimal way. Python even might have improved readLines method by preserving capacity for output list internally, while in Swift code it will require allocations. More proper would be to use FileHandle or even fopen to match Python at least in terms of correct reading.
Initial confusion of what to use by the author, however, is an issue I believe: there is no clear interface that would say "use me to read file line by line". And FileHandle is part of Foundation framework, not the language.
What concerns me is out of control complexity, similar to C++. Too many features and syntax alternatives (you need to know them all to read arbitrary code), and an overly-pedantic language philosophy. I’ve learned a fair amount of Swift about four times now and I have to re-learn what I’ve learned each time I’ve approached the language, because it all changed. I keep going back to Objective-C because it’s easier & more enjoyable, and in the cases where I need speed, C++ is still faster.
Yeah, tbh I've wanted to respond in comments that comparison is not fair, but feels like quite often task and it's not obvious in Swift how to achieve the same.
It's just an example, see that kind of stuff from time to time. Actually think language is quite performant, just how you use the language can become a problem. And then you need to google/check forum/ask someone and etc. So basically agree here:
Simplicity can be deceptive; many older languages, especially object oriented, tend to have far more unwritten rules and patterns on how to write code than Swift has feature complexity — and those changed over time just as much, if not more.
Learning complexity incrementally as it is added to something we are already used to is always going to be relatively easier than switching to a completely different style of programming.
I started programming with languages like Rust and Swift so for me it's the inverse, Swift is immediately understandable where the patterns of languages like Objective-C feel cryptic and old — more so even than looking back at the beginnings of OOP like Smalltalk.
Remove callAsFunction as Xcode can almost never find it, and it's great at obfuscating things to make it hard to tell what's going on.
Add actual namespaces as the enum namespace thing is such an abused hack.
Remove the implicit return type from closure thing, as it's also great at making it hard to figure out what's going on, and when something in it goes sideways in a chain of method calls, the compiler melts down and gives nonsense diagnostics.
Generally prioritize making the language easier to read over easier to write.
Add the ability to call into super default protocol implementations? I know this kinda messes with what a protocol is, but would it have to?
As i am only a user of the swift PL and not a swift PL developer, i may conflate the ecosystem with the language itself indeed. From my POV however, it doesn't really matter.
I tried to compile a swift "hello world" cross-platform mobile app (meaning ios & android) during the last year on my mac M1 using various 3rd-party SDKs without success (for various reasons, depending on the SDK).
I recently tried kotlin multiplatform, and it took me 10 minutes to do it, using a real software architecture with clean separation of business logic written in kotlin, and UI written in whatever i wanted (swift UI or something else), while giving me enough confidence to feel that i could build a real application with it.
Plus, the kotlin team is heavily communicating on this part of the language, documentation is abundant, talks about it have been online for a few years now, the ecosystem seems maturing at a nice pace, etc.
I had tried the same thing in rust almost a year ago, and although you could feel that the ecosystem was more sparse, the documentation were also super clear, and i managed to build a library in rust that i could use both on an android simulator and an ios one, to use from a native UI, written in whatever. It was of course a bit more crude than kotlin multiplatform, but it also gave me confidence the road was there (since that time i've known a few team using rust for building cross-platform mobile apps with great success).
Another data point : look at the signal library. Purely cryptographic, so not a lot of dependencies, and yet they chose rust instead of swift for their cross-platform rewrite. It could be for performance, i don't know, but it does tell a bit.
Now you may tell me swift "is the most platform independant high level language out there", and it may perfectly be true, but from a swift user POV the least you can tell is that it doesn't really show.
But this is fixable.
comment about making sure not only Apple is using Swift:
.
.