7 ms·
Makie, a modern and fast plotting library for Julia
- simondanisch 3y agoMakie 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. Try it out today: install Julia and https://julialang.org/downloads https://julialang.org/downloads and in the Julia REPL run: ]add GLMakie using GLMakie scatter(1:4)
- wjholden 3y agoDoes 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.
- wthomp 3y agoComing 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!
- quasarj 3y agoTo 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.
- nextos 3y agoThe 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.
- throwawaymaths 3y agoMatlab 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.
- auxym 3y agoMatplotlib 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.
- velsi 3y agoCheck: https://github.com/MakieOrg/AlgebraOfGraphics.jl https://github.com/MakieOrg/AlgebraOfGraphics.jl
- nextos 3y agoI know about this. It's heading in the right direction, but still lacks many Gadfly features, let alone ggplot2 ones.
- patrec 3y agoHave you used pandas? :)
- analog31 3y agoI'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.
- jakobnissen 3y agoAbsolutely 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?
- simondanisch 3y agoMakie 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)
- adgjlsfhk1 3y agoAlso get hyped for 1.10 (alpha coming soon) (1.9 included because my computer is apparently slower than simons): 1.10: julia> @time using GLMakie 3.350991 seconds (3.62 M allocations: 224.447 MiB, 5.41% gc time, 0.55% compilation time) julia> @time display(scatter(1:4)) 0.799333 seconds (410.41 k allocations: 39.615 MiB, 2.36% gc time, 76.37% compilation time) 1.9: julia> @time using GLMakie 8.004230 seconds (10.56 M allocations: 643.198 MiB, 5.43% gc time, 0.49% compilation time: 47% of which was recompilation) julia> @time display(scatter(1:4)) 1.096839 seconds (681.36 k allocations: 53.541 MiB, 2.42% gc time, 74.83% compilation time)
- nsajko 3y agoTo clarify the above, precompilation usually only happens when installing or upgrading the packages.
- martinsmit 3y agoI 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]. [1]: https://docs.makie.org/stable/examples/blocks/legend/index.html#multi-group_legends https://docs.makie.org/stable/examples/blocks/legend/index.h...
- simondanisch 3y agoPolishing 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.
- krumbie 3y agoImproving 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.
- operator-name 3y agoDoes anyone have any experience for how this compares to R's ggplot2?
- cjalmeida 3y agoTidierPlots(https://github.com/TidierOrg/TidierPlots.jl 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.
- krumbie 3y agoIt'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.
- atulvi 3y agoJulia is looking more and more like a viable alternative to Python's data science stack.
- isoprophlex 3y agoI want this to become reality. Are there any IDEs for Julia that come close to the ergonomics and feature set of Pycharm?
- cbkeller 3y agoThe 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.
- nextos 3y agoThere'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.
- ssivark 3y ago> There's no TF / PyTorch / JAX replacement 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.
- the_svd_doctor 3y agoI mean, yes but also no. JAX will JIT on accelerators OOTB and has outstanding (imho) support for multi node. Julia does not have that OOTB AFAIK. Now I agree that Julia, with its JIT, is well positioned to do all this. But I don’t think it does.
- HDMI_Cable 3y agoIt 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.
- twobitshifter 3y agoA 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.
- krumbie 3y agoI 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 https://github.com/JuliaInterop/RCall.jl
- twobitshifter 3y agoin 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.
- krumbie 3y agoI 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.
- nsajko 3y agoTangential: No Grammar to Rule Them All: A Survey of JSON-style DSLs for Visualization https://arxiv.org/abs/2207.07998 https://arxiv.org/abs/2207.07998 Both Vega and Echarts are covered, among others.
- twobitshifter 3y agoThanks, I was looking at the quote from Alex Gardner under the discussion of observables. It might be I’m misinterpreting what was meant by that.
- simondanisch 3y agoWe'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
- nsajko 3y agoOne 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).
- adgjlsfhk1 3y agoThe 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-packages) 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.
- deleted 3y ago[deleted]
- krumbie 3y agoPersonally, 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.
- leephillips 3y agoChris Rackauckas has put together a valuable guide to the Julia plotting ecosystem here: http://www.stochasticlifestyle.com/summary-of-julia-plotting-packages/ 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.
- krumbie 3y agoYeah 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.
- nsajko 3y agoIMO, the Summary of Julia Plotting Packages article undersells Vega/Vega Lite. They're really powerful and look good.
- asdfman123 3y agoWhy does Julia get her own plotting library? Unfair.
- chrispeel 3y agoLooks 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. from https://julialang.org/community/standards/ https://julialang.org/community/standards/
- asdfman123 3y agoNah, it's not because I'm being appropriate, it's because it's a cheesy joke that Julia devs are probably sick of. (I know when I'm going to make cheesy jokes, but don't always stop myself like I should :)
- wodenokoto 3y agoI was quite impressed to see they have their own online conference. I’ve never heard of GGcon or matplotlibcon. I’m not using Julia, so I really don’t know about the library, but it seems like it has a very strong community
- bmitc 3y agoI'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?
- NeuroCoder 3y agoMakie is a actually the front end and there are multiple backbends to choose from. I use OpenGL for interactive but Cairo for publishing figures
- bmitc 3y agoRight, but that means that someone implemented the backend interface. Also, does Cairo support all the features? I thought Cairo only supports 2D graphics, but I see several 3D style graphics in the demos.
- NeuroCoder 3y agoI 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
- tkuraku 3y agoMakie has been far superior to Plots.jl in my experience.
- jbdistaken 3y agoGreat 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