It does, of course, but serialization is problematic (with the combination of Type inference and dynamicism this is maybe to be expected). Beyond that there is

It does, of course, but serialization is problematic (with the combination of Type inference and dynamicism this is maybe to be expected). Beyond that there is a bewildering array of packages, and not really a clear consensus for which to use: https://discourse.julialang.org/t/what-is-the-preferred-way-to-save-variables/21918 https://discourse.julialang.org/t/what-is-the-preferred-way-... JLD2, which for a while seemed like an emerging consensus option has caused massive dataloss for a number of people: https://github.com/JuliaIO/JLD2.jl/issues/55 https://github.com/JuliaIO/JLD2.jl/issues/55 The issue is also that Julia packages often use their own container types for convenient analysis. For example the solution type of DiffEq has a number of important features like interpolation built in. If I want to reliably save the data I got from the numerical integration, and don't want to rely on brittle/broken serialization packages, I have to extract the underlying arrays though. That would be fine if not for the fact that there is no documented way (that I've found) to initialize the solution objects from this raw data, so now I have lost access to the convenience functions. Don't get me wrong, this is all growing pains. I am sure this will be sorted out eventually. But it's important to point out how the intersection of features that enable Julia to do things that are unheard of in other languages (e.g. DiffEqFlux, Zygote) also mean there are some things that still need to be figured out for this language (serialization, useful error messages, interfaces).