it should be noted that if you look at many of the most successful languages today (C++, python) they all follow the batteries included philosophy. People don’t want to use a language with poor support.
8 Likes
(I am not core team, this is just my opinion)
Batteries included should be the long term goal of the Swift project.
Long term, exactly how that's divided between standard library, corelibs-foundation, blessed/bundled packages, non-standard libs, etc., is a matter of accounting. Current accounting reflects current realities of the project, and as technical trade-offs shift the accounting should shift as well.
9 Likes
I also think the "Batteries included" approach is the better one.
Do you and the others think we can handle the accounting? I’ve already made a suggestion above:
It may be also a good idea to @-mention some core team members in order to get things started. (But I don’t know who would be "best suited" for this)
Correct me if I'm wrong, but to my understanding, a “Batteries included” implementation of this idea would be the dividing factor between a "Non-Standard Library" and the current cocoa pods.
cocoa pods are an orthogonal and irrelevant concept here. cocoa pods only make sense in the context of (proprietary) cocoa platforms.
But wouldn't a free market approach essentially just be recreating what cocoa pods have already done? A "Batteries Included" method would be where an official "Non-Standard" library would really shine in areas such as ease of setup and code quality.
The library being discussed would be curated, maintained and shipped together with the rest of the language. It will contain stuff like SHA1, ZIP and HTTP client/server. Other stuff, like AWS clients, game engines and web frameworks will of course still be available as 3rd party libraries through the Swift Package Manager. Cocoapods and Carthage are in the same space with SPM and I'm guessing their use is going to decline when SPM gets integrated into Xcode.
However this is just my opinion and this discussion is purely academic as there are no official plans to do anything as far as I know.
Foundation, Dispatch and possibly CoreGraphics all lie in same space that this Library would cover. They are very high quality frameworks, highly optimized and battle tested over decades of use, so you'd be crazy to not use them. The flip side is that they were created decades ago, they are not written in Swift and often don't match the way Swift does things and lastly they are tied to Apple's development process and release cycles. So for the time being we wait...
isn’t CoreGraphics osx only?
-- E
1 Like
I think Perl 5’s model is very nice. There’s a whole ecosystem of libraries, the CPAN, and some of these libraries are included in the core, meaning they get shipped with Perl implementations and you can count on them being available without the user having to install anything extra. (So these are the batteries from the “batteries included” approach.)
This means the “standard library” (or what this thread calls the “non-standard library”) is not a monolith and its parts can be developed using the same process as any other third-party module, just the bar for accepting changes is higher and the set of core modules is obviously required to work together well (as in Haskell’s Stackage).
Doing this for Swift would mean building something like CPAN, Hackage, RubyGems.org, or, obviously, CocoaPods. It’s a high bar, but doing this the right way would be a huge push for the language community and IMHO has to be done either way. It would be great to join forces with CocoaPods (and Carthage) somehow, but I don’t know if that’s realistic given their coupling to Apple platforms and their own package manager.
If we were to start this way, I would be happy to put code and money where my mouth is.
4 Likes
I agree that the "Batteries included" approach is most likely the best way to increase adoption of the Swift language. It's definitely a factor in why languages such as Ruby and Python and many others gained such popularity. People don't want to have to build their own libraries to do common things and if they look for others who have already made a library with the functionality they need and find 5 different ones that all do basically the exact same thing then they may be confused about which to use or dissuaded from using the language altogether.
That being said, I echo the thoughts of @zoul:
Doing this for Swift would mean building something like CPAN2, Hackage, RubyGems.org, or, obviously, CocoaPods. It’s a high bar, but doing this the right way would be a huge push for the language community and IMHO has to be done either way. It would be great to join forces with CocoaPods (and Carthage) somehow, but I don’t know if that’s realistic given their coupling to Apple platforms and their own package manager.
It would be extremely useful to have a single location where people can go to find libraries that aren't included in the core language. Python has pypi, ruby has rubygems, and other languages have their own package finding tools. It is essential for swift to have one of these as well, especially now that the IBM Swift Package Catalog has been shut down.
Googling for "swift functionality-the-developer-needs" is not the most effective way to find the library you're looking for, and currently that's what people have to do. Swift needs a centralized location for finding SPM packages if it's going to become mainstream.
3 Likes
I think we all agree that Swift needs some "Non-Standard Libraries".
Should we do it this way? Maybe one of the core team members (@Ben_Cohen @Chris_Lattner3 @dabrahams @Douglas_Gregor @Joe_Groff @John_McCall @tkremenek) has an idea or a concrete plan.
1 Like
I'm not sure that settling on a set of libraries and starting to build them right now is the right approach.
@Aciid mentioned in another thread that the package manager team plans to introduce a package index at some point, but there are no concrete plans yet.
I think (although I'm not sure) that a sensible first step would be to establish this index and wait to see how the package ecosystem develops from there and maybe choose some packages to be included with the Swift distribution, similar to how Perl seems to handle this.
It may also be worth looking at how Ruby is changing their approach (also here) to this issue.
6 Likes
I'm not sure that anyone here is saying we should start building a set of libraries right now, in fact, many of the libraries we desire have already been built by multiple different developers, and that's the problem! Adoption of swift packages is slow and fragmented because there is little unity in the swift package community. Different people find and use different libraries for a plethora of reasons. A developer may write his library to do one thing better than this other library that already does basically the same thing and neither library developer works together to find a unified best-approach, so we end up with multiple copies of basically the exact same library all competing to become the most popular which just results in an even more fragmented community.
The core team has said that once one of these libraries "wins" and becomes the de-facto standard, they might consider it for addition to the standard library, or possibly a non-standard library. Swift has been out for years and there are more and more new packages being created and the likelihood of one of them "winning" is becoming slimmer and slimmer. We see this all the time, a developer stops actively working on his library and so someone else writes a new one that's even better. They work on it for a while and then they stop actively working on it. Rinse and repeat.
For example, I know of three libraries for file management/manipulation and each has its pros/cons (there are probably more, but I only know of 3). One has a cleaner interface and significantly larger community, but doesn't support linux. The second supports all OS's but its interfacing isn't quite as nice. The third I haven't ever used because I found the other two before I learned about it and so I haven't tried it. It may actually be better than both! But I'm exhausted from all my investigation into the other two and too heavily invested in the one I'm currently using to justify another switch. This is one of the biggest problems I have with the current state of the swift package community. Packages are difficult to find and there are too many similar packages.
I think that what we want (at least me anyways) is some place where we can work together with a little bit of @core-team oversight to decide on best design approaches and coding practices for some common functionality libraries that already exist anyways. Things like file management, big nums, random functionality ([Proposal] Random Unification), crypto, or whatever it is. This way we could come to a community driven and commonly accepted library, rather than forcing developers to decide between several versions of essentially the same library.
A separate "Libraries" thread here on the swift forums would facilitate this communication. Currently devs are just hoping and praying people find their library through just the right google searches and choose to adopt it rather than write their own. It also opens the door for easier communication backed by this entire community, rather than opening a GitHub issue or pull request and hoping the maintainer(s) are active.
10 Likes
could not agree with this more.
If functionality gets better and better with each iteration, isn't that an argument against one of them "winning"? Why should we want to ossify something that's still evolving? If a developer can make a better solution by starting from scratch instead of building on top of an existing library, why should the community discourage that sort of effort?
i think what Ponyboy47 means is that there are a lot of incomplete or immature libraries out there so when a dev goes looking for one, they are invariably unsatisfied and try to write a “better” one themselves, but once it meets their local requirements it ends up being abandoned for lack of community interest just like all of its predecessors.
3 Likes
Thank you taylorswift for clarifying my thoughts better than I can :)
I don't mean to suggest we should prevent that sort of effort, but rather to help them along by providing a location for this evolution discussion to take place here, where they can take advantage of anyone interested instead of just the people who happen to know about their library.
I imagine that the discussions in a "Libraries" thread would be very similar to those that occur here on the evolution thread, and that people would discuss things they liked from other libraries or languages. I also imagine that people will frequently link to their own libraries or others libraries that they have used, much like people are currently doing in the evolution discussions about language features.
I personally feel that this would actually bolster development and adoption of each of these libraries. Most of the swift libraries I've seen tend be driven by just one developer or maybe a small handful of people. If one of these library developers takes part of the discussions then they could likely improve their own library knowing what the community truly wants. Having the input from core team may give additional insights into how they can improve the library as well. It may even be that someone will take the discussions from the "Libraries" threads and make their own new library as a result of all the community inputs.
Even minor changes to a search query can yield entirely different results when you're looking for a library or even just a Stack Overflow post, these search results directly correlate to who knows about which libraries that are available. It was pure chance that I learned about any of the file management/manipulation libraries I mentioned in my previous post. Each one was buried in a search about paths/files that just happened to yield results that led to me learn about these libraries.
Giving people a single common location to discuss all of the libraries they know about and the pros and cons and directions the community thinks they should take would greatly benefit the community as a whole and would increase the adoption of the true "best" library.
Basically, I see no harm from creating a separate "Libraries" thread but a large amount of benefit.
5 Likes
For the kind of standardized libraries that I think would be the most important one, that argument doesn't count:
Things like Result and Point are so trivial that many implementations are completely equivalent - but still, if two different graphics frameworks decide to use different representations for coordinates, you can't combine those two without stupid conversion.
Just imagine Optional wouldn't be standardized, and everyone would use his own flavor.
If they’re trivial, then it’s also trivial to switch the type you use or convert between them. Optional needs compiler support for special sugar and therefore must be in the standard library. By contrast, the differences in Result implementation arise from disagreement on the issue of whether the Error type should be generic, which simply isn’t settled.