I switched permanently from Plots.jl to Makie.jl in order to have backend-agnostic fine-grained control. My publication plots look fantastic and the power given to users is really something. It also has a nicer API than Plots.jl once you get a hang of the figure, axis, plot distinction (plots live inside axes live inside figures) and what goes where.
Unfortunately, as with Plots, the documentation is lacking. The basic tutorial does a good job introducing the aspects of the package at a high level, but the fact that some parts of the documentation uses functions/structs that don't have docstrings in examples makes it very hard to build on the examples in these cases.
I get it, I can do anything with Makie, and most things that I want to do work amazingly. But my code for a single figure can get huge because it's all so low level. See, for example, the Legend documentation[1].
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.
One annoying thing about trying to install Makie (although it would be silly to blame Makie for it) is that installing it pulls a ton of compiled C/C++ binary dependencies. I'm talking Fontconfig, Xorg(!?), Cairo, a bunch of audio and video codecs and compression libraries, among other things. Most/all of these are transitive dependencies, though. And all of these are already installed system-wide, independently of Julia.
Although Julia is my favorite PL by far, it's sometimes shocking how easily the Julia community sidesteps traditional programming values. Often this turns out to be a good thing, but the above issue is surely not a good example. I'd very much prefer to leave the work of packaging all those to the Archlinux maintainers.
EDIT: to be clear, this is more of a Julia-wide issue than a Makie issue. Or partly an issue with some of the Julia packages that Makie depends on. But Makie is perhaps the worst offender among the popular packages (transitively).
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.
> 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.
I can tell you I had orders of magnitude more issues with inferior (and I have yet to encounter one which is anywhere close to a system package manager) language package managers. The main issue that one might encounter (especially with super stable packages like Cairo or fontconfig), is that the package one wants to install uses some feature of the most cutting edge release and the system has an older release.
The consideration of not always using the latest and greatest and considering only stable releases seems to have completely gone missing and people just argue to install everything via virtual environments or docker containers. So we end up with tons of different versions of the same library all over the place.
Regarding Julia being not public facing and security being not an issue, that someone else mentioned somewhere else down the thread, this package builds interactive dashboards. That's pretty public facing to me.
It's fairly easy, if not super user friendly, to opt out of the Julia-vendored binaries though.
If you've ever tried to install CUDA related packages from a poorly configured Python environment you'll have encountered this issue. On the vast majority of machines if you want to use CUDA.jl you just add it as a dependency.
There's a reason much of Julia's audience uses things like Spack or even static dependencies in their non-Julia code. If you just want to get work done fussing with PATH issues or the right version of CMake/gcc/LLVM-OMP etc etc can take hours.
Once you've gotten the work done, and you know it will load on most users computers, you're ready to deploy. Then just add an Overrides.toml to your environment.
From the other side, just like websites there is a barrier caused by "please install W, X, Y, Z dependencies" vs "Pkg.add("GLMakie")"
Actually I would argue the reason that every language is inventing their own poor package manager, is because other OS don't have proper package management.
As I said in the previous post, I hardly ever have issues with my system packages. Helping people set up an environment to develop cython code for windows on the other hand is an absolute nightmare.
I agree. Since nowadays the disk space saving argument is almost irrelevant the only thing in favor of shared libraries seems to be the automatic improvement of all dependents with one update. But I think history has shown that this is a major source of incompatibilities and since Julia software is not really supposed to be running public facing services the security argument is moot anyways.
> since Julia software is not really supposed to be running public facing services
Who said that? As far as I know, it was always intended as a general purpose language, and in my opinion, it’s already a pretty good one (and rapidly getting better), except for the fact that the library ecosystem is still limited in some areas.
If each package vendors its own deps, when the dep has a security vulnerability and needs an upgrade you need to hunt down every last location it exists in, instead of updating the single shared system dep and being done with it.
Apart from what sibling said, another issue is explosion of trust assumptions.
On my system, I obviously have to trust the Archlinux project not to serve me malware. When using Julia, I additionally have to trust the Julia project not to serve me malware. (See also: Python, Node, etc.) Obviously: less trust is better for security, ideally almost all installed software would be signed by Archlinux maintainers.
For comparison, the situation is kind of similar for Apple users; but on Windows, trust is extremely watered-down anyway (with or without Julia or Python etc.).
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.
Makie is a modern plotting library for Julia. It is easy to use, fast and powerful. Packed with features, it is a general-purpose tool that makes as few compromises for specialized use cases as possible.
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.
Coming from matplotlib, I found Makie such a breath of fresh air. The API is just as (if not more) flexible but way more predictable. Their layout system in particular is amazing. I think it bundles it's own constraint engine?
Congrats on the new website!
PS. Thanks to the Makie team for the shoutout to my corner plot package in the ecosystem section!
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.
The best plotting APIs I have seen are those from MATLAB and Mathematica. I have used Makie a few times, and it is very flexible and well designed.
I am hoping they provide a declarative API that emulates Gadfly more closely. Gadfly is great for simple statistics, sort of a Julia equivalent to ggplot2.
Matplotlib is heavily inspired by MATLAB's plotting, no? Its pyplot submodule is a wrapper around the base OO API which is an almost exact clone of matlab.
Matlab and Mathematica are awesome. Gadfly had a great API but suffered greatly from Julia's ttfp problem. Tried makie, looked good but that was around when I left Julia (just because other langs paid). VegaLite is pretty amazing.
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.
Useful, because the wealth of choices confuses people.
I stick with Plots.jl because of the recipe system. This is Plots’ secret weapon. If you create a package with its own data types, you can include instructions telling Plots how to visualize them. The user then need simply type
plot(custom_type; etc.)
to get the custom visualization. And the package need not include Plots as a dependency for this to work. This is only one of the things the recipe system can do.
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.
Absolutely insane visuals - that does really make me want to play around with Makie. Bravo!
Traditionally, time to first plot has been awful in Julia. I remember using about 30 seconds back in 2018 to render my first Gadfly image. How is Makie doing on this front?
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)
julia> @time display(scatter(1:4))
0.780343 seconds (672.09 k allocations: 51.171 MiB, 2.08% gc time, 63.66% compilation time)
The most IDE-ish experience is probably currently the vscode plugin. I haven’t used pycharm specifically for comparison, but I suspect “probably not” as compared to a polished paid IDE in general. There’s progress being made though.
What do you mean by that? AFAICT for the most part Julia is already like the best that Jax could ever hope to be — since there is language level support for JIT compilation, gradients, etc — given how well libraries compose without having to pick different incompatible subsets of the language.
That's right, but at the same time Flux, the default choice is not mature at all compared to JAX. So that advantage is only on paper.
I would really prefer to use Julia, I actually dislike Python, but it's unrealistic to implement large architectures in Flux. It is buggy, lots of gradient calculations are unreliable.
Ah, I see. There’s XLA.jl for TPUs and a bunch of stuff from the JuliaGPU organization for GPUs — I wonder how they compare with TF/PyTorch/JAX.
I’m curious to get perspectives on what remains to be done to solve the missing piece, and what are the biggest challenges to overcome (assuming one gets access to the appropriate low level APIs on top of the hardware — like OpenAI’s Triton).
It seems like there's a lot of libraries for plotting in Julia now. Does anyone know how good interoperability between Julia and R is? I have a lot of workflows in R and Python using some pretty niche bio informatics libraries, but Julia just seems...better.
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.
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.
I'm not interested in Julia, but this is pretty awesome stuff. It looks like it is built right on top of OpenGL and WebGL. How foes one go about learning to accomplish and develop this type of thing?
I recall seeing something that built on Cairo and provided something that had basic 3d interaction on top of an iterative 2d render a long time ago. So there are projects that do more direct implementations but I'm not sure if they have stable glue to Make yet. This is the sort of thing I hate dealing with directly so I usually just say, " hey that's interesting" and wait for a stable release
Great package & community... As someone who was new to both julia & makie, the community was helpful. & what Makie lacked in documentation at the time, the authors were active in various forums for community questions. thanks Simon & krumbie
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.
in terms of being the only charting library to update based on diffs, this might be true for julia but javascript charting libraries have been doing this for a while. my favorite is echarts.
I don't think we claim we are the only library that uses something like Observables, as you say there are others that do. VegaLite also uses a signal mechanism for interactivity, for example. Makie has been inspired by many libraries that came before (although I can't say that I knew echarts, specifically :) )
Every plotting library has something to offer, there are so many choices to make when building one that you can't cover everything. I envy the pure javascript libraries a little for their easy embedding in websites. But when you already do data work in Julia, especially with custom types and such, it's nice not having to move across a language barrier, and instead make use of Julia's multiple dispatch some more by using a native plotting library.
We're not using diffing! Diffing has a pretty big overhead for calculating the shadow dom and going through all values and seeing if they're the same, which can be very expensive for huge plots. We use signals that get wired through from the user up to the gpu, so if the user changes something, it gets immediately and directly changed on the gpu too! that's very different from diffing and much faster..
We're surely also not the only ones doing something like that, but Alex is referring to the whole package of Makie offering the ui, performance, simplicity and visuals to do this easily
ok, that’s interesting. The other libraries don’t diff the dom either (so many different diffs in this world) but compare the chart configuration and use this to determine what’s changed. And when you provide a partial configuration the existing stuff is implicitly left unchanged, so only new data is compared.
Looks like you've been voted down. Mb the reason is the following:
> In particular, do not sexualize the term "Julia" or any other aspects of the project. While "Julia" is a female name in many parts of the world, the programming language is not a person and does not have a gender.
Unfortunately, as with Plots, the documentation is lacking. The basic tutorial does a good job introducing the aspects of the package at a high level, but the fact that some parts of the documentation uses functions/structs that don't have docstrings in examples makes it very hard to build on the examples in these cases.
I get it, I can do anything with Makie, and most things that I want to do work amazingly. But my code for a single figure can get huge because it's all so low level. See, for example, the Legend documentation[1].
[1]: https://docs.makie.org/stable/examples/blocks/legend/index.h...