[HN Gopher] Makie, a modern and fast plotting library for Julia
___________________________________________________________________
Makie, a modern and fast plotting library for Julia
Author : simondanisch
Score : 190 points
Date : 2023-07-04 15:22 UTC (7 hours ago)
(HTM) web link (makie.org)
(TXT) w3m dump (makie.org)
| nsajko wrote:
| 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).
| krumbie wrote:
| 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.
| adgjlsfhk1 wrote:
| 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.
| [deleted]
| eigenspace wrote:
| 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...
| WanderPanda wrote:
| 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.
| eigenspace wrote:
| > the security argument is moot anyways
|
| Sorry, I'm missing something, what security concerns are
| you referring to?
| chaosite wrote:
| 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.
| somsak2 wrote:
| we just need better tooling for upgrading the individual
| locations. something like GitHubs dependabot
| nsajko wrote:
| 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.).
| nsajko wrote:
| > since Julia software is not really supposed to be running
| public facing services the security argument is moot
| anyways
|
| 1. both Julialang.org and Juliahub.com run Julia as far as
| I understand
|
| 2. even if your premise were true, it wouldn't be
| acceptable for the Julia project to condone pwning of Julia
| users
| cycomanic wrote:
| > 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.
|
| 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.
| patagurbon wrote:
| 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")"
| bmitc wrote:
| This seems much more like a critique of Linux than any
| language or package development.
|
| And Linux is particularly a nightmare when it comes to
| graphical things.
| cycomanic wrote:
| 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.
| adgjlsfhk1 wrote:
| Have you used Julia's package manager? Imo, it works
| better than apt and snap (I don't have enough experience
| with RPM/flatpack to compare)
| bmitc wrote:
| I would say most language package managers I have used
| are easier than than any Linux package manager I have
| used.
| simondanisch wrote:
| 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.
|
| 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 wrote:
| 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.
| bmitc wrote:
| 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?
| HDMI_Cable wrote:
| 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.
| twobitshifter wrote:
| 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.
| krumbie wrote:
| 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
| jakobnissen wrote:
| 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?
| simondanisch wrote:
| 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)
| adgjlsfhk1 wrote:
| Also 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 wrote:
| To clarify the above, _precompilation_ usually only happens
| when installing or upgrading the packages.
| wthomp wrote:
| 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!
| quasarj wrote:
| 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.
| nextos wrote:
| 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.
| auxym wrote:
| 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.
| velsi wrote:
| Check: https://github.com/MakieOrg/AlgebraOfGraphics.jl
| nextos wrote:
| I know about this. It's heading in the right direction,
| but still lacks many Gadfly features, let alone ggplot2
| ones.
| throwawaymaths wrote:
| 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.
| patrec wrote:
| Have you used pandas? :)
| analog31 wrote:
| 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.
| atulvi wrote:
| Julia is looking more and more like a viable alternative to
| Python's data science stack.
| nextos wrote:
| 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.
| enkursigilo wrote:
| How about Flux.jl?
| ssivark wrote:
| > 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 wrote:
| I 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.
| ssivark wrote:
| 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).
| patagurbon wrote:
| XLA.jl is essentially abandoned, no funding IIRC. Coil.jl
| and maybe some future hypothetical work on MLIR.jl could
| bridge the gap pretty easily.
| nextos wrote:
| 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.
|
| See some discussion here for instance:
| https://kidger.site/thoughts/jax-vs-julia
| isoprophlex wrote:
| I want this to become reality. Are there any IDEs for Julia
| that come close to the ergonomics and feature set of Pycharm?
| cbkeller wrote:
| 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.
| martinsmit wrote:
| 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].
|
| [1]:
| https://docs.makie.org/stable/examples/blocks/legend/index.h...
| krumbie wrote:
| 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.
| simondanisch wrote:
| 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.
| asdfman123 wrote:
| Why does Julia get her own plotting library? Unfair.
| wodenokoto wrote:
| I 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
| leephillips wrote:
| Chris 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.
| nsajko wrote:
| IMO, the _Summary of Julia Plotting Packages_ article
| undersells Vega /Vega Lite. They're really powerful and look
| good.
| krumbie wrote:
| 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.
| twobitshifter wrote:
| 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.
| krumbie wrote:
| 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.
| nsajko wrote:
| Tangential: _No Grammar to Rule Them All: A Survey of JSON-
| style DSLs for Visualization_
|
| https://arxiv.org/abs/2207.07998
|
| Both Vega and Echarts are covered, among others.
| tkuraku wrote:
| Makie has been far superior to Plots.jl in my experience.
| operator-name wrote:
| Does anyone have any experience for how this compares to R's
| ggplot2?
| krumbie wrote:
| 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.
| cjalmeida wrote:
| 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.
___________________________________________________________________
(page generated 2023-07-04 23:00 UTC)