[ViralBShah]

Yuri's criticism was not that Julia has correctness bugs as a language, but that certain libraries when composed with common operations had bugs (many of which are now addressed).

I will recommend following the discussion on the Julia discourse here that is focussed on productively and constructively addressing the issues (while also discussing them in the right context): https://discourse.julialang.org/t/discussion-on-why-i-no-lon...

Just like any other open source project, Julia has packages that get well adopted, well maintained, and packages that get abandoned, picked up later, alternatives sprout and so on. The widely used packages usually do not have this problem. Overall the trend is that the user base and contributor base are growing.

[jakobnissen]

I think you must be misremembering. There were several issues linked in his post that were bugs in the core language itself.

I can find you several more, if you want. In the last 2 years I've myself filed something like 6 or 7 correctness bugs in Julia itself (not libraries), and hit at least 2 dozen, whereas I've never found a correctness bug in Python despite using it daily for 5 years.

Right now, you can go to the CodeCov of Julia and find entire functions that are simply not tested. Many of those, and they are in plain sight. And it would take less than an hour to find a dozen correctness bugs that are filed, known about, agreed to be a bug, tractable, yet still not put on the milestone for the next Julia release, which means the next Julia release will knowingly include these bugs.

I just don't know how people can see these facts and still claim Julia cares a lot about correctness. It's just not true.

If you want something actionable, here are three suggestions:

1) Do not release Julia 1.9 until codecov is at 100% (minus OS-specific branches etc.)

2) Solicit a list of tractable correctness bugs from the community and put all the ones that are agreed to be bugs and that are solvable on the 1.9 milestone.

3) Thoroughly document the interface of every exported abstract type, the print/show/display system, and other prominent interfaces, do not release 1.9 before this is done.

Edit: I apologize for implying you were not being genuine. That was uncalled for.

[ViralBShah]

I carefully mentioned that the issues (with the exception of a type intersection bug which is in the language, but was characterized as a control flow bug) are not core language issues. Julia ships with a very large standard library, and people often lump all issues in base Julia as "language issues".

I know you have yourself filed dozens of issues, many of which have been fixed. I feel it is unfair to characterize years of work by a community of people as: "Julia does not care about correctness". There's an open triage meeting that happens every other week, where all new issues are discussed and triaged. There is a fairly detailed and well-defined release process. I don't believe people are holding back on filing bugs, because they are waiting for us to solicit.

[jakobnissen]

I would argue #39460, #39385 and #39183 mentioned in the post are all correctness bugs in Julia itself.

I feel there is this weird disconnect between what is being said by e.g. Yuri, me or Dan Luu, and what is being heard by some of the core devs, and I don't understand where this disconnect is happening precisely. That is very frustrating.

I think delving into the issues with communication will only turn sour with no benefit, so let's not go there. Instead, let me be much more concrete. When I say that Julia does not put correctness as a high priority, what I mean is:

* Julia is not well tested, as can plainly be seen from the code coverage. Having all functions covered by the test suite is the absolute minimal standard of testing - I would argue that is not sufficient to consider something well tested considering Julia's generic methods. But even covering all methods with tests is still not done for Base Julia.

* When I file a bug that is eminently fixable e.g. #43235 or #43245 (or several others), it is not being fixed after months, it is not being milestoned, and new releases are being pushed out that contains the bug.

Do these two points not illustrate that more could be done to reduce the bugginess of Julia? I legitimately don't understand that one can hold the view that these two issues are not a reflection of correctness not being prioritized in Julia.

There is a broader point here about how Julia's language design and lack of safety features or tooling makes it very difficult to write correct code and enforce the correctness of it. But I feel if we can't even agree that Julia ought to have all its exported methods covered by tests, and all its bug reports fixed, then I can't see how we can have a discussion about the more complex and nuanced topics like how to enforce interfaces or contracts.

[ViralBShah]

My comments have been mainly to address the nature of the conversation here and to provide some balance. Specifically, most readers of HN are not deeply steeped in the nature of issues, and the overly broad language in some of the comments can easily give the wrong impression.

It is easy to pick a subset of bugs and weave a particular narrative. You have filed several issues, many of which are still open, and many have been addressed. Thousands of bugs are fixed for every release, including many you have filed - and Julia is better as a result.

Should Julia be better tested, yes it should be. Should we have better tooling, of course we should. Can the triage process be improved, yes. Should code coverage get to 100% - it has steadily increased over time. None of Julia's dependent libraries have 100% code coverage. Many of those projects are even larger than Julia itself. Can every possible bug identified be fixed - we would like to - but eventually there is limited developer time and everything has to be prioritized.

I will once again mention that the triage process is not a secret process. I welcome you to join some of the triage calls to give higher visibility to issues that you feel should be fixed (but are unable to provide PRs yourself for).

[ViralBShah]

Correction: It is not that every new issue is triaged on the triage call. Issues are triaged by a group of people with triage access - and the triage call focusses on issues that have the `triage` label.

[adgjlsfhk1]

also, if you want to be able to mark issues for triage, ask. we are fairly liberal in who we give tagging permissions to.

[nsajko]

All other languages and language implementations have bugs, too.

[tremon]

...and they correctly treat them as release-critical.

[nsajko]

No. Take a look at the GCC or Clang bug trackers, for example.

[wtetzner]

It’s not just bugs that are the issue, it’s correctness bugs.

[blindseer]

If I may Viral, I suspect one takeaway from Yuri's criticism (at least it was a takeaway for me) is that with multiple dispatch correctness bugs like the ones listed are hard to find (impossible even). How would you respond to that criticism?

In my opinion, better tooling to assist with such cases would help tremendously. Adding support for interfaces to `Base` would be a great start. What are your thoughts about this?

Also, it's been a while since we've seen a roadmap on what the core team is working on? What are the next big features we can expect from the language and what is the approximate timeline for that? Having answers to these questions would be extremely helpful.

[ViralBShah]

The issue is not that the bugs are with correctness of multiple dispatch, but that multiple dispatch allows you to combine generic programming with abstract data types. Thus, one can have a generic implementation in base Julia, and someone can pass a new user data type - a combination that can easily not work. Some of the frustration also arises from types such as OffsetArrays that are included in the base distribution, but not as well supported and tested as the regular Arrays type. Thus, the discussion here tends to focus on defining interfaces, and of course on better testing of uncommonly used data types.

In general, we've not had a formal roadmap - but we present a "State of Julia" talk at JuliaCon every year. But very broadly, the list (of the top of my head) includes: improving a lot of the underlying compiler infrastructure overall, improving support differentiable programming, improving garbage collection, support for GPUs from multiple vendors (too many of those now), supporting apple silicon, type system support for tools like JET.jl.

NEWS.md is generally updated during the course of a release cycle, which eventually becomes release notes, and then post release, we put together a highlights blog post. https://github.com/JuliaLang/julia/blob/master/NEWS.md

[amkkma]

Thanks.

regarding "improving a lot of the underlying compiler infrastructure overall"

Is the compiler plugin project still active/ planned?

[ViralBShah]

It is still planned, but I'll defer to Keno and others to chime in on the details.

[sgt101]

>If I may Viral, I suspect one takeaway from Yuri's criticism (at least it was a takeaway for me) is that with multiple dispatch correctness bugs like the ones listed are hard to find (impossible even).

Maybe one approach would be for the community to create some certification tests. Although this wouldn't help with corner cases it would allow packages to run some testing that (if the tests are good) might throw up problems with constitutionality? Also if there were bugs from composition the certificate could be suspended until they were fixed.

[Sukera]

I may be missing some context, but what correctness bugs exactly are you referring to that are caused by multiple dispatch?

[orthoxerox]

Dependently typed arrays/lists/vectors with explicit lower/upper bounds would've prevented the errorneous assumption that you can iterate over any axis from 1 to length inclusive.

[Sukera]

True in principle, but that is neither related to multiple dispatch nor a common feature in other languages. Dependent typing is very much active research in PL academia. The @inbounds kerfuffle was all about incorrectly using a tool that's explicitly documented to take off the existing bounds checking safety, similar to `unsafe` blocks in Rust. So even with dependent types, if you explicitly opt out of those checks, they wouldn't have helped.

[abhimanyuaryan]

@blindseer I recommend start writing for your code. Tests are important you should not skip them. Julia vs no Julia

[blindseer]

Did you mean to reply to me? Or perhaps another comment of mine? If not, I don't follow.

Edit:

It looks like abhimanyuaryan is blindly spamming suggestions to write tests in this thread (???). This is a case where I agree in principle but their comments are completely beside the point and not relevant to the context of the comment or the post.

[abhimanyuaryan]

sorry for confusion what just pointing to one of recommendations from the blog post that I thought you mind wanna re-consider to overcome "multiple dispatch correctness bugs" i.e. "I'd say that there is a huge combination of packages that can be used together providing the language with an enormous amount of possibilities. It is up to the programmer to verify the interaction before use and, preferably, add tests to one of the packages." Yuri's criticism of composability came from packages as Viral already mentioned

[anonymoushn]

> Yuri's criticism was not that Julia has correctness bugs as a language

Are you sure? Here are some issues from the post:

"Wrong if-else control flow" seems like a language issue? bug is still open [0]

"Wrong results since some copyto! methods don’t check for aliasing" seems like a bug in a core library. The bug, which is filed against Julia, not some third-party library, is still open [1]

"The product function can produce incorrect results for 8-bit, 16-bit, and 32-bit integers" was a bug in a core library, which was fixed [2]

"Base functions sum!, prod!, any!, and all! may silently return incorrect results" seems like a bug in a core library and is still open [3]

"Off-by-one error in dayofquarter() in leap years" seems like a bug in a core library which was fixed [4]

"Pipeline with stdout=IOStream writes out of order" seems like a bug in a core library and is still open [5]

I've been deliberately conservative here and only posted the issues from Yuri's post that are in the JuliaLang/julia repository. The other issues are filed against JuliaStats/Distributions.jl, JuliaStats/StatsBase.jl, JuliaCollections/OrderedCollections.jl, and JuliaPhysics/Measurements.jl. Since I have not used Julia very much, I don't know whether these are commonly used libraries or obscure libraries nobody uses, but they seem pretty close to the core use-cases of the language. Maybe someone who uses the language a lot more can shed some light on this issue.

Some commenters seem exhausted by what they perceive as a continual stream of lies about these topics, which has left them less inclined to post about them.

[0]: https://github.com/JuliaLang/julia/issues/41096

[1]: https://github.com/JuliaLang/julia/issues/39460

[2]: https://github.com/JuliaLang/julia/issues/39183

[3]: https://github.com/JuliaLang/julia/issues/39385

[4]: https://github.com/JuliaLang/julia/pull/36543

[5]: https://github.com/JuliaLang/julia/issues/36069

[ninjin]

At its core, yes, Yuri wanted to highlight the fact that the “power” of the language created more or less “a fractal” of type/function composition cases that made it very difficult to guarantee the correctness of a given call site. This is inherent in the language, but causes potential issues across the ecosystem and he felt that the community did not take it as seriously as he would have hoped. At least that is the takeaway I got from both talking to him and reading what he wrote.

To me, this is a long and complex discussion to be had by those that understand general programming language design and the case for Julia itself and frankly statements like “Some commenters seem exhausted by what they perceive as a continual stream of lies about these topics, which has left them less inclined to post about them.” are bloody cheap, unfalsifiable, and adds little to nothing to the discussion.

[anonymoushn]

> At its core, yes, Yuri wanted to highlight the fact that the “power” of the language created more or less “a fractal” of type/function composition cases that made it very difficult to guarantee the correctness of a given call site. This is inherent in the language, but causes potential issues across the ecosystem and he felt that the community did not take it as seriously as he would have hoped. At least that is the takeaway I got from both talking to him and reading what he wrote.

For things like "The majority of sampling methods are unsafe and incorrect in the presence of offset axes" I agree that this is just some unfortunate combination of library code and concerns that the library authors had not considered, but the numerous correctness issues in the language and stdlib seem like they would often make it hard to figure out what exactly the problem is.

> bloody cheap, unfalsifiable, and adds little to nothing to the discussion.

Sorry about that. I'm not sure how to highlight the recurring nature of these less-than-factual posts and their effect on some members of the community while respecting the wishes of those people.

[ninjin]

> For things like "The majority of sampling methods are unsafe and incorrect in the presence of offset axes" I agree that this is just some unfortunate combination of library code and concerns that the library authors had not considered, but the numerous correctness issues in the language and stdlib seem like they would often make it hard to figure out what exactly the problem is.

I am not sure what we are arguing here. You asked what Yuri originally wanted to highlight and I answered based on my own insights. I have re-read what he wrote and I still stand by my conclusion and I see no point in arguing back and forth as I have stated here and in a comment when Yuri’s post was originally submitted [1] that all the issues are derived from how Julia as a language handles types and dispatch. Everything beyond this is arguing minute semantics and frankly very uninteresting compared to a discussion as to whether it can be resolved and how.

[1]: https://news.ycombinator.com/item?id=31398040

> Sorry about that. I'm not sure how to highlight the recurring nature of these less-than-factual posts and their effect on some members of the community while respecting the wishes of those people.

Not sure if I can consider this an apology when you in your very next breath make exactly the same kind of vague statement that I called out in the first place. Since you apparently know these people, how about collecting their opinions and presenting them anonymised? Likewise, if there are lies spread across so many posts, why not simply collect and refute them? This all seems obvious to me, but maybe I am missing something? In fact, I find posts such as yours in very stark contrast to what Yuri wrote and accomplished with his post, so perhaps you can find inspiration there?

[anonymoushn]

If the project has cultural issues that would cause severe correctness issues regardless of the language's semantics, it may not be that useful to talk about technical solutions that would let other projects without these cultural issues make a language with similar semantics and fewer correctness issues.

> Since you apparently know these people, how about collecting their opinions and presenting them anonymised

This sounds like the sort of claim that would get called out as unfalsifiable online.

> Likewise, if there are lies spread across so many posts, why not simply collect and refute them? This all seems obvious to me, but maybe I am missing something?

Is the question really "Why don't you just do a lot of work for me, for free, since I will not use a search engine?"

[ninjin]

> If the project has cultural issues that would cause severe correctness issues regardless of the language's semantics, it may not be that useful to talk about technical solutions that would let other projects without these cultural issues make a language with similar semantics and fewer correctness issues.

How can solving – or failing to solve – a technical issue that could then lead to insights shared between communities ever be a bad thing? Maybe I am just too thick to see it? But I am ending my efforts at this point as I am not getting any closer to understanding what you are trying to convey.

As for your “comebacks”, we clearly have very different standards and expectations when it comes to discourse. Where I come from, those that bring claims are expected to also bring adequate evidence – or at the very least attempt to do so and not spread claims just to later throw their hands into the air when called out for it.

[Sukera]

[0] is already fixed on master but can't be backported to LTS due to the fix introducing other problems specific to LTS. [2] is closed. [3] should be fixed, but doesn't seem trivial to do. [4] is a regular ol' bug (again, not a language but a library bug). Same goes for [5].

From the linked stuff, only [0] is a true correctness problem of the language and not a bug in a library.

> Some commenters seem exhausted by what they perceive as a continual stream of lies about these topics, which has left them less inclined to post about them.

How is differentiating bugs in the language (parser, compiler, type system, ...) from bugs in libraries implemented in the language "lying about these topics"? It's not like julia is claiming to prevent logic bugs, or am I missing something.

[anonymoushn]

"Yuri's criticism was not that Julia has correctness bugs as a language" would be an appropriate thing to say if none of the bugs in the post were "Wrong if-else control flow."

Edit: "certain libraries when composed with common operations had bugs" also does not seem like a completely on-the-level way to describe bugs in the stdlib that do not require any particular composition to encounter.

[ViralBShah]

If you look at the linked issue, you will see that it is a type intersection issue (a real language issue) mischaracterized as a control-flow bug. Many readers here seem to see that and believe that if statements in Julia are broken - no that is not the case.

[anonymoushn]

As an end user it may be hard for me to accept that there are no control-flow bugs involved when this code

    println(flag)
    if flag
        println("flow for true.")
    else
        println("flow for false.")
    end

prints

  false
  flow for true.

[oivey]

I pasted that code into a REPL (including setting flag=false, which seems to be implied) and got:

  false
  flow for false.

How did you get your output? Your post implies that if statements are broken in Julia. Untrue.

[anigbrowl]

That's valuable context, thanks for taking time to answer. Looking forward to JuliaCon 2022!