Live data from Hacker News

Correctness and composability bugs in the Julia ecosystem (2022)

yuri.is

81–83 of 83 posts

Re: Correctness and composability bugs in the Julia ecosystem (2022)

#81

Has anything changed since then? What are y'all's thoughts about correctness in Julia in 2025?

I've been using Julia for seven years, four years as my main language at work.

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.

Re: Correctness and composability bugs in the Julia ecosystem (2022)

#82
post #8

I think I may have missed what alternative is being recommended instead, after scrolling through the whole article.

The OP shows examples of people being unable to solve a problem in Julia that they solve quickly after switching to PyTorch, Jax, or TensorFlow, so the OP is implicitly recommending those alternatives.

But those are not languages, but frameworks, and are not general enough to solve many problems, especially outside of machine learning.

Re: Correctness and composability bugs in the Julia ecosystem (2022)

#83

Earlier quoted context omitted.

> Without contracts, either specified in documentation or as static guarantees, it is hard or impossible to build robust programs. 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…

> 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. 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 gener…

Agreed 100%.
Post reply on HN