You always have, and thank you for that.

Also, I think it is important to acknowledge massive progress in some of these ecosystems on Julia. Plots and DataFrames are pretty stable and have a critical mass of features, and the TTFP is good enough. VS Code is stable and has a sufficient number of features at this point.

I donât think basic datascience tasks are the real issue here (and not sure how many of those R/python users you will attract anyways, but that isnât my field).

For open-source competitors, the main issue is the numpy/scipy stack. The standard scientific computing requirements (interpolation, linear optimization, nonlinear optimization, quadrature, solving system of equations, solving a root of a univariate function, numerical linear algebra, and a few others) arenât the âbasicsâ for everyone, but for those having the most problems with the package ecosystemâs quality/feature coverage/discovery it seems to be a common theme. We have talked about discovery, but as Stephen pointed out, part of this is identifying packages with the most resources and being in ânumpy/scipy/pandasâ is an easy way to know it had a lot of resources and is actively maintained.

I brought up interpolation as just one example, but with some obvious exceptions (FFT, anything to do with solving differential equations, SparseArrays, etc.) that whole stack of features I mentioned is tough for users, and even identifying the top starâd package isnât enough. I know the people maintaining a lot of the most starâd packages and respect them greatly, but they are sparse and canât possibly keep these packages maintained without coordinated resources. Matlab/NAG are commercial, but what about scipy? This NEP 48 â Spending NumPy project funds â NumPy Enhancement Proposals probably tells you a lot of what you need to knowâŚ could be wrong, but suspect coordination on package/org funding made it happen.

Of course, there is a tradeoff for focus. Maybe the difficulty of trying to marshalling the ecosystem to ensure it is more accessible for scientific computing users with less programming experience who would otherwise use matlab or python+scipy are resources/energy better spent on other things.

I think it is the wrong test but since you donât use python day-to-day I understand why it made sense to try. A python or matlab scientific computing user wouldnât even consider googling which csv package to use because everything is built in to their basic environment where they import scipy, pandas, numpy, and matplotlib. (Also, while CSV.jl is a good top choice, lets not forget that CSV.jl broke for weeks earlier this year, etc. during which time it was terrible advice!)

Anyways, I am going to stop posting here. I understand where you are coming from completely and why you are puzzled. Thank you for everything you guys have done to make the best language for scientific computing the world has ever seen, and enabling some of the best packages in history for those topics. Hopefully this helps give some context about one part of the package ecosystem. Whether something mitigating these issues is feasible is a separate question.