A plotting library is one of those things that is really difficult for a research community to support because
a) it doesn’t really change research
b) limited types are necessary at the very bottom (your eye can’t see the difference between Float64 and Float32 in terms of relative scale, so just convert)
c) The limited types means that even ancient C++ libraries do about the same thing and are already optimized.
For this reason, the Julia community has worked on new interfaces specifically for solving (b): how do you automatically convert types to plottable types? This is the innovation of the recursive recipe system of Plots.jl (Recipes · Plots). However, in terms of plotting itself, even Plots.jl just calls into established backends.
One spot where there is innovation to be had is in GPU acceleration. Not too many people are plotting things with the billions of data points with interactivity that is required to make this useful, but it is something that is starting to come up more and Makie.jl is a library for handling that, which is pure Julia (GitHub - JuliaPlots/Makie.jl: High level plotting on the GPU.). It is quite far along.
For more of a traditional plotting library in pure Julia form, there’s https://github.com/GiovineItalia/Gadfly.jl , but it’s limited to 2D so it works well for data science workflows but not general technical computing. This is somewhat because the development efforts grow fast with 3D of course.
A plurality of the community uses Plots.jl, then there’s sizable communities around PyPlot.jl, Gadfly.jl, Makie.jl, and VegaLite.jl. Then there’s a long tail of Winston.jl, Plotly.jl, InspectDR.jl, PlotlyJS.jl, UnicodePlots.jl, etc. Plots.jl lets you swap backends to use many of these, so you can just learn plots and get the different displays and call it a day, which is what a lot of people do. In the end, there’s a pretty bustling plotting community with anything a researcher needs, but without a focus on purity, and quite frankly I think that’s okay.