I don't really know what kind of rebuttal you're looking for, but I will link my HN comments from when this was first posted for some thoughts: https://news.ycombinator.com/item?id=31396861#31398796. As I said, in the linked post, I'm quite skeptical of the business of trying to assess relative buginess of programming in different systems, because that has strong dependencies on what you consider core vs packages and what exactly you're trying to do.
However, bugs in general suck and we've been thinking a fair bit about what additional tooling the language could provide to help people avoid the classes of bugs that Yuri encountered in the post.
The biggest class of problems in the blog post, is that it's pretty clear that `@inbounds` (and I will extend this to `@assume_effects`, even though that wasn't around when Yuri wrote his post) is problematic, because it's too hard (arguably impossible) to write correctly. My proposal for what to do instead is at https://github.com/JuliaLang/julia/pull/50641.
Another common theme is that while Julia is great at composition, it's not clear what's expected to work and what isn't, because the interfaces are informal and not checked. This is a hard design problem, because it's quite close to the reasons why Julia works well. My current thoughts on that are here: https://github.com/Keno/InterfaceSpecs.jl but there's other proposals also.
There is no rebuttal because nothing much has really changed culture wise. Sure, the various @inbounds issues and concrete bugs that are mentioned in Yuris post have mostly been addressed, but the larger point (that is, "what can I actually expect/get guaranteed when calling a given function?") definitely hasn't been, at least not culturally (there are parts of the ecosystem that are better at this, of course). Documentation of pre- and postconditions are still lackluster, PRs trying to establish that for functions in Base stall for unclear reasons/don't get followups and when you try to talk about that on Slack retorts boil down to "we're tired of hearing you complain about this" instead of trying to find a systemic solution to that problem. Until that changes, I have large doubts about Yuris post losing relevance.
My own efforts (shameless plug, https://github.com/Seelengrab/PropCheck.jl for property based testing inspired by Hedgehog and https://github.com/Seelengrab/RequiredInterfaces.jl for somewhat formalizing "what methods are needed to subtype an abstract type") are unused in the wider community as far as I can tell, in spite of people speaking highly of them when coming across them. I also don't think Kenos InterfaceSpecs.jl is the way forward either - I think there's quite a lot of design space left in the typesystem the language could do without reaching for z3 and other SAT/SMT solvers. I personally attribute the lack of progress on that front to the lack of coherent direction of the project at large (and specifically not to the failings of individuals - folks are always very busy with their lives outside of Julia development/other priorities). In spite of the fact that making this single area better could be a big boon with more traditional software engineers, which are very underrepresented in the community.
This article is a litany github issues for correctness bugs in library code, every one of which appears to have been fixed long ago now so it's not quite true to say there's been no rebuttal. Whether there remain a lot of correctness bugs in julia library code I can't say, but not these ones any more.
Maybe sometime from the realm of psychology would like to theorize why this article became so popular? I never found it compelling.
I think it's because evaluating a language is horribly complicated, and people crave certainty and the article sounds very definive. Maybe people see it as a sort of the article is right/Julia bas vs the article is wrong/Julia good.
Besides the 'correctness' issues, all of the issues that blogpost mentioned were fixed back then ASAP. Most of it arise from the usage of @inbounds, which to be fair, the documentation clearly tells you its usage is unsafe. Is it bad there were unrealized bugs in the official example? Yes. Did it get fixed immediately once reported? Yes. Mistakes happen everywhere else. I don't like the stance the blogpost took at all, and I find it quite misleading as it falsely implies Julia is bug-ridden. Personally, the number of bugs I've faced in Python is far more than the ones I've run into in Julia.
I remember reading this article and being curious I looked at all the correctness issues. I think I found almost all of the issues have been resolved. Of course, they might've gotten priority after the publication of this article and might not mean that the fundamental issues are not their. But I think it is a sign that the language is in continuous improvement.
Regarding the @inbounds problem. If removing @inbounds leads to out of bounds memory access, doesn't that mean it was masking a bug? Shouldn't it crash with a message like an assert?
I think those points are just the symptoms. The real problem is having an out of tree dependency on LLVM. It is too much work to keep up with. The LLVM project does not care about breaking their external users' code.
I wonder why ORNL used AMDGPU.jl directly rather than something like KernelAbstractions.jl, which doesn’t require you to overspecialize to a particular architecture. I realize Frontier is all AMD. But the DOE labs have flipped back and forth between HPC platforms a few times. (Which is partly why Sandia invested so heavily in developing Kokkos).
Given the amount of code involved, perhaps just out of fear the resulting code generation might not be as good? Rather a quick job to write something like that, but the scaling tests take a bit more time.
[+] [-] davidwritesbugs|2 years ago|reply
[+] [-] KenoFischer|2 years ago|reply
However, bugs in general suck and we've been thinking a fair bit about what additional tooling the language could provide to help people avoid the classes of bugs that Yuri encountered in the post.
The biggest class of problems in the blog post, is that it's pretty clear that `@inbounds` (and I will extend this to `@assume_effects`, even though that wasn't around when Yuri wrote his post) is problematic, because it's too hard (arguably impossible) to write correctly. My proposal for what to do instead is at https://github.com/JuliaLang/julia/pull/50641.
Another common theme is that while Julia is great at composition, it's not clear what's expected to work and what isn't, because the interfaces are informal and not checked. This is a hard design problem, because it's quite close to the reasons why Julia works well. My current thoughts on that are here: https://github.com/Keno/InterfaceSpecs.jl but there's other proposals also.
[+] [-] Sukera|2 years ago|reply
My own efforts (shameless plug, https://github.com/Seelengrab/PropCheck.jl for property based testing inspired by Hedgehog and https://github.com/Seelengrab/RequiredInterfaces.jl for somewhat formalizing "what methods are needed to subtype an abstract type") are unused in the wider community as far as I can tell, in spite of people speaking highly of them when coming across them. I also don't think Kenos InterfaceSpecs.jl is the way forward either - I think there's quite a lot of design space left in the typesystem the language could do without reaching for z3 and other SAT/SMT solvers. I personally attribute the lack of progress on that front to the lack of coherent direction of the project at large (and specifically not to the failings of individuals - folks are always very busy with their lives outside of Julia development/other priorities). In spite of the fact that making this single area better could be a big boon with more traditional software engineers, which are very underrepresented in the community.
[+] [-] adammarples|2 years ago|reply
[+] [-] eigenspace|2 years ago|reply
[+] [-] kdwikzncba|2 years ago|reply
I think it's because evaluating a language is horribly complicated, and people crave certainty and the article sounds very definive. Maybe people see it as a sort of the article is right/Julia bas vs the article is wrong/Julia good.
[+] [-] balencpp|2 years ago|reply
[+] [-] j_maffe|2 years ago|reply
[+] [-] phkahler|2 years ago|reply
[+] [-] rightbyte|2 years ago|reply
[+] [-] alechammond|2 years ago|reply
[+] [-] anewhnaccount2|2 years ago|reply
[+] [-] lukego|2 years ago|reply
That little kernel in Listing 2 sure packs a punch.
[+] [-] affinepplan|2 years ago|reply
[+] [-] pjmlp|2 years ago|reply
Moreso I would enjoy that somehow pressures Python folks to care about having a JIT in the box.
The only major mainstream scripting language left without one.
There are still Perl, Tcl, and Awk, however their use isn't as widespread nowadays.
[+] [-] WanderPanda|2 years ago|reply
[+] [-] c0k2z|2 years ago|reply
[deleted]