Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Correctness and composability bugs in the Julia ecosystem

yuri.is

Post reply on HN
Print view View original

201–210 of 419 posts

Re: Correctness and composability bugs in the Julia ecosystem

#201

Post by cbkeller »

Sporktacular wrote: post #150
cbkeller wrote: post #145

Earlier quoted context omitted.

I actually wouldn't be surprised if the total number of tests run in the Julia ecosystem wasn't too different (thousands of packages with typically hundreds to thousands of unit tests, run on every commit and PR) -- virtually every Julia package has CI set up (at least standalone unit tests, though many packages could use more integration tests). Of course, in neither Matlab nor Julia do tests guarantee correctness.

Is that tests for the purpose of verifying correctness or tests of applications that will flag problems incidentally? I'm not too familiar, but like the idea of dedicating resources to that specifically. Guarantees aside, does MATLAB have an issue with this to the same extent as Julia?

Personally I'd probably categorize most unit tests as verifying correctness (but only for the scenarios tested); integration tests may be more useful for finding incidental issues that you wouldn't have thought to test for directly. I'm for sure on board with dedicating more resources to testing -- and in my case as an academic, this is something I only have really been exposed to as a result of interacting with the Julia community.

Matlab is pretty mature at this point, but I'm sure it's had its share of bugs over the years as well (especially if you also counted the file exchange, which is probably the closest thing they have to an open source package ecosystem); it would be interesting to compare the two at a similar level of maturity / development person-hours if quantitative data could be found.

Re: Correctness and composability bugs in the Julia ecosystem

#202

Post by runevault »

mattkrause wrote: post #97
RcouF1uZ4gsC wrote: post #17

> If you pass it an array with an unusual index range, it will access out-of-bounds memory: the array access was annotated with @inbounds, which removed the bounds check. It think making indexes configurable is a huge mistake. Even if they are not ideal for the situation, having a single way to do indexes makes a huge source of confusion and potential bugs just go away. And this is orthogonal to whether you pick 0 or…

There's a parallel idea, that you should avoid--insofar as is possible--numerical indexing. In other words, instead of iterating over `0:length(X) - 1` or `1:length(X)`, you use something like `for element in array` or indices = CartesianIndices(multidimensional_X) for index in indices X[index] = # whatever If you do that, you don't need to keep track of whether it's zero-based, one-based, or anything else. In fact,…

I'm only skimming this post and I'm not familiar with Julia so maybe I'm missing it, but does it have a way to get an item AND its index? There's I think Enumrable? in Rust where it gives you a tuple with both the item and its index in cases where you need both.

Re: Correctness and composability bugs in the Julia ecosystem

#203

Post by buescher »

snicker7 wrote: post #175
cozzyd wrote: post #163

Earlier quoted context omitted.

In my experience it's much harder to write Python that won't crash than C/C++ that won't crash. With Python, rarely taken code paths can have very dumb errors in them (e.g. accidentally introducing a new variable with a different name than the variable you wanted or typoing a method name, or passing arguments with the wrong type) that would get caught by a C/C++ compiler but won't be caught in Python until the crash…

C/C++ memory errors are literally responsible for 70% of ALL critical security bugs. Most python "dumb errors" can be caught by linters. Memory is infinitely harder. Source -- https://msrc-blog.microsoft.com/2019/07/16/a-proactive-appro...

And Python is implemented as a large C program.

Re: Correctness and composability bugs in the Julia ecosystem

#204

Post by freemint »

As a huge fan of Julia i got to fully agree. Although i would probably not "no longer recommend Julia" but "give huge caveats when mentioning Julia". Organisations (that includes those who maintain programming language) have values Bryan Cantrill has an excellent talk on this https://youtu.be/2wZ1pCpJUIM and i got to agree with the author that correctness (especially correctness under arbitary composability) is not a value that Julia teaches and instills in its users. Some Julia users care about this, some core maintainers do to (as the Pkg3 demonstrates). However there are many invocations (SafeTestSets vs Test) and stumbling blocks. I am aware of no efforts to do formal verification on Julia code. There are no good ways to move certain Run-Time to compile errors. Correctness is not a value of the Julia language. Here is the good thing though, as Bryan demonstrates in his talk, you can hire for values.

Re: Correctness and composability bugs in the Julia ecosystem

#205

Post by dash2 »

IshKebab wrote: post #130
sdfhdhjdw3 wrote: post #29

Earlier quoted context omitted.

The problem isn't that 1-base indexing can be "fixed" in Julia. The problem is that you see 1-based indexing as a flaw.

It is a flaw. Computers don't work that way fundamentally, and it introduces lots of awkward translation.

But humans don't work 0-based. Try explaining to a bunch of scientists why for rows 2-5 of the DataFrame they have to write df[1:5].

Re: Correctness and composability bugs in the Julia ecosystem

#206

Post by freemint »

markkitti wrote: post #111
CoastalCoder wrote: post #23

Earlier quoted context omitted.

I think the real test will be whether or not Julia's custodians / developers start putting a greater focus on semantics and correctness. When a language's raison d'être is to try out certain ideas, it probably makes sense for a while to ignore corner cases and rigor. But as the author points out, they eventually become gating factors for wider adoption.

The question here is are these merely just bugs or is there something about the language that makes Julia error prone? There is potential in using Julia's type inference engine to check for correctness. For example see JET.jl. "JET.jl employs Julia's type inference to detect potential bugs." https://github.com/aviatesk/JET.jl https://www.youtube.com/watch?v=7eOiGc8wfE0 The video brings up some potential difficulties…

Jet.jl is far from a solution. Over short or long JuliaComputing (or someone else) will have to pay people full time to develop such tools if it wants to see larger adoption. Nobody expects Julia to be system language a language you write an OS in). The later those tools come the more code will need to be fixed up.

Re: Correctness and composability bugs in the Julia ecosystem

#207

Post by IshKebab »

dash2 wrote: post #205
IshKebab wrote: post #130

Earlier quoted context omitted.

It is a flaw. Computers don't work that way fundamentally, and it introduces lots of awkward translation.

But humans don't work 0-based. Try explaining to a bunch of scientists why for rows 2-5 of the DataFrame they have to write df[1:5].

Yeah because humans got it wrong. Really the word for "first" should correspond to the number 0.

Try doing a block iteration over an array, or any kind of interval algorithms in 0-based and 1-based. 0-based with right-open intervals just results in way way more elegant, easier to understand and (very) slightly more efficient code.

Re: Correctness and composability bugs in the Julia ecosystem

#208

Post by tgv »

rendall wrote: post #20
fgh wrote: post #7

It would be interesting to know which language the author currently uses.

The author mentions that he was stuck on a problem for weeks using Julia, but solved it with Python within hours

That was someone else: Patrick Kidger is mentioned in the article. If I look at the author's github, it's go and javascript.

Re: Correctness and composability bugs in the Julia ecosystem

#209

Post by cbkeller »

ModernMech wrote: post #102

> OffsetArrays in particular proved to be a strong source of correctness bugs. The package provides an array type that leverages Julia’s flexible custom indices feature to create arrays whose indices don’t have to start at zero or one. I always thought this sounded like a bad idea. I remember one time I was working with a C++ guy on a Matlab project, and he handed me some Matlab code with 0 based indexing assumed. I…

For it to silently fail of course though, he would have had to explicitly used the OffsetArrays package and explicitly switched all `Array`s to `OffsetArray`s (which hopefully you would notice) -- and then you would have to go ahead and use those OffsetArrays in a package which doesn't support them; if you just go ahead use 0 as an index in plain Julia code it will error as you would expect.

Re: Correctness and composability bugs in the Julia ecosystem

#210

Post by ViralBShah »

p33p wrote: post #18

Viral frequents HN so I will be curious to see if he engages this directly in a productive manor. There are many great qualities of Julia, and I've wanted to love it and use it in production. However, coming from the tooling and correctness of Rust leaves me thinking something is just missing in Julia. One of the links in the post references "cowboy" culture. While I don't think this is the correct nomenclature, ther…

I think Keno's comment above pretty much articulates my thoughts as well. I have met Yuri on several occasions and have been thrilled to see his contributions. I find the post constructive and it will certainly help make Julia better, and hope Yuri will be back at a later date.

Some of the issues linked are JuliaStats issues, and there's a lot happening to improve it, which should become more visible over the next few months. Example: https://discourse.julialang.org/t/pushing-julia-statistics-d...

Julia really pushes on language and compiler design in ways many statically typed languages do not. There is real wok to be done at the frontiers, and also investment in tooling built on top of that. It is all happening. The package ecosystem takes time to mature - Julia has a deliberate release process, the key packages have adopted a more deliberate release process, but stuff out in the long tail naturally tends to move fast - as it should.

Post reply on HN