Introducing FoundationLite framework as a portable subset of Foundation

The Evolution process misses a strong lead and vision. So development of Swift moves very chaotic and not targeted. Beside that there are the ever present bikeshedding wars. Both not something I want for macOS/iOS APIs.

3 Likes

I believe this is only partially true.

Each version of swift has has a specific goal in mind (ie: ABI stability for swift 5). This primary objective has been a motivating factor behind several proposal acceptions/rejections of which I've been following.

That being said, I do understand why you feel that development is chaotic. A large amount of the proposals are created because of what a single contributor feels like working on and pitching to the community. There isn't always a long-term goal and many proposals start as, "I like/want/need this feature, so I'll see if others agree that we should add it." There is some oversight from the core team, but many times that oversight boils down to a simple decision of "does this actively harm our long term goal for swift?" If not, then it's usually accepted.

This is true of any development where there is more than a single developer though (and sometimes even when there is only one dev). It's impossible to avoid bike shedding and as long as it doesn't go on for too long I don't see the harm (of course we may draw the line for what qualifies as "too long" in different places).

I would already be glad if a clear long term design goal would be decided on and communicated. It would remove a lot of chaos, imo. A kind of open mission statement.

1 Like

I'm in complete agreement with you here. "World Domination" is not exactly the most specific goal :wink:

Although I do think the core team is realizing that they need to give more specific long term goals to the community and the following posts/threads are proof that long term goals are becoming more important:

These show that the core team is trying to formulate the long-term swift (and swift.org) goals by getting feedback from the community. I'm sure there will be more announcements in the future once the actual mission statement has been decided on by the core team.

4 Likes

The long-term goal as stated on https://swift.org/about/ is:

The goal of the Swift project is to create the best available language for uses ranging from systems programming, to mobile and desktop apps, scaling up to cloud services. Most importantly, Swift is designed to make writing and maintaining correct programs easier for the developer. To achieve this goal, we believe that the most obvious way to write Swift code must also be:

Safe. The most obvious way to write code should also behave in a safe manner. Undefined behavior is the enemy of safety, and developer mistakes should be caught before software is in production. Opting for safety sometimes means Swift will feel strict, but we believe that clarity saves time in the long run.

Fast. Swift is intended as a replacement for C-based languages (C, C++, and Objective-C). As such, Swift must be comparable to those languages in performance for most tasks. Performance must also be predictable and consistent, not just fast in short bursts that require clean-up later. There are lots of languages with novel features — being fast is rare.

Expressive. Swift benefits from decades of advancement in computer science to offer syntax that is a joy to use, with modern features developers expect. But Swift is never done. We will monitor language advancements and embrace what works, continually evolving to make Swift even better.

What do you feel is lacking from this goal statement?

Just saying that Swift aims to be safe, fast, and expressive is a very general statement. I'm sure everyone here could define those 3 things differently. Which is probably why the "Expressive" section states:

Basically what I glean from those goals is that Swift is always changing and the end goal is really a moving target. Nothing concrete about what is actually being done to/for swift.

I think what many developers (like myself) are looking for is a more specific set of goals. Yes, those are the general goals of the swift language as a whole, but what is being done to achieve those? What does it take to say that my idea for a proposal matches the criteria of being safe, expressive, and fast?

How are we replacing C-based languages across multiple platforms? (Or at least how have we enabled them to be replaced?) What APIs are being/should be written to make swift more expressive and easier/safer to use? Which algorithms are commonly implemented in other languages that Swift is working to implement "faster" and/or "safer"? And the best question (or at least my personal favorite), when are all of these things being implemented in swift? :wink:

I'm not alone in saying I want the specifics of what can be/is being done to achieve those very broad goals. I'm sure that whatever list of specifics we come up with today will be different a year from now, but breaking down the broad, generic goals into a smaller set of achievable goals can help give a lot of direction and comfort to the community.

I also think the core team tends to agree that the community needs/deserves more specifics, which is why they've begun asking for community feedback or even stating some of those more specific goals.

There's a lot more that goes into making swift as a whole safe, fast, and expressive than just making new things safe, fast, and expressive.

2 Likes

"Safe, fast and expressive" isn't the goal, they are design principles. Questions of how or when aren't about goals either, they are about plans (and I agree completely that the core team could be more specific here).

The goal, as stated, is that Swift should be "the best available language for uses ranging from systems programming, to mobile and desktop apps, scaling up to cloud services."

Personally, I think that goal is vague since there is no prioritization between systems programming, apps and cloud services. Things that are unproblematic on iOS and macOS, e.g. important APIs only being available in Foundation, are problematic in the cloud. And other things that make iOS and macOS development possible, e.g Obj-C interop and AnyObject lookup, might be long-term hindrances for systems programming.

I would like for example a clear long time commitment to oop - This would remove all the bad dissing you get from parts of the community when you want to use it. It often feels like oop is a third class citizen of Swift.

1 Like

No one is going to remove classes and inheritance from Swift, and that's all OOP really is, from the perspective of syntax.

4 Likes

There is a difference between retaining the syntax and being fought by the community because you want to use it. I have often heard here that oop sucks, is dead and inferior to value types and functional programming. That's not a clear commitment to oop in Swift.

A clear commitment by the core team that oop is a equal part of Swift would enable to point at the statement when people start with the oop hate.

I fear I'm not good at putting in words what I intend to say so of something is unclear just ask for clarification.

Full agreement.

There is no silver bullet, different languages prioritise different things. For example, the fact that fatal errors are unrecoverable is a big problem for server-based applications (you need to build some infrastructure around it so that an illegal array access or integer overflow doesn't just halt your entire service), while it probably makes a lot more sense for iOS/macOS (the user can just restart the App). Similarly, the choice of ARC vs. GC is not "superior" but a clear tradeoff between predictable performance and not requiring users to deal with low-level details such as retain cycles; one which, I think, makes much more sense for certain types of applications than for others.


A young language, just like a political party, becomes the surface onto which people with very different desires, needs and philosophies project their ideas. We're already seeing this with some people wanting to push traditional (Java-like) OOP, asking for things like abstract classes, a protected modifier, etc., whereas others try to push FP and would like to see HKTs and so on; yet other people seem to want Swift to be much closer to the metal and want to implement parts of Rust's borrow checker.

Ultimately, I think, the language will have to decide what it wants to be.

6 Likes

I think you’re confusing love of fp with hatred for oop. The latter isn’t going anywhere in Swift, but a lot of patterns are objectively better solved using fp, and pointing that out, is not the same as hating oop. The opposite is also true.

1 Like

I would be wary about throwing around terms like "objectively" so easily. Whatever studies there are about FP vs OOP productivity are very inconclusive, to my knowledge (which is to be expected, there are way too many confounders).

2 Likes

I'm not throwing it around easily. I use it sparingly. But for some cases fp are better. For others, oop is. Yes, even objectively. Which is better, in general however, is an inconclusive subject. Therefore, Swift is pragmatic and lets you choose.

Anyone suggesting that Swift, or the community, is against one or the other, is ill-informed.

2 Likes

TLDR: Since Foundation multi-platform is an afterthought and since we cannot directly impact the way it evolves, maybe it's not the best choice to have it full with utility features that every platform will need. Having another library that is thought multi-platform first and that we can direct the way to evolve through evolution process might be better.


FWIW Foundation supposed to be swift-corelibs-foundation/README.md at main · apple/swift-corelibs-foundation · GitHub and its evolution is public swift-corelibs-foundation/Status.md at main · apple/swift-corelibs-foundation · GitHub.

But actually, Foundation is more a library for working with Apple OS(iOS, macOS) and SDKs rather than a toolbox for Swift because a lot of it’s type are bound with features Darwin. Backporting Foundation to other OSs is a bad idea because it API rely on a lot of Darwin feature since it bound with AppleOSs, its evolution is not modifiable and multi-platform support is an afterthought.

Having a project driven by the community is really a hard and slow this I understand the resistance to open the evolution of Foundation so we cannot influences(mainly slow) it evolution which might impact Apple SDKs and platforms. In order to make Swift move forward, it needs to have more independent and multi-platform enabled library.

Foundation and Swift don’t seem to share the same goals like multi-platform support and evolution openness. Those are crucial for adaptation and Foundation can’t do them maybe it should be shipped with the Apple SDKs instead of Swift.

I don’t think we should do a Foundation Lite but we should add what is missing to the stdlib or make a new cross-platform library that will handle these task.

We have already seen that SPM, NIO, libSyntax needed some features like Process, URL, Data and re-implementing it.

Maybe we can use some blessed library like express here Large Proposal: Non-Standard Libraries even if would prefer a first party solution.

BTW I know Apple is working hard to bring Foundation on Linux and maybe Windows and a few important features have been recently added but the teams working seems rather small.

Some features of Foundation are developed in the open RFP: OrderedSet.

6 Likes

It's not a slow process people fear - it's a solution that isn't tailored to macOS/iOS but just another sucking cross platform toolkit nobody wants to use.

Foundation does not seem like a Swifty solution and is not easy portable.
I rather think that it should be available only on macOS and that we (Swift) build our own cross-platform API, being it inspired by Foundation or other languages.
It would resolve issues that we have currently such as SwiftNIO not linking with Foundation because of dependencies.

What is so unswifty at Foundation? I don't understand why it is so hated by non apple users.

The fact that some of it doesn't work on non-Darwin systems?
I recently spent a whole day replacing a CSV library that worked locally but wouldn't in our docker container on CI (and production). The reason it didn't work was that some as NSData? casts work on macOS/iOS, but they don't on Linux.

1 Like

This type of bridging has been recently added to Swift Foundation.

I think that people stating that Foundation is not a cross-platform solution are simply saying that because:

  1. Swift Foundation is not fully completed.
  2. Foundation on Darwin is using a different Objective-C based implementation.
  3. Swift Foundation is not at feature parity with Darwin Foundation.
  4. Ignore the history and evolution of Foundation.

Foundation was designed to be a cross-platform basic framework (the Objective-C version has been working on NeXTStep, Darwin, Windows (I think iTunes is currently using it) and Linux (GNUStep)).

I do think that:

  1. Completing Swift Foundation should be a priority of the Swift Project.
  2. The Darwin Foundation Swift SDK overlay and Swift Foundation should be somewhat integrated to allow full cross-platform evolution.
  3. Foundation design should move to a Swift Evolution style. The design direction and roadmap should be published and updated by the Foundation Core Team.
  4. Publishing parts of the Objective-C Foundation source code would allow to make Swift Foundation more similar in implementation and performance to it.
  5. In the long-term it would be great to be able to unify Swift Foundation and Darwin Foundation so all Objective-C entry points would call to the Swift implementation that would be the same in all platforms.
14 Likes