Julia should be a much easier transition for a python programmer than Swift would be. If your argument is that swift can just be called from python so that the python programmers don't have to touch it directly, then I'd say:

1) That's not the most robust solution, especially for deep learning because auto-diff tools don't cross language barriers well

2) If you have an argument for why 1) isn't a big deal, then the next step would be demonstrating why that argument doesn't apply to julia just as well (if not better) than Swift. In fact, Julia has a great interoperability story with other languages, one good example is DiffEqPy and DiffEqR which are Python and R packages respectively for accessing julia's state of the art DifferentialEquations library.

Still better to learning a language that only works properly on Apple platforms, without any kind of eco-system for scientific computing.

I don't see Tensorflow-Swift going anywhere.

I agree. I looked into it briefly (since I sorta already know Swift anyway and like the language) but I can't even run this stuff on Linux easily, so it's kind of useless for me so far. This doesn't in any way mean that Julia has a snowball's chance in hell of taking off though. Besides the language, Python had a decade of head start in terms of "batteries included". And people have gotten used to that particular brand of batteries.

Is Julia likely to become as massively popular as Python? Probably not. Is julia likely to become much bigger than it already is? Yes, I'd say so.

Julia's value proposition is mostly geared towards people trying to do things that are just too difficult, awkward or slow in other languages. It's not just about speed, dynamism and friendly syntax. It's also about solving the expression problem and providing unprecedented composability.

So while it doesn't have great appeal to end users, it does appeal to people who make the sort of things end users want so the community is currently swelling with very talented people making state of the art research libraries. Honestly, whether these libraries attract hordes of 'scripters' or not, doesn't really matter to julia's usefulness to the people who use it currently.

But I think that as julia's package ecosystem evolves and matures (We've only been at 1.0 for a year!), it's going to get more and more attractive to end users.

I'd like to add that it took the Julia community itself quite a bit to understand what this "value proposition" actually is, especially that it is not just a very nice high level language language geared towards linear algebra that is fast as C and allows some interaction with the type system!

Yes, I fully agree. You can even see the vestiges of this in julia's own official website: https://julialang.org

I cringe a little every time I see a julia advertisement that centres it's premise around "use julia 'cause it's fast!".

I love how fast julia is, but that really isn't the important part.

Julia will add pressure for Python folks to actually take PyPy seriously.

There is a large subcommunity that doesn't enjoy being forced to drop down to C for anything performance.

Julia already counts some banks on their list, that tend to use ML languages instead of Python due to performance.

I feel like a lot of performance could still be extracted from Python libs everyone is using. I.e. NumPy should probably use MKL on Intel out of the box - an easy 2x improvement in performance. On dense linear algebra MKL is pretty impressive. All the stuff that has to happen in Python will be slow as molasses, though, no question there. Parallelization is also currently much harder than it needs to be. I have a bit of code that does elastic deformation on images. It uses a single core for whatever reason (it does call out into numpy and scipy, obviously, this is not done in Python). All my options for parallelizing this suck mightily. I might end up doing exactly what you're opposed to: drop it down to C++ and use pybind, because currently this stuff is single handedly responsible for quadrupling the duration of training runs, which weren't super fast to begin with.

PyPy can't get you all the way there in many cases. Unlike Julia. The real problem with PyPy is Python's semantics. They preclude many essential optimizations to get those final few drops of performance.