A devastating article for Julia. I was thinking about trying Julia out... but not after reading this.
Correctness and composability bugs in the Julia ecosystem
331–340 of 419 posts
Re: Correctness and composability bugs in the Julia ecosystem
#332Earlier quoted context omitted.
FWIW my take is not that Yuri is expressing "there are too many bugs" so much as he's expressing a problem in the culture surrounding Julia itself: > But systemic problems like this can rarely be solved from the bottom up, and my sense is that the project leadership does not agree that there is a serious correctness problem. Concisely: 1. The ecosystem is poorly put together. (It's been produced by academics rather t…
> The Julia language is amazing. The ecosystem needs to be rewritten. I think this is pretty unfair. Julia has many libraries that have allowed me to build things that would have taken orders of magnitude more effort to produce in other languages with the same conciseness and efficiency. Composability and efficiency hard. Are things better elsewhere? Python has excellent libraries. But these are big monoliths that no…
As a user, I’d prefer “correct but lacking composability” over “composable but sometimes my results will be silently wrong”.
What is Julia’s composability useful for if it leaves me unable to trust my results?
Re: Correctness and composability bugs in the Julia ecosystem
#333Earlier quoted context omitted.
> The Julia language is amazing. The ecosystem needs to be rewritten. I think this is pretty unfair. Julia has many libraries that have allowed me to build things that would have taken orders of magnitude more effort to produce in other languages with the same conciseness and efficiency. Composability and efficiency hard. Are things better elsewhere? Python has excellent libraries. But these are big monoliths that no…
As a user, I’d prefer “correct but lacking composability” over “composable but sometimes my results will be silently wrong”. What is Julia’s composability useful for if it leaves me unable to trust my results?
The answer as far as I can see is to write integration tests when you want to use composability (and/or just check that the packages in question already have integration tests against each other -- increasingly many do). It's not especially hard or anything, but you need to know to do it.
Re: Correctness and composability bugs in the Julia ecosystem
#334Unfortunately this is not a feature but a bug, and the worst kind, a bug at the language design level:
Basically, Julia tries very hard to make composability work, even if the authors of the packages that you're composing don't know anything about each other. That's a critical feature that makes Julia as powerful as it is, but of course you can easily end up with situations where one or the other package is making implicit assumptions that are not documented (because the author didn't think the assumptions were important in the context of their own package) and you end up with correctness issues.
Re: Correctness and composability bugs in the Julia ecosystem
#335Earlier quoted context omitted.
It's not subjective. The fundamental meaning of an index is "how far are we from the start of an array". The first element is 0 from the start of the array. If humans had got this right then we wouldn't be even having this discussion. Same for similar mistakes like Pi vs Tau, negative electrons. But the mistake is understandable given that we didn't even think of 0 for a long time.
It's subjective because you haven't defined or quantified elegance or understandability. I could say that zero based indexing is not in fact understandable based on the amount of confusion I encounter explaining the concept to new users. I could say it's inelegant based on the fact it makes algorithms I use harder to implement. Others argue it's more elegant because it makes algorithms they use easier to implement. S…
You encounter confusion explaining it to new users because they've learned it wrong their whole lives.
Nobody has any trouble in the UK with lifts where the ground floor is 0 - one of the few places where humans got it right.
Re: Correctness and composability bugs in the Julia ecosystem
#336I tried Julia but the compilation time for interactive use was just too insane. I ended up paying £125 for MATLAB. Nothing else really remotely compares to MATLAB's plotting facilities.
I use Matlab daily, and the plotting is indeed excellent. But the language itself is a horrible kludgy mess. Most of the development time is spent on input parsing and contorting your code into a vectorized shape.
Yeah I agree the language is not great, especially for non-matrix things. But Julia isn't exactly great either (unsurprisingly since it is pretty much a MATLAB derivative).
But I only use it for prototyping. I would absolutely not recommend it for production code. If there's some gnarly input processing to be done I'll do that in another language and just have it output CSV or similar.
Re: Correctness and composability bugs in the Julia ecosystem
#337Everything has correctness issues somewhere. Julia ships an entire patched version of LLVM to fix correctness bugs in numerical methods. It has its own implementations of things like software-side FMA because the FMA implementation of Windows is incorrect: https://github.com/JuliaLang/julia/pull/43530 . Core Julia devs are now the maintainers of things like libuv because of how much had to be fixed there. So from tho…
> Everything has correctness issues somewhere. This is fallacy of gray. The blog post isn't complaining that there are non-zero bugs, it's complaining that when you use the language you hit a lot of correctness bugs. More bugs than you'd hit using e.g. python. Also, to the extent that Julia uses LLVM, a correctness bug in LLVM is also a correctness bug in Julia. So arguing "LLVM has lots of correctness bugs" is not h…
> So arguing "LLVM has lots of correctness bugs" is not helping the case
It does not help the case about the correctness of Julia, but it does help the case about Julia having more bugs than other software (negatively for the other projects). Every library built with LLVM that touches those code paths will have those bugs.
Another thing to have in mind is that Julia ships patches for some of these, that are not used upstream yet. So Julia does not suffer from some bugs on LLVM that other projects might.
Re: Correctness and composability bugs in the Julia ecosystem
#338Earlier quoted context omitted.
I'll start by saying that I greatly prefer 0-based, and have used but 0- and 1-based indexing, but the choice is largely arbitrary. 0 makes sense as the '0-th offset' when thinking from a pointer perspective, but I often find when teaching, that 1-based comes more naturally for many students (the 'first' item). You mention mathematical or scientific work...but I often/mainly see enumerations (such as weights x_1, x_2…
My experience is that 0-based offsets (and use of I came to 0-based offsets later in my career, having started with Matlab. So I have some real experience with 1-based offsets. Experience that was 'untainted' by being used to a different option. I much prefer 0-based. Especially because I now sort-off have a linter rule in my head 'if I am writing i - 1 then I am making a mistake or doing something the wrong way'. Wh…
I have a similar experience. Matlab was my first experience with computational work. Now I use Python and 0-based is still more natural.
Re: Correctness and composability bugs in the Julia ecosystem
#339Earlier quoted context omitted.
> Is "for i in 1:length(A)" ever correct? In some rare cases, it very well might be exactly what the code's author intended and needed. I tend to lean towards when Martin Fowler calls an "enabling attitude"[0] (as opposed to a "directing attitude") -- that is, when faced with a choice about how to design the primitives of an interface, I lean more often towards providing flexibility, and I try to avoid choosing ahead…
Why not have a feature to allow you to turn off the warning? E.g. have something recognise 1:length(x) and complain unless you write e.g. @nowarn eachindex before it.
Warning about such things is the job for a linter. There is a linter for Julia so such a thing could be added there. It shouldn't be a runtime warning though, like you propose.
Re: Correctness and composability bugs in the Julia ecosystem
#340Earlier quoted context omitted.
Makes sense. I guess the author's contention is that if Julia had those formal features the author wants, it would need very significantly less dev time to reach python's levels of reliability? It's of course plausible, that's what those sorts of features are intended for, but I'm not certain I'm absolutely confident. At any rate, python demonstrates it is not the only path, as the author seems to be suggesting ("it…
Python's reliability here comes because it is a much less flexible language in some ways. If you write your own array type in python, and pass it into tensorflow, you would expect it to error. If you do the same thing in Julia, you would expect it to work.
More like you hope it works is what I'm gathering.