I'm not sure if the Swift type system is half way decent in terms of machine learning applications. At least not without a lot of work. The data tends to be in specialized in-memory formats that tend to be opaque to the type system. The actual matrix operations involve dimension parameters that are likewise opaque to most type systems. So you still need to run code for the actual tensor graph compilation to validate if everything is correct. Python in notebooks does that instantly, Swift I suspect has a much longer delay.
I don't see any reason the swift type system could not accommodate the types required for ML. I did a lot of work with computer graphics in Swift, which is all linear algebra also, and the type system was a huge benefit.
Also I don't see why Swift would perform worse than python in any case. If python is fast, it's because it's wrapping a C++ library. There's no reason Swift could not wrap the same library, but on top Swift could communicate better type information back to the user.
In addition to what the sibling said, a big part of the S4TF project was proposing changes to Swift's type system. I'd also point out that there are not one, not two, but three type checkers looking into tensor typing for Python. What's more, Guido is on that committee!
Which is sort of my point. If you have to rewrite or expand significant parts of the the type system anyway is there any advantage over just doing the same work for Python?
There's many other advantages of Swift over Python for ML (concurrency and performance) but I just don't see the type system as one. At least not anymore.
I mean yes, because a) there's less to change, b) you still have nice features like protocols and c) Python's type system is pretty unsound. My point was that saying ML is too complex for type systems is really a cop out, and that has been borne out by how many languages have started experimenting with more complex types for this exact purpose.