A somewhat extreme alternative could be the use of IDLs and "libs as services“:

A Python lib could aditionally expose its APIs (or a relevant subset of it) via 
an IDL. Generators would help with the necessary stub and skeleton code on both 
Python and Swift sides.

My impression is that only big libs like TensorFlow are relevant to be bridged 
anyhow so that the effort to create an IDLized API for that community is 

IDLs are an old idea but they seem to get reinvented every now and then. Google 
has a new one called FIDL for its Fuchsia project: 


> Am 01.12.2017 um 17:07 schrieb Jon Gilbert via swift-evolution 
> <swift-evolution@swift.org>:
> On Dec 1, 2017, at 02:44, Xiaodi Wu via swift-evolution 
> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
>> So the use case here is, how do we make Swift a viable candidate for doing 
>> those things which today drive users to Python? The answer here is _not_: 
>> build a better Python. Nor does it require, out of the gate, even being as 
>> good as Python. The solution is to provide a _reasonably_ ergonomic to 
>> _interoperate with libraries available in Python_, with the benefit that 
>> those parts that you can write in native Swift will make the overall result 
>> safer and faster, etc.
> I think we would be better served by a transpiler that translates Python 
> (etc.) into Swift at compile time. 
> Look what Google did with j2objc (https://github.com/google/j2objc 
> <https://github.com/google/j2objc>). It translates Java right into Objective 
> C. You can even put your Java code right in XCode and it auto-translates at 
> build time. 
> Clearly, this is no small feat, and j2objc is a technical marvel that took 
> world-class engineers years to perfect. 
> My point is, “Dynamic Member Lookup” is not the only solution, and it’s not 
> the ideal solution if indeed it compromises the static guarantees of Swift.
> Therefore, we should consider what other approaches might entail. The main 
> players in Swift have lots of money and technical resources they could pour 
> into a set of revolutionary transpilers. 
> Surely we don’t want to allow Goole to be the only company to provide a 
> library that translates other codebases directly to a primarily Apple 
> language, do we?
> That being said, I am still interested to hear Chris’s response to these 
> concerns, and if they were already addressed on a previous message and I 
> missed that, then please forgive me.
> - Jon
> _______________________________________________
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

swift-evolution mailing list

Reply via email to