Swift can import C (and C++) modules directly, and it's fairly straightforward to wrap existing C APIs with callbacks to be usable from structured concurrency. Here's an example I just worked on. [1]

[1] https://github.com/PADL/NetLinkSwift

This is not what holding swift.

What's holding swift is not having a good story to call a swift compiled extension from Python/JS/Ruby/PHP.

Python's community is huge, very active, Python is everywhere, and it needs compiled extensions. And tooling to make them BFF, like pyo3 and maturin, is great

And that's how we got cryptography, pydantic core, polar... Which motives even tooling to be written in rust as a side effect, and how we have uv and ruff.

The scripting community is the most active, if you got them on your side, you get access to a huge pool of devs.

What Python needs is to catch up to SELF, Smalltalk, Common Lisp, and either embrace PyPy, or finally get a mature JIT into CPython.

Thankfully, Facebook and Microsoft are making it happen.

Yes, but it's a completely unrelated matter: even with a JIT you'll want compiled extensions since you can't beat hand crafted SIMD for the scientific stacks or machine learning.

Ever heard of intrinsics?

Maybe spend some time reading about other JIT languages expose SIMD to developers, without requiring folks to go down to C.

Which incidentally is what all those Python DSLs for GPGPU APIs also do, with the caveat of not being that useful for general purpose programming outside machine learning algorithms.

I'm not sure scripting-language interop is holding back Swift, but ...

> call a swift compiled extension from Python/JS/Ruby/PHP

The story there is excellent.

Here's a Swift function callable from C

    @cdecl("myfunc")
    public static func f(){...}

C/C++ types are mostly handled automatically (including sharing memory management), but it can be tricky.

To build a library to load and call from any language:

    swiftc mine.swift -emit-library -o libmine.dylib 

E.g., calling from java 22 FFI:

https://foojay.io/today/java-panama-polyglot-swift-part-2/

But most people instead use a slower json server network interface because (sadly) json is the lingua franca for scripting and Swift Codable makes it trivial to map the json to a swift type.

Try to make Rust interop with C++, C and Objective-C as easy as Swift does it.

This is a big deal. In reality, most of the code that powers your systems (phones, tablets, any computers) is built using C and C++, regardless what OS you use.

Agreed, and rust-c interop is as good as any other I've used. The c++ interop was clunky but getting much better with crates like zngur. That is what was holding back its use on chrome for a while. Oddly its python interop is way better with pyo3 and maturin making it super easy.

C++ is (IME) an order of magnitude more annoying from Rust than C or Objective-C. I've dealt with interop of the latter two on a number of projects and frankly found them to be fine.

(Though I wouldn't fault anyone for making an argument that Swift is still more ergonomic here)

swift-wasm exists