What are your most coveted functionalities missing in the ecosystem?

My wish list:

  1. A stable plotting system that just works (Makie.jl is not ready, and Plots.jl is… you know)
  2. A stable mechanism for precompiling full environments as opposed to just isolated packages
  3. A comprehensive package for probabilistic graphical models a la pgmpy
  4. A package for 3D meshing without external dependencies written in other languages
  5. A VTK.jl package that has WriteVTK.jl as well as “ReadVTK.jl” functionality

Besides functionality and packages, it would be really great if experienced Julia users could compile a book on HPC with Julia. There are many parallel models in the language, but the community is lacking the necessary training to pick the most appropriate model for the problem at hand.


Give VegaLite.jl a shot!

We’ve added experimental support for easily compiling a sys-image for an environment in the latest VS Code extension. Probably not perfect, but I’d love to hear feedback on how that works.


Is this a possible solution? https://github.com/cdr/code-server

Thank you @davidanthoff! VegaLite.jl is a really beautiful work. My main use case however is plot recipes. Does VegaLite.jl support plot recipes? When it comes to plotting dataframes and tabular data in general, I recommend VegaLite.jl to colleagues.

I think code-server might also work, but my guess is that the various remote extensions that MS is putting out are probably a more stable story. But not sure, I haven’t really tried :slight_smile:

No, not at this point. I assume it is something that could be added, though, but I’m not familiar enough with that ecosystem right now. Has the whole plots recipe story settled, or is that all in flux with the imminent Makie.jl story? I have to admit I haven’t followed this closely. BUT, it would be great to use vega and vega-lite plotting capabilities for non grammar of graphics APIs as well.


I think the recipes API is still evolving because of Makie.jl. Maintainers of these projects already pointed out that their plan is to migrate all existing recipes as smooth as possible to the new ecosystem.

Vega-Lite and Vega themselves are language-agnostic recipe systems (plus the runtime implemented in JavaScript). I think a better direction is to implement Vega-Lite/Vega runtime in Julia to handle amount of data which is too large to put in row-oriented JSON format. It would be beneficial for people outside Julia community, too. Of course, this is a pretty ambitious project… (Also, there is already https://github.com/vega/vega-loader-arrow so this may not be necessary at all)

1 Like

My wish list:

  1. Simple way to generate independent Shared / Static Libraries from Julia code which doesn’t require embedding Julia when linked to a C / C++ code. With support for Windows, macOS and Linux.
  2. Easily generate standalone applications from Julia code with UI.
  3. First class support for Intel MKL with all optimizations (JIT in MKL, Batch API, Compact API, etc…). Including utilizing MKL Solvers, MKL Sparse Matrices support, etc…
  4. First class support for Intel SVML.
  5. Better control for vectorization of code.

This is a little off topic with regards to the original post, feel free to split this discussion out into a separate thread.

Yes, that sounds very interesting. Reading through the paper explaining vega-lite, it seems to me that there are shared goals between vega-lite and Makie with respect to interactivity. One key advantage of vega-lite is that you can send interactive visualizations to people and they can open it in their browsers without jumping over any installation hurdles. My understanding is that WGLMakie will bring similar functionality to Makie.

To me, the logical way to make vega/vega-lite available in a non grammar of graphics form would be to make a vega/vega-lite backend for either Plots.jl or Makie.jl. Or were you thinking of making a non grammar of graphics API that is separate to those packages?

Making a separate API would be sad because then you can’t support plot recipes. However, making vega-lite a backend to Plots/Makie is also sad because then you lose the grammar of interactive graphics which one of the central features of vega-lite.

Maybe we should just be greedy and do both.

Complete Elimination of compilation latency! When installling a package, I imagine a scrip called, to_compile.jl can be supplied with the package and anything contained within it will be compiled, so that when you load up a packages it just loads the compile versions so it starts up until you try to run a funcion that isn’t in the to_compile.jl then it will compile, otherwise my true feelings are that Julia feel too “lethargic” to use. But compiliation latency is a top prioritise as listed in the “What’s bad about Julia” talk at Juliacon 2019. So I am sure something is being worked on.

JuliaDB.jl! Everytime it nevered worked for my use-case and the thing is I can’t share the data that I tried to use it with! So I can’t give the JuliaDB team much useful info! Also some key features seems to be missing from JuliaDB (e.g. https://github.com/JuliaComputing/JuliaDB.jl/issues/257).

I still use R for larger data because JuliaDB.jl doesn’t work on my data. It’s hard to beat R’s data.table though, so I have builit a R medium data tool (https://github.com/xiaodaigh/disk.frame) which is generating some interests in the R community. Once I am happy with the R pacakge, I might create a disk.frame.jl package. I think CSV.jl and DataFrames.jl have come a long way!


Hi @Maurizio_Tomasi,

since the pull request #68 has been merged, YAML.jl is able to emit Julia objects to YAML files (and YAML-formatted strings).

1 Like

A Julia interface to distributed-memory FFTW-MPI that works with DistributedArrays.jl.


A dataframe package that works and is fast as data.table in R. This would be a killer feature to bring over a lot of people that use R and Python for data analysis, which in turn would bring even more development support.

1 Like

More generic UI widgets. IE: Interactive plots, click and drag event listeners.


I wish Julia version of Simulink. It will be the lethal strike to Matlab.


Hold your horses.


The option to create concretely “typed” functions similar to FunctionWrappers.jl (except without the ccall and both the run time and compilation overheads which are currently killing me).


I want to share that I have worked on getting my top coveted functionality for the ecosystem.