[swift-evolution] Swift-based Metal Shading Language

[L. Mihalkovic]

Regards
(From mobile)

> On Jul 10, 2016, at 11:25 AM, G B via swift-evolution <swift-evolution at swift.org> wrote:
> 
> I feel like there are two totally different discussions happening here.  One is whether Swift needs better interoperability with C++, which it does.  Let’s just assume that that will happen.

One of the side effects of a good swift/c++ interop would eliminate the core objections to rewritting swiftc in swift, which IMH would propel forward some of the gaps that exist in the language to be able to do that cleanly. As long as swift remains an app language, completing the generics system or dealing with the question of module/submodule/namespace can be lower priorities with more time to complete.


> The other discussion, which I think was the intended topic of this thread, is whether the benefits of parallel computing can be brought closer to Swift, which I believe they can.
> 
> In most applications, if we can get 80% of the benefit of new hardware with minimal code rewrites, most developers would take that in a heartbeat and focus the specialized talent and careful efforts necessary to craft, profile and maintain truly optimized code on only the most critical kernels.  Maybe that critical code will be written in C++, or some other language better suited to the task.
> 
> Is there a good reason why Swift can’t be made as suitable— or more suitable— than C++ for the 80% kinds of tasks?  It seems to me that Swift would be well suited for it.
> 
> 
> 
> 
>> On Jul 10, 2016, at 01:41 , Goffredo Marocchi via swift-evolution <swift-evolution at swift.org> wrote:
>> 
>> 
>> 
>> Sent from my iPhone
>> 
>> On 10 Jul 2016, at 08:50, Georgios Moschovitis <george.moschovitis at icloud.com> wrote:
>> 
>>>> working on C++ compatibility/interaction is  still quite key because of the mountains of legacy and new code still written everyday in it.
>>> 
>>> Totally agree, but C++ interoperability is orthogonal to my original request. Would love to have both!
>>> 
>>>> Also, I think that the right language for the right domain and being able to glue them together is quite key in the modern computing world and using a single language in every computing domain is a chimera that can bring more pain than good.
>>> 
>>> I disagree. IMO, the ‘babel’ of programming languages is one of the most annoying problems in our industry. Besides, I don’t see how C++ is any more suitable than Swift for GPU/heterogenous stuff (without peculiar extensions like CUDA). Swift is starting from a clean-slate, and could definitely become a ‘right’ language for this domain.
>> 
>> Also, call me when we get a port of either OpenCL or CUDA bindings in Swift. Hint: it is more likely for Swift to have working C++ integration first than to wait for those to happen.
>> 
>> We can talk about Swift, Rust, Kotlin, Eiffel, Scala, etc... but they are still relatively niche and before any of those gets anywhere near the strong worldwide cross platform following that JavaScript (with the explosion of Node.JS too), Ruby, C/C++, Java, and C#/.NET still have, we will need to keep nurturing and strengthening this language and tools for a while longer.
>> _______________________________________________
>> 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