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.