Warning: this is going to be a long one…
This is about using libraries that build on top of (incompatible with JAX) TF APIs, in which case you might as well compare against PyCall.
The reason you didn’t see it is because we’ve had many, many threads about this in the past year alone with all of the arguments made thus far and more! I’m sure “breaking point” has appeared at least a dozen times. Doesn’t make your points less valid, of course, but @anon92994695 and others on this forum are no stranger to them.
My personal impression is that Julia’s ML ecosystem was hyped a too hard around 2018-early 2019 and burned many people (including yourself, I assume) who weren’t expecting to face sharp edges or pay the early adopter tax. Continuing with the hype cycle analogy however, I think we’re starting to emerge from the trough of disillusionment. In other words, you’ll see less flashy evangelism about Julia, but more and more users behind the scenes.
I used to think this too, but I think a fairer explanation would be that us ML folk are in a different bubble 
. Let me explain:
I have been playing around with Julia ML off and on for over a year now. I say "
off and on" because I usually end up digging myself out after accruing many, usually small, frustrations. This includes (but is far from limited to):
- Import times
- Debugging and AD errors
- IDE tooling
- Gaps in the library ecosystem (augmentation, preprocessing, layers, etc.)
- No multi-GPU or easy auto-scaling. No, MPI doesn’t count.
So pretty much your list from earlier. More than once, I was unsure why I was even bothering to spend more time on this.
But then, I’d go on Slack or Discourse and see something amazing done by non-ML Julia users. Like all of the crazy econ models that run lightning fast and fit in a page of code. Or the geo/climate models that can run on a cluster with minimal work. Or @tamasgal’s amazing series of posts about why Julia is such a breath of fresh air in particle physics (worth a read for any JAX advocates).
And then I’d remember wanting to put a hole through my monitor the day before when conda went into a dependency resolver death spiral for the umpteenth time (hyperbole, but I’m sure you can relate). Or the week before that wasted wresting with numpy and pandas to run parallel preprocessing on 10GB (not TB, GB) of data without triggering Python’s GIL and/or blowing up my machine’s RAM. Or the headache I’ll have to deal with tomorrow because some DL library pulled of a set of incredibly dirty and fragile hacks that would be trivial to implement with multiple dispatch.
In the ML community, Julia is language with a small minority of users. But in the Julia community, we are the minority. I’d be happy to use Julia for ML work in the next decade, but I do think it’ll happen. To use the example of another LLVM-based language:
- Despite much naysaying, Rust carved out a niche alongside C/C++ and is steadily gaining steam.
- Unlike Rust, Julia already has a healthy ecosystem across multiple domains and organizations.
- As the ML community grows and research focuses shift, more and more users are going to become frustrated with Python and start shopping for alternatives. In other words, growth means that language mindshare is not a zero-sum affair.
- More domain experts are going to be learning ML than ML people gaining domain knowledge. Julia has been pretty good at attracting the former crowd, so I don’t anticipate being alienated any time soon.
One thing Julia DL is lacking are more developers with solid ML experience who are willing to put in the work to flesh out the ecosystem. I’m not sure if/how there’s a good way to make this happen, but it would be a huge help.