6 ms·

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

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-longer-recommend-julia-by-yuri-vishnevsky/81151 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.

deleted 4y ago
[deleted]
blindseer 4y ago
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.
- abhimanyuaryan 4y ago
  @blindseer I recommend start writing for your code. Tests are important you should not skip them. Julia vs no Julia
  - blindseer 4y ago
    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 4y ago
      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
- Sukera 4y ago
  I may be missing some context, but what correctness bugs exactly are you referring to that are caused by multiple dispatch?
  - orthoxerox 4y ago
    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 4y ago
      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.
- sgt101 4y ago
  >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.
- ViralBShah 4y ago
  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 https://github.com/JuliaLang/julia/blob/master/NEWS.md
  - amkkma 4y ago
    Thanks. regarding "improving a lot of the underlying compiler infrastructure overall" Is the compiler plugin project still active/ planned?
    - ViralBShah 4y ago
      It is still planned, but I'll defer to Keno and others to chime in on the details.
anigbrowl 4y ago
That's valuable context, thanks for taking time to answer. Looking forward to JuliaCon 2022!
anonymoushn 4y ago
> 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 https://github.com/JuliaLang/julia/issues/41096 [1]: https://github.com/JuliaLang/julia/issues/39460 https://github.com/JuliaLang/julia/issues/39460 [2]: https://github.com/JuliaLang/julia/issues/39183 https://github.com/JuliaLang/julia/issues/39183 [3]: https://github.com/JuliaLang/julia/issues/39385 https://github.com/JuliaLang/julia/issues/39385 [4]: https://github.com/JuliaLang/julia/pull/36543 https://github.com/JuliaLang/julia/pull/36543 [5]: https://github.com/JuliaLang/julia/issues/36069 https://github.com/JuliaLang/julia/issues/36069
- Sukera 4y ago
  [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.
jakobnissen 4y ago
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.
- nsajko 4y ago
  All other languages and language implementations have bugs, too.
  - tremon 4y ago
    ...and they correctly treat them as release-critical.
    - nsajko 4y ago
      No. Take a look at the GCC or Clang bug trackers, for example.
      - wtetzner 4y ago

deleted 4y ago

[deleted]

blindseer 4y ago

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.

abhimanyuaryan 4y ago
@blindseer I recommend start writing for your code. Tests are important you should not skip them. Julia vs no Julia
- blindseer 4y ago
  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 4y ago
    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
Sukera 4y ago
I may be missing some context, but what correctness bugs exactly are you referring to that are caused by multiple dispatch?
- orthoxerox 4y ago
  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 4y ago
    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.
sgt101 4y ago
>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.
ViralBShah 4y ago
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 https://github.com/JuliaLang/julia/blob/master/NEWS.md
- amkkma 4y ago
  Thanks. regarding "improving a lot of the underlying compiler infrastructure overall" Is the compiler plugin project still active/ planned?
  - ViralBShah 4y ago
    It is still planned, but I'll defer to Keno and others to chime in on the details.

anigbrowl 4y ago

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

anonymoushn 4y ago

> 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 https://github.com/JuliaLang/julia/issues/41096 [1]: https://github.com/JuliaLang/julia/issues/39460 https://github.com/JuliaLang/julia/issues/39460 [2]: https://github.com/JuliaLang/julia/issues/39183 https://github.com/JuliaLang/julia/issues/39183 [3]: https://github.com/JuliaLang/julia/issues/39385 https://github.com/JuliaLang/julia/issues/39385 [4]: https://github.com/JuliaLang/julia/pull/36543 https://github.com/JuliaLang/julia/pull/36543 [5]: https://github.com/JuliaLang/julia/issues/36069 https://github.com/JuliaLang/julia/issues/36069

Sukera 4y ago
[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.

jakobnissen 4y ago

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.

nsajko 4y ago
All other languages and language implementations have bugs, too.
- tremon 4y ago
  ...and they correctly treat them as release-critical.
  - nsajko 4y ago
    No. Take a look at the GCC or Clang bug trackers, for example.
    - wtetzner 4y ago