What does HackerNews think of swift-corelibs-foundation?
The Foundation Project, providing core utilities, internationalization, and OS independence
There already was an open-source project to rewrite ALL of foundation, but it had stalled on the shores of having to re-implement everything:
https://github.com/apple/swift-corelibs-foundation
The announcement:
https://www.swift.org/blog/future-of-foundation/
https://forums.swift.org/t/what-s-next-for-foundation/61939/103
What's Foundation? Swift's most-core library is the stdlib, tightly coupled to the compiler/language version, providing things like arrays, dictionary, etc., and available wherever Swift is. Beyond that, Foundation is the library with core API's for common features, e.g., for dates and concurrency. Stdlib is fully cross-platform and Swift-specific, but Foundation is a beast with API's dating to NExT with support for 20 years of API's.
Microsoft famously arrived at porridge for an operating system by maintaining backwards compatibility. Apple has cracked open Swift by developing in the open, but it's still Apple-funded and Apple-driven. Library and some integration support for other platforms has always had to come from community (notably compnerd's heroic effort to make-things-work on windows, and a revolving cast wanting Linux support for their server API's).
But there's no good reason to impose the whole Foundation history on other platforms. And there may be a movement inside Apple to migrate internal code to newer async API's, designed after the recent Apple-silicon generation.
For developers with server experience and some free time in a tech lull, it could be a good opportunity to help rebuild a new, er, foundation for computing on all devices, that's native but type- and memory-safe. The community is large and mature, but there is plenty of room for others.
If I use the SL, then I should also have no problem using some lashed-up chimera that has a dependency hierarchy that spans three continents.
Like I said, I'll do things my way.
For the record, here's the Swift Foundation Library: https://github.com/apple/swift-corelibs-foundation (I mostly write in Swift).
It has plenty of open issues: https://github.com/apple/swift-corelibs-foundation/issues?q=...
Also, for the record, here's a peek at some of the "worthless" packages that I use in my own work: https://github.com/RiftValleySoftware
If every dependency chain can match these, then I'll be open to considering them.
As it is, I do use the occasional external package, but I'm picky.
As a consequence, many Swift libraries only focus on macOS, just like many dotnet libraries focus on Windows (though recent efforts have improved that situation). You can probably get a lot of them working on Linux as well and if you use Swift for command line tools or web applications. I suppose you can probably run the most important tools cross platform, but the non-native ecosystem is clearly a second class citizen.
The big difference between XCode and VSCode is that Apple doesn't claim XCode is open source; also, XCode is more comparable to Visual Studio than VSCode in terms of SDK integration and preconfigured tooling.
Huge parts of the Darwin kernel are actually publicly accessible while Microsoft only provides kernel sources under NDA in things like education projects. Unless you count the WinXP source code leak, that is.
C# is sort-of mostly open source-ish except that debugger features are closed and the community has little say in its development.
Apple did in fact put effort into making Swift cross platform, as outlined here[1]; though their intention is that Swift programs use the system runtime on macOS/iOS/iPadOS, they put the effort into making a base layer freely available for other operating systems to gain some portability.
I'd personally argue that Apple and Microsoft are similarly if not equally open in their development, but Microsoft advertises itself much more "open source" than Apple. Apple's approach of "you can look but you can't touch" is a lot more explicit and their supposed openness comes up in fewer marketing materials.
> Our primary goal is to achieve implementation parity with Foundation on Apple platforms. This will help to enable the overall Swift goal of portability.
Foundation is open source https://github.com/apple/swift-corelibs-foundation
FYI, Swift is available on Linux and Windows along with a significant chunk of its core libraries (e.g. https://github.com/apple/swift-corelibs-foundation) and app frameworks such as Vapor (used for writing web apps and APIs).
You can find some info by searching, there has been a few attempts to get it running on Android. Also just searching around github will net some other attempts.
The foundation dependency is the biggest problem. You can check out https://github.com/apple/swift-corelibs-foundation which gets rid of the objc runtime dependency for other platforms, though you will find yourself writing implementations for each eventually.
I would say if you are going to stay with just Android/iOS to look into maybe moving to Kotlin or C for your common layer and then call it from Swift. Kotlin multi-platform also has been improving recently.
EDIT: Also look at the Swift github, there are some docs about different platforms. https://github.com/apple/swift/blob/main/docs/Android.md
The "core language" pretty much works great on Ubuttnu, but there are still minor annoyances getting it installed, or building it, on Linux. Other Linux targets, also doable, but more annoying. Windows, I haven't really heard of people doing for real. Not sure that's even on anybody's radar.
What's really awesome is how far Swift has come with the core lib Foundation, which is a from-scratch clone of Apple's Objective-C and closed-source macOS/iOS Foundation library[1], written in Swift, in the open. It is not done, but huge swaths of it are now done[2], and that makes coding in Swift on Linux a lot more pleasant, since we don't typically want to waste time rolling our own regex support, Unicode string manipulations, basic geometry routines, HTTP networking, date formatting, etc. But Foundation is a huge, almost 30-year-old library that has evolved continuously and has shipped with every OS X/macOS/iOS release. An open-source Swift re-implementation of that sounded like "yeah right" bullshit/fantasy when they announced it but now it looks very real just a couple years later.
Tooling is different issue, though. Swift is a modern language with excellent support for auto-completion and in-editor hinting and help. People complain about it all the time, but Xcode is so much better than any IDE on Linux (or any other platform) for coding in Swift that I do most of my Swift-on-Linux work using a Mac, with Ubuttnu running in VMWare Fusion. If a basic editor will do, though, you have a lot of choices. For builds and package management, Swift Package Manager is now built into Swift, and works great. (It also has an option to automatically generate Xcode project files from Swift packages, which is hugely useful; my practice, and I think the prevailing or at least emerging convention, is to keep the package and source in git but treat the Xcode project as a throwaway item, not in version control, that can be generated whenever needed. So you don't need Xcode, but its easy to use for editing convenience when you want, assuming you have a Mac. But not all devs need to have Macs.)
I think you still have to like Swift a lot to choose it for your Linux project, but it is doable. I'd be surprised if Swift adoption on Linux didn't quintuple or sextuple by the end of 2018.
[1]: https://github.com/apple/swift-corelibs-foundation
[2]: https://github.com/apple/swift-corelibs-foundation/blob/mast...
Of course UIKit will still be missing, but thats sort of expected.
The first proposal for bringing Foundation APIs to this decade has already been accepted for Swift 3: https://github.com/apple/swift-evolution/blob/master/proposa...
https://github.com/apple/swift-corelibs-foundation https://github.com/apple/swift-corelibs-libdispatch
Works is well under way.