[swift-evolution] Large Proposal: Non-Standard Libraries

Thu Nov 9 04:11:02 CST 2017

Just to comment on the idea that a forum will pull the community
together and improve this situation. A good and recent (as in young
language) example of it is Rust
https://users.rust-lang.org/c/announcements . You can filter by that
category and see what the community is building, new libraries and
even calls for help to maintain them. Not saying that that specific
forum is the solution but just pointing that something different that
the mailing list would help. Also there is already a lot of people
that doesn't chime in in this discussions because they are not
interested in dealing with a mailing list (you can see it easily with
recent conversations that happen in GitHub instead of here).

I also like how the standard Go packages look, a rich set of
functionality *out of the box*. I really like that, is basically how
Apple platforms are always so nice to develop on with Foundation been
amazing. But unless the Core Team can oversee the development and
design of such tools I personally wouldn't feel confortable shipping
them with the rest of Swift. And it doesn't have to be, with
improvements on SPM there shouldn't be a big difference between
something that ships with Swift and a 3rd party package (apart from
being installed on the OS instead of coming with your binary I guess).
With that and having the community together, and a good place to
highlight them, I feel like the de facto standard libs are gonna pop
up with some time and care. Then and only ten would make sense to
consider making them part of the oficial distribution. (unless
obviously the Core Team would triple in size and they had infinite
time to do all of it, but then we also like when they improve the
language and tooling, can't have it all ^^)

Another thing that this list has to consider when not receiving
feedback on this kind of thing is that a lot of the Swift community is
more the iOS community, and that already has a lot of necessities
solved with other package manager, indexes, website that showcase
libs, newsletters, etc. The difficulty here is grow the part of the
community that is not iOS (or Apple platform) centric, which is key
for the future of world dominance.

Cheers

On Thu, Nov 9, 2017 at 8:54 AM, Kelvin Ma via swift-evolution
<swift-evolution at swift.org> wrote:
> i’m not one to applaud everything go does but its extended standard library
> seems nice
>
> On Thu, Nov 9, 2017 at 2:24 AM, Nick Keets via swift-evolution
> <swift-evolution at swift.org> wrote:
>>
>> I think there are two ideas discussed in this thread at the same time. One
>> is for a more extended standard library, that is developed and shipped as
>> part of the language. This is similar to what Python, Go and other languages
>> are doing. The second is for a more wide collection of packages, developed
>> by 3rd parties and not included with the language. This is similar to npm,
>> PyPI, etc.
>>
>> If I understood it correctly, the original proposal is about the first
>> idea and I don't think an "open market" approach works well for this. As for
>> what should be included, I find Go to be a nice example, that could be used
>> as a starting point:
>>
>> https://golang.org/pkg/
>>
>> To summarize, it includes:
>> - archival and compression formats (tar, zip, gzip, ...)
>
>
> will be an open problem to port zlib to Swift, but it’s doable
>
>>
>> - a few data structures
>
>
> lots of incomplete implementations floating around GitHub, none really stand
> out because i feel like most people have gotten used to rolling their own
> since we still don’t have a Swift equivalent of std::priority_queue. at this
> point i just have Queue.swift file lying around that I copy and paste
> whenever i need it. which is bad.
>
>>
>> - cryptographic functions (including hashes and random numbers)
>
>
> This is being talked about right now, mostly about random number generation,
> less on cryptography since it’s really easy to mess that up
>
>>
>> - sqlite and basic database drivers support
>> - various data encodings (CSV, XML, JSON, ...)
>
>
> I have an Linux-compatible XML library in progress, last I remember the
> Foundation class didn’t work on Linux
>
>>
>> - some stuff used internally by the go tools (AST trees, debugging
>> symbols)
>> - basic graphics and image support
>
>
> i maintain a Swift PNG codec, and am developing a pure Swift JPEG codec
>
>>
>> - basic text and HTML templates
>
>
> could really use these, don’t know of any cross-platform Swift libraries for
> these
>
>>
>> - math and bignums
>
>
> peep https://github.com/attaswift/BigInt and
> https://github.com/xwu/NumericAnnex
>
>>
>> - networking and HTTP support (client and server)
>
>
> isn’t there a server working group?
>
>>
>> - OS support (including path handling, command line flags etc)
>
>
> YES. currently working on a new URI type to replace the Foundation one which
> is really just a wrapper around NSURL which is in turn a wrapper around
> CFURL. which is bad.
>
>>
>> - Miscellanous stuff like dates, unicode, IO, string parsing, testing,
>> etc.
>
>
> yes
>
>>
>> Go considers all these packages part of the language and offers source
>> compatibility guarantees for all of them. I find the availability of these
>> packages and the fact that they are developed and maintained by the Go core
>> team to be very powerful.
>>
>> We can debate what should be included and if these should be separate
>> modules or not, but I think the key insight here is that they are a curated
>> list of useful libraries that are developed and maintained together with the
>> language.
>>
>>
>> On Wed, Nov 8, 2017 at 9:37 PM, Ted Kremenek via swift-evolution
>> <swift-evolution at swift.org> wrote:
>>>
>>>
>>>
>>> On Nov 8, 2017, at 4:54 AM, Karl Wagner <razielim at gmail.com> wrote:
>>>
>>> On Nov 7, 2017, at 1:58 PM, Ted Kremenek via swift-evolution
>>> <swift-evolution at swift.org> wrote:
>>>
>>> FWIW, Ben Cohen and I have been talking about possibly using Swift
>>> packages as a way to seed out experimental ideas for extensions to the
>>> Standard Library.  This would allow ideas to be trialed by real usage (a
>>> complaint I’ve seen about some changes we’ve made to Swift in the past).
>>> Users could build things on top of those libraries, knowing they are
>>> available as packages, and if an API “graduates” to being part of the
>>> Standard Library the user can then depend upon it being available there.  If
>>> it never graduates, however, the package remains around.
>>>
>>>
>>> Yeah this is exactly the problem that the package manager is there to
>>> solve, right? It’s supposed to make it ridiculously easy to integrate
>>> libraries and manage your dependencies.
>>>
>>> The problem is that most people writing Swift code every day are doing it
>>> to make graphical applications on iOS/macOS. SwiftPM doesn’t support those,
>>> so if I want to test a library, it’s just a one-off thing that I play with
>>> in a Playground.
>>>
>>>
>>> I think that the best thing we could do to encourage people to write, use
>>> and contribute to public libraries would be to improve the package manager.
>>> SwiftPM is still basically a toy (or an interesting curiosity), until it can
>>> actually be used in the projects most Swift devs get paid to work on every
>>> day. Talking about it supporting a community is way premature; it’s not even
>>> close to ready to taking on that responsibility, IMO.
>>>
>>>
>>> I agree that the tooling support around SwiftPM is not sufficiently
>>> advanced yet to support this for everybody.  Further, I don’t think there
>>> would be a need to preclude other ways to share libraries for this purpose,
>>> even if the SwiftPM tooling support was more mature.
>>>
>>> The primary point I wanted to make was more about the model itself.  I’d
>>> prefer the community grow up a set of libraries that trialed and used before
>>> focusing on prematurely baking them into the core Swift distribution.
>>>
>>> _______________________________________________
>>> swift-evolution mailing list
>>> swift-evolution at swift.org
>>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>>
>>
>>
>> _______________________________________________
>> swift-evolution mailing list
>> swift-evolution at swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>
>
>
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>

-- 
Alejandro Martinez
http://alejandromp.com