Makie, a modern and fast plotting library for Julia

Improving the docs as a key point was one of my takeaways from MakieCon. It's pretty time-intensive to work on them as you can imagine, but I hope we'll be able to make the structure more clear and efficient in the future. There should definitely at least be docstrings for every exported struct and so on. But I also want newcomers to get started with less friction, so the explanations/tutorials/how-tos must improve.

This is an easy way for newcomers to help out, by the way, just give feedback on how starting out with the library went and what the main roadblocks were. The better we understand them, the more we can improve them.

Polishing the Docs will be a big thing we want to do with better funding :) Improving APIs and recipes is the other big thing planned for this year.

I pretty strongly disagree here.

The fact of the matter is just that tonnes of bugs, incompatibilities, permission problems, and bad installation experiences every Linux user is intimately familiar with, often occur because package code has no control over which versions or whatever of system-level dependencies like Xorg, Fontconfi, Cairo, etc. are already installed. This also makes it much much easier for package authors to write code which works on multiple OSs without being experts on the details of all those OSs.

Now, if there was no way around this, then you might have a point, but users always can opt-out of binary artifacts like that and point julia to their system libraries instead of the default vendoring of binary artifacts[1]. I think this is the right way to do it. Experts who want to get involved in the nitty gritty details of this stuff and who are also equipped to debug and deal with failures, can opt into using their system libraries, and the rest of us can pay some hard drive space and get a better out-of-the-box experience.

______________________________

[1]: https://pkgdocs.julialang.org/v1/artifacts/#Overriding-artif...

The counterpoint here is that shipping the compiled binaries reduces a ton of uncertainty in terms of package version or compilation with non-standard options (cue potential reproducibility problems). Also different OSes will put libraries in different places (including different Linuxes). The last major benefit is that most OSes require root permissions to install packages, so Julia's approach works a lot better on systems where the user isn't root (e.g. most servers), and also means that the package manager doesn't have to know how to talk to the OS package manager for every OS that we support.

Lastly, if you want use system versions of C/C++ packages, you can do so using the preference system (see https://docs.binarybuilder.org/stable/jll/#Non-dev'ed-JLL-pa.... This isn't the default because it would make package installation a lot more annoying, but for deployment it very well may be what you want to do.

Personally, I like the state now better than a couple years ago, where it was a struggle to get Cairo.jl working because it was interacting with users' systems in weird ways. It admittedly takes much more harddrive space, sometimes to a silly extent. I'm not sure if it's technically possible to have weak binary dependencies, I think if Cairo the C library declares binary deps, we have to add them all (hence Pango, Fontconfig, etc. etc.).

By the way, we get very few installation issues nowadays. They usually have to do with either graphics drivers on Linux, or because people have somehow messed with their library load paths and pull in the wrong dylibs. From a maintainer's perspective it's nice not having to worry about all that too much.

Does it play nice with RStudio? I've had some success using Plots.jl from JuliaCall. However, I sometimes find it easier to just bring a dataframe into R and use ggplot.

To be fair, matplotlib is pretty awful (the API, I mean). I think it might be the worst library I have ever worked with... Though perhaps I'm repressing some memories there.

I'm coming from matplotlib too, though I lack the experience to judge whether its API is any good or not. I just use it. ;-) Much as I love Python, there's always that question lingering in the back of my mind, as to what comes after Python. A compelling plot library would be a major factor.

Yeah the recipes are Plots.jl's strength. We will need more time to get there, I've always felt that the statefulness you get from having interactivity gets in the way of easy composability a bit. In Plots, you assemble one big plot description from recipes that then gets translated to a backend representation once. In Makie (currently) each plot object gets instantiated immediately, ready to go for interaction. But in the future, we might add a layer on top that builds full descriptions first, like Plots, then instantiates at once.

As a side note, package extensions in Julia 1.9 mean that any package can now in principle extend Makie without directly depending on it. That should remove one of the big blockers for adoption, as admittedly, Makie is a heavy dependency to take on.

IMO, the Summary of Julia Plotting Packages article undersells Vega/Vega Lite. They're really powerful and look good.

Makie is almost 100% written in Julia and a pretty big library by now... So not so great ^^ But Julia 1.9 now supports caching binary and we also worked a lot on improving compile times, so after `precompiling` Makie (which, admittedly takes a while), time to first plot can be under a second:

julia> @time using GLMakie

  4.954254 seconds (9.99 M allocations: 617.151 MiB, 7.81% gc time, 0.58% compilation time: 39% of which was recompilation)

  0.780343 seconds (672.09 k allocations: 51.171 MiB, 2.08% gc time, 63.66% compilation time)

I want this to become reality. Are there any IDEs for Julia that come close to the ergonomics and feature set of Pycharm?

There's still one major bottleneck. There's no TF / PyTorch / JAX replacement.

For small things, interop with R is good, so one can defer things to R packages and get access to a great set of functionality.

I don't use it personally, but RCall.jl[1] is the main R interop package in Julia. You could call libraries that have no equivalent in Julia using that and write your own analyses in Julia instead.

[1] https://github.com/JuliaInterop/RCall.jl

A lot of things that would need a library in R can be done in Julia directly. I would suggest doing your analysis in R or python and saving as an Arrow or hfds and then plotting in julia to start with.

Makie is a actually the front end and there are multiple backbends to choose from. I use OpenGL for interactive but Cairo for publishing figures

It's in a different category I would say. For the users, ggplot is mostly about the grammar idea, how you assemble plots from data, geoms, etc. Makie is on a lower level, where you create elements like axes, colorbars, legends etc. manually (with convenience methods, where applicable) and plot things like volume plots or line plots to the axes (like in matplotlib or Matlab for example, but with the whole Observables thing for interactivity). However, the packages AlgebraOfGraphics and TidierPlots are just using Makie's plotting infrastructure to layer a more descriptive plot-building engine on top. There should be nothing in principle that ggplot can plot that Makie really can't, because there are only so many 2D primitives, but Makie has a bunch of 3D stuff that you would not use ggplot for, I'm sure.

My biased view as a coauthor of Makie is that Makie's model is cool because you have a much easier time to combine low-level tinkering with high-level descriptive plots this way. I don't know if you've ever tried hacking the ggplot data structures for special use cases but they are more complex or inscrutable than in Makie, I would say.

Of course, ggplot2 has an amazing and mature ecosystem around it, our ecosystem will need time to fill gap after gap.

TidierPlots(https://github.com/TidierOrg/TidierPlots.jl) aims to provide a 1:1 API compatible ggplots2 implementation on top of Makie.

Works fine for me, specially given I can leverage Makie when I wanted to tweak some stuff.