@dang: I'm not sure exactly when this was posted since it seems to have no date, but it's at least (2022) per HN's link from that year: https://news.ycombinator.com/item?id=31396861
I mention this because this is definitely the sort of content that can age poorly. I have no direct experience, I've never so much as touched Julia.
> My conclusion after using Julia for many years is that there are too many correctness and composability bugs throughout the ecosystem to justify using it in just about any context where correctness matters.
Does this have any impact on the cosmological emulator written in Julia?
I like the design of the language, but I eventually went through too many cycles of "fast compilation and/or module caching is coming in the next release" and "ahead of time compilation is coming soon" and got burned out. I remember believing the same stuff from java for years until forgetting about it.
I'm reminded of the recent post about R's (CRAN's) somewhat radical approach to integration testing [1] and I wonder if something like that would help with the composition issues described here.
The Julia world is already quite careful with testing and CI. Apart from the usual unit testing, many packages do employ integration testing. The Julia project itself (compiler, etc) is tested against the package ecosystem quite often (regularly and for select pull requests).
Which is a bummer, however the basics are always critical. Numerical stability and known correctness is still (or was) a reason a lot of old fortran libraries were used for so long.
I'm really surprised by the list of issues as some of those are pretty recent (2024) and pretty important parts of the ecosystem like ordereddict.
Julia is a very powerful and flexible language. With very powerful tools you can get a lot done quickly, including shooting yourself into the foot. Julia's type-system allows you to easily compose different elements of Julia's vast package ecosystem in ways that possibly were never tested or even intended or foreseen by the authors of these packages to be used that way. If you don't do that, you may have a much better experience than the author. My own Julia code generally does not feed the custom type of one package into the algorithms of another package.
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.
The person who eventually fixed the issue, mkitti, had to push through a lot of "institutional" friction to do so, and the eventual fix is the result of his determined efforts.
while I certainly agree that bug was a bit frustrating, in all that
* it happened in the first place
* it took so long to get noticed
* it took so long to merge the fix after being reported
I do feel like I should push back on the term "institutional friction." it was more of a bus factor problem; there were not enough (aka zero) maintainer eyeballs on the proposed fix. but there wasn't exactly anybody saying not to fix it, which is what I think of as friction.
I use julia intensively and have done so for 5 years or so. I have never encountered anything I would call a correctness bug. I guess it depends on what you count as a correctness bug, and what you mean by "julia". The core language has no obvious bugs, but there are packages of dubious quality.
Say you use some package for numerical integration. One day you cook up your own floating point type, and use the same package with success. Then you change your floating point type subtly, and suddenly weird things start to happen. Is it a correctness bug? Whose bug?
Surely, the author of the integration package didn't have your weird floating type in mind, but it still worked. Until you made it even weirder. These are the things some people think are correctness bugs in julia. It's mostly poor coding.
I've found that I'm most productive in Julia when minimizing the number of third party dependencies for this reason, even more so than other languages. That's not to say there are not many high quality packages available but rather the benefits of the type system align better when I have a strong understanding or control over the most pertinent interfaces. As a language Julia definitely rewards you heavily for this type of thing. Coming from Python my first instinct was to try to solve as many problems as possible with third party packages and filling in between the lines. Unsurprisingly this was the worst of both worlds.
If there was one thing I could change about Julia it most certainly wouldn't be correctness issues in my own experience. Filling in the ecosystem in terms of boring glue type stuff like a production grade gRPC client would be amazing. This was the type of problem that almost got me to give up on the language.
Julia is not without warts, but this blog post is kinda rubbish. The post claims vague but scary "correctness issues", trying to support this with a collection of unrelated issue tickets from all across Julia and the Julia package ecosystem. Not all of which were even bugs in the first place, and many of which have long been resolved.
The fact that bugs happen in software should not surprise anyone. Even software of critical importance, such as GCC or LLVM, whose correctness is relied upon by the implementations of many programming languages (including C, C++ and Julia itself), are buggy.
Instead the post could have focused more on actual design issues, such as some of the Base interfaces being underspecified:
> the nature of many common implicit interfaces has not been made precise (for example, there is no agreement in the Julia community on what a number is)
The underspecified nature of Number (or Real, or IO) is an issue, albeit not related with the rest of the blog post. It does not excuse the scaremongering in the blog post, however.
19 comments
[ 0.19 ms ] story [ 46.7 ms ] threadI mention this because this is definitely the sort of content that can age poorly. I have no direct experience, I've never so much as touched Julia.
Does this have any impact on the cosmological emulator written in Julia?
https://news.ycombinator.com/item?id=45346538
[1] https://news.ycombinator.com/item?id=45259623
The language is elegant, intuitive and achieves what it promises 99% of the time, but that’s not enough compared to other programming languages.
I'm really surprised by the list of issues as some of those are pretty recent (2024) and pretty important parts of the ecosystem like ordereddict.
Any recommended libraries (or languages) that have thoroughly verified libraries?
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.
I may refresh the post with more recent information at some point. In the meantime, those curious can find a short story of one newer correctness bug here: https://discourse.julialang.org/t/why-is-it-reliable-to-use-...
The person who eventually fixed the issue, mkitti, had to push through a lot of "institutional" friction to do so, and the eventual fix is the result of his determined efforts.
While his part of the story mostly played out in venues outside of the Discourse forum some of it is on display in this thread: https://discourse.julialang.org/t/csv-jl-findmax-and-argmax-...
* it happened in the first place
* it took so long to get noticed
* it took so long to merge the fix after being reported
I do feel like I should push back on the term "institutional friction." it was more of a bus factor problem; there were not enough (aka zero) maintainer eyeballs on the proposed fix. but there wasn't exactly anybody saying not to fix it, which is what I think of as friction.
Say you use some package for numerical integration. One day you cook up your own floating point type, and use the same package with success. Then you change your floating point type subtly, and suddenly weird things start to happen. Is it a correctness bug? Whose bug?
Surely, the author of the integration package didn't have your weird floating type in mind, but it still worked. Until you made it even weirder. These are the things some people think are correctness bugs in julia. It's mostly poor coding.
If there was one thing I could change about Julia it most certainly wouldn't be correctness issues in my own experience. Filling in the ecosystem in terms of boring glue type stuff like a production grade gRPC client would be amazing. This was the type of problem that almost got me to give up on the language.
The fact that bugs happen in software should not surprise anyone. Even software of critical importance, such as GCC or LLVM, whose correctness is relied upon by the implementations of many programming languages (including C, C++ and Julia itself), are buggy.
Instead the post could have focused more on actual design issues, such as some of the Base interfaces being underspecified:
> the nature of many common implicit interfaces has not been made precise (for example, there is no agreement in the Julia community on what a number is)
The underspecified nature of Number (or Real, or IO) is an issue, albeit not related with the rest of the blog post. It does not excuse the scaremongering in the blog post, however.