[swift-server-dev] Crypto Library
babt at me.com
Sat Nov 12 10:00:30 CST 2016
I absolutely agree. Why re-invent the wheel? Existing libraries that would be chosen are most likely “battle tested and proven”. To redo all that in Swift seems to me to be a waste of valuable time. There’s a lot more other work that needs to be done to make server side Swift successful and if that means reusing and leveraging existing “C” code, so be it.
> On Nov 10, 2016, at 3:02 PM, Chris Lattner via swift-server-dev <swift-server-dev at swift.org> wrote:
>> On Nov 8, 2016, at 2:18 PM, Helge Heß via swift-server-dev <swift-server-dev at swift.org> wrote:
>> On 8 Nov 2016, at 16:45, Chris Bailey via swift-server-dev <swift-server-dev at swift.org> wrote:
>>> Whilst there's legitimate debate on the use of C vs. Swift for HTTP parsing, I think the situation for the security libraries in general is more clear.
>> This is really a bit off topic but I disagree with that. Either you:
>> a) are OK with C libs and deal with it
>> b) deal with C libs as a temporary measure but the goal is Swift
>> c) reject C libs from the start
> Just my personal opinion, but I don’t see why “pure swift” is a goal or even interesting to thing about. The goal should be provide expressive and natural Swift APIs for server development tasks. The implementation should not show through that API.
> If (and only if) there is some advantage to rewriting C code in Swift (e.g. for performance, memory, correctness, or capability reasons) then it is certainly interesting to talk about that of course.
> A relevant comparison is to corelibs-foundation, which uses a significant amount of C code in its implementation.
> swift-server-dev mailing list
> swift-server-dev at swift.org
More information about the swift-server-dev