Has anything changed since then? What are y'all's thoughts about correctness in Julia in 2025?
Using this approach since 2017 I've never really encountered the types of issues mentioned in Yuri's blog post. The biggest issue I've had is if some user-package makes a change that is effectively breaking but they don't flag it the associated release as breaking. But this isn't really a Julia issue so much as a user-space issue, and can happen in any language when relying on others' libraries.
But Julia fucked it up to where it's not clear what you're using, and library writers don't know which one has been passed! It's insane. They chose style over consistency and correctness and it's caused years of suffering.
My understanding is that it's a difficult problem to solve, and there are people working on traits/interfaces - but these are still peripheral projects and not part of the core mission to my knowledge. In practice, composability problems arise seldomly, but there is no formal way to guard against it yet. I believe there was some work done at Northeastern U. [1] toward this goal but it's still up to the user to "be careful", essentially.
[1] https://repository.library.northeastern.edu/files/neu:4f20cn...
In a language with pervasive use of generic methods, I don't know what actually means. If I write a function like:
function add3(x, y, z)
x + y + z
end
Is that correct? What expectations should someone have about a function whose behavior is defined in terms of calls to other open-ended generic functions?
My point is that there is an implied contract that `add3()` only does what you expect if you pass it values where `+` happens to do what you expect. When you have a language with fully open generic methods like Julia, it's very powerful, but the trade-off is that every function is effectively like middleware where all it can really say is "if you give me things that to delegate to the right things, I'll do the right thing too".
When I'm writing `add3()`, I don't know what `+` does. I'm writing a function in terms of open-ended abstractions that I don't control, so it's very hard to make any promises about the semantics of my function.
In Julia it's almost as if every function is an interface, with (usually quite terse) documentation as its only semantic constraint. For example, here is the full documentation for `+`: https://docs.julialang.org/en/v1/base/math/#Base.:+
I love Game Programming Patterns, by the way! Laughed out loud when I first saw the back cover.
Right. I think a big part of this is expectation management. Julia lets you compose unrelated libraries much more freely than most other languages do. That's very powerful, but if you come into it expecting all of those compositions to magically work, I think you just have an unrealistic expectation.
There's no silver bullet when it comes to code reuse and Conway's Law can't be entirely avoided.
> I love Game Programming Patterns, by the way! Laughed out loud when I first saw the back cover.
:D
Yep, and it is unfortunate that this unrealistic expectation is explicitly encouraged by the creators of the language:
> It is actually the case in Julia that you can take generic algorithms that were written by one person and custom types that were written by other people and just use them together efficiently and effectively.
It seems worth reiterating that on a personal level I really like and appreciate the vast majority of the folks I’ve met in the Julia community. I’m glad I got to hang out with them and learn from them. But in my opinion setting expectations like this fosters bad science.
On the contrary, it is my impression the experienced Julia programmers, including those involved in JuliaLang/julia, take correctness seriously. More so than in many other PL communities.
> there are people working on traits/interfaces - but these are still peripheral projects and not part of the core mission to my knowledge
What exactly do you mean by "traits" or "interfaces"? Why do you think these "traits" would help with the issues that bug you?
I think you're actually even more active in the Julia community so maybe I don't have to summarize the debate but these are the types of traits and interface packages being developed that are meant to formalize how modules can be used and extended by others.
https://github.com/rafaqz/Interfaces.jl
https://discourse.julialang.org/t/interfaces-traits-in-julia...
• The documentation (currently) of the function warns not to use it this way;
• This is a rather perverse use of the function(s) that would be unlikely unless you’re trying to break things;
• The discussion on the issue page demonstrates the exact opposite of a culture not caring about correctness;
• This kind of stuff doesn’t matter to all the scientists who are actually using Julia to do real work.
Nevertheless, sum!() and friends should be, somehow, made to avoid this problem, certainly.
It is good the documentation is now explicit that the behavior is not guaranteed in this case, but even better would be if aliasing were detected and handled (at least for base Julia arrays, so that the warning would only be needed for non-base types).
Still, the lesson is that when using generic functions one should look at what they expect of their input, and if this isn't documented one should at least test what they are giving thoroughly and not assume it just works. I've always worked this way, and never run into surprises like the types of issues reported in the blog post.
Currently there is no documentation on what properties an input to `sum!` must support in the doc string, so one needs to test its correctness when using it outside of base Julia data types (I haven't checked the broader docs for an interface specification, but if there is one it really should be linked in the docstring).
It's my view that all the major points in the blog post are true, and the problem persists. It's slightly better now, because Julia has more usage in industry and less usage by hobby hackers.
I'm convinced it's caused by two factors: The first is the duck-typed, dynamic nature of the language, which, like Python, gives the developer no tools to check or enforce correctness.
More fundamentally, the culture of Julia is a cowboy hacking culture where we just start writing, and then we can always kick the code around once bugs appears. There seem to be an almost complete disinterest in careful documentation of behaviour and edge cases, or even actual descriptions of what some abstraction is supposed to do. The natural result is that people interpret all kinds of meaning to any abstraction and use them in slightly different ways. It's madness.
As an example, consider [the definition of Base.seek](https://docs.julialang.org/en/v1/base/io-network/#Base.seek). There is no description of what the position is, what type is can be or operations it's supposed to support. Nor that the seek position is typically zero-indexed. There is no description of what should happen for out of bounds seeks, or how it differs for files open in reading and writing mode. Nor any description of the errors it can throw.
I must emphasize that this kind of documentation is the norm, not the exception.
This kind of indifference towards actually specifying behaviour is not a foundation you can build a language on. And it's very hard to change in retrospect, because by now, seek means a bunch of different things in Base Julia and the ecosystem, and it would be breaking to change.
I've several times seen a core dev change some behaviour of some code because they clearly thought the behaviour was always meant to be X, even though it actually did Y, arguing that Y was an implementation detail. No shit - everything is an implementation detail when nothing is documented.
I think Julia needs to grow up and begin taking it's documentation and interfaces seriously.