[swift-server-dev] Crypto Library

[Bill Abt]

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.

-Bill Abt

> 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.  
> 
> -Chris
> _______________________________________________
> swift-server-dev mailing list
> swift-server-dev at swift.org
> https://lists.swift.org/mailman/listinfo/swift-server-dev