I would like to challenge you on many of these point. You will have to elaborate a bit to convince me that these are genuine concerns.
1. VSCode already has great Julia support. How is VSCode not professional enough?
2. Why Keras, TensorFlow and Torch, when IMHO Flux and other Julia machine learning libraries are superior. Why? Because Flux easily integrates with almost anything in the Julia community while TensorFlow and PyTorch use a monolitc inflexible design.
3. Partially agree.... but R, Python, Ruby, Matlab doesn't really have this either, now do they. Love to see this on Julia, but why is this a deal breaker?
4. What is wrong with existing Plotting libraries like Plots? I don't know ggplot2, so this is an honest question.
5. A lot of this actually exists. Tom Kwong has a great design patterns book. I have also written a Julia book, Julia for Beginners which covers OOP programmin in Julia. Julia Machine Learning and High Performance computing books also exist
6. Yes, higher education support could get better, we are seeing growth there.
But I could try to piggy back on some of th issues you raised to say what I think is a problem:
- The Julia machine learning story needs better documentation and explanation. Flux is great. But getting beginners to really understand this power and how you combine libraries is not well enough documented.
- While AOT in principle isn't needed, I think it is a way for Julia with such a small community to get a foot in the door. It would allow Julia to have easier distribution than Python, which could help drive adoption.
- Lots of books are now available on Julia. But one needs more variety of style and especially beginner books for people who don't know Julia at all.
- First-time-to-plot would still need improvement. If one could get really fast startups either through better pre-compilation or trace JITing I think it would improve the appeal.
Library Polish and Documentation
Outside the most popular libraries, documentation and polish is kind of lacking. We need more comperhensive documentation, and smoothing of some rough edges.
E.g. I noticed that a lot of the common HTTP stuff you would want to do just isn't documented well enough in the HTTP.jl package. We need more examples and better covereage of all functionality.
