Can you elaborate on what you mean by this? Does Julia not support writing files?
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-...
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
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).
The only workaround is to use an undocumented alternative interface for working on the files. A pull request to at least inform people about the issue has been lying around for almost two years.
I am happy that activity has picked up again, but don't intend to recommend the use of JLD2 for expensive data for the foreseeable future...
Because the core is so brilliant at what it does I am sure that Julia will get there eventually, but it will be a painful way.
For crying out loud, we still don't have a sory for people to save their data...