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 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.
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)
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?
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
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.
[+] [-] martinsmit|2 years ago|reply
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...
[+] [-] krumbie|2 years ago|reply
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.
[+] [-] simondanisch|2 years ago|reply
[+] [-] nsajko|2 years ago|reply
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).
[+] [-] eigenspace|2 years ago|reply
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...
[+] [-] adgjlsfhk1|2 years ago|reply
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.
[+] [-] krumbie|2 years ago|reply
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.
[+] [-] simondanisch|2 years ago|reply
Try it out today: install Julia and https://julialang.org/downloads and in the Julia REPL run:
]add GLMakie
using GLMakie
scatter(1:4)
[+] [-] wjholden|2 years ago|reply
[+] [-] wthomp|2 years ago|reply
PS. Thanks to the Makie team for the shoutout to my corner plot package in the ecosystem section!
[+] [-] quasarj|2 years ago|reply
[+] [-] analog31|2 years ago|reply
[+] [-] leephillips|2 years ago|reply
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
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.[+] [-] krumbie|2 years ago|reply
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.
[+] [-] nsajko|2 years ago|reply
[+] [-] jakobnissen|2 years ago|reply
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?
[+] [-] simondanisch|2 years ago|reply
julia> @time using GLMakie
julia> @time display(scatter(1:4))[+] [-] atulvi|2 years ago|reply
[+] [-] isoprophlex|2 years ago|reply
[+] [-] nextos|2 years ago|reply
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.
[+] [-] wodenokoto|2 years ago|reply
I’m not using Julia, so I really don’t know about the library, but it seems like it has a very strong community
[+] [-] HDMI_Cable|2 years ago|reply
[+] [-] krumbie|2 years ago|reply
[1] https://github.com/JuliaInterop/RCall.jl
[+] [-] twobitshifter|2 years ago|reply
[+] [-] bmitc|2 years ago|reply
[+] [-] NeuroCoder|2 years ago|reply
[+] [-] jbdistaken|2 years ago|reply
[+] [-] operator-name|2 years ago|reply
[+] [-] krumbie|2 years ago|reply
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.
[+] [-] cjalmeida|2 years ago|reply
Works fine for me, specially given I can leverage Makie when I wanted to tweak some stuff.
[+] [-] tkuraku|2 years ago|reply
[+] [-] twobitshifter|2 years ago|reply
[+] [-] krumbie|2 years ago|reply
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.
[+] [-] simondanisch|2 years ago|reply
[+] [-] asdfman123|2 years ago|reply
[+] [-] chrispeel|2 years ago|reply
> 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.
from https://julialang.org/community/standards/