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

181–190 of 419 posts

Re: Correctness and composability bugs in the Julia ecosystem

#181

Post by chubot »

Oof, accessing out of bounds memory is pretty surprising to me for a dynamic language ... But I guess it's not surprising if your goal is to compile to fast native code (e.g. omit bounds checks).

I don't know that much about how Julia works, but I feel like once you go there, you need to have very high test coverage, and also run your tests in a mode that catches all bound errors at runtime. (they don't have this?)

Basically it's negligent not to use ASAN/Valgrind with C/C++ these days. You can shake dozens or hundreds of bugs out of any real codebase that doesn't use them, guaranteed.

Similarly if people are just writing "fast" Julia code without good tests (which I'm not sure about but this article seems to imply), then I'd say that's similarly negligent.

-----

I've also learned the hard way that composability and correctness are very difficult aspects of language design. There is an interesting tradeoff here between code reuse with multiple dispatch / implicit interfaces and correctness. I would say they are solving O(M x N) problems, but that is very difficult, similar how the design of the C++ STL is very difficult and doesn't compose in certain ways.

(copy of lobste.rs comment)

Re: Correctness and composability bugs in the Julia ecosystem

#182

Post by mbauman »

chubot wrote: post #181

Oof, accessing out of bounds memory is pretty surprising to me for a dynamic language ... But I guess it's not surprising if your goal is to compile to fast native code (e.g. omit bounds checks). I don't know that much about how Julia works, but I feel like once you go there, you need to have very high test coverage, and also run your tests in a mode that catches all bound errors at runtime. (they don't have this?) B…

You can also use `julia --check-bounds=yes` — and our testing frameworks automatically do so.

Re: Correctness and composability bugs in the Julia ecosystem

#184

Post by dang »

KenoFischer wrote: post #108

So this one is a tough one for me, because Yuri has certainly spent significant time with Julia and I think he's a very competent programmer, so his criticism is certainly to be taken seriously and I'm sad to hear he ended up with a sour opinion. There's a lot of different issues mentioned in the post, so I'm not really sure what angle to best go at it from, but let me give it a shot anyway. I think there's a couple…

Re the title: ok, we've replaced the submitted title ("The Julia language has a number of correctness flaws") with a representative phrase from the OP which uses the word 'ecosystem'.

HN's title rule calls for using the original title unless it is misleading or linkbait (https://news.ycombinator.com/newsguidelines.html) and "Why I no longer recommend Julia" is generic enough to be a sort of unintentional linkbait - I think it would lead to a less specific and therefore less substantive discussion. In that sense the submitter was probably right to change the title, and for the same reason I haven't reverted it.

I'm going to autocollapse this comment so we don't get a big thread about titles.

Re: Correctness and composability bugs in the Julia ecosystem

#185

Post by TimTheTinker »

rcthompson wrote: post #178
ChrisRackauckas wrote: post #44

Everything 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…

Is "for i in 1:length(A)" ever correct? Should Julia just emit a warning any time it encounters that pattern? Or maybe something slightly more complicated, such as that pattern followed by usage of i to index into A inside the loop?

> 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 of time what users aren't allowed to do. It's better to document what's usually the wrong way to do something than to enforce it in the design. You can never guess what amazing things people will create when they are given flexible, unrestricted primitives.

So for cases like this, I think it's better to rely on a flexible linting tool (if available) than warnings or errors.

[0] https://martinfowler.com/bliki/SoftwareDevelopmentAttitude.h...

Re: Correctness and composability bugs in the Julia ecosystem

#186

Post by IshKebab »

forgotpwd16 wrote: post #153
IshKebab wrote: post #124

I 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.

Did you tried Octave, GNU's numerical package that is compatible to MATLAB?

Of course! The language implementation is decent and the GUI is promising, except for the most important feature of the GUI - the plot viewer, which is completely awful. Forget about the same league, it's not even playing the same game as MATLAB.

Re: Correctness and composability bugs in the Julia ecosystem

#187

Post by KenoFischer »

dang wrote: post #184
KenoFischer wrote: post #108

So this one is a tough one for me, because Yuri has certainly spent significant time with Julia and I think he's a very competent programmer, so his criticism is certainly to be taken seriously and I'm sad to hear he ended up with a sour opinion. There's a lot of different issues mentioned in the post, so I'm not really sure what angle to best go at it from, but let me give it a shot anyway. I think there's a couple…

Re the title: ok, we've replaced the submitted title ("The Julia language has a number of correctness flaws") with a representative phrase from the OP which uses the word 'ecosystem'. HN's title rule calls for using the original title unless it is misleading or linkbait ( https://news.ycombinator.com/newsguidelines.html ) and "Why I no longer recommend Julia" is generic enough to be a sort of unintentional linkbait -…

Thanks. Appreciate your thoughtful moderation as always :).

Re: Correctness and composability bugs in the Julia ecosystem

#188

Post by mattkrause »

grumpyprole wrote: post #174
ChrisRackauckas wrote: post #44

Everything 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. Yes but Julia is (yet another) dynamic language, presumably for "ease of use". A language with static types would have made it easier to build correct software (scientific code in e.g. OCaml and F# can look pretty good). Julia chose a path to maximize adoption at the expense of building a reliable ecosystem. Not all languages choose to make this trade-off.

I'm surprised at this critique, as I thought Julia's type system was often considered to be one of its strongest features.

Re: Correctness and composability bugs in the Julia ecosystem

#189

Post by mbauman »

kazinator wrote: post #176
mbauman wrote: post #172

Earlier quoted context omitted.

`eachindex` is — in quite a few situations — faster than `1:n`. We've also been trying to promote a culture of not blindly putting `@inbounds` notations on things as the compiler gets smarter. `@inbounds` is a hack around a dumb compiler, especially when the loop is as simple as many of these examples. It's not needed there anymore (but was 5 years ago).

The question is: is it at least as fast in all situations? Was it always that way? The 1 to length loop just has to initialize a local variable and step it; it cannot do anything else. It doesn't worry about the kinds of array that A may be, with its particular configuration of indexing, right? You may promote a culture of not doing certain things, but that by itself won't make those things disappear from existing co…

> The question is: is it at least as fast in all situations? Was it always that way?

Yes and yes.

Re: Correctness and composability bugs in the Julia ecosystem

#190

Post by rashidrafeek »

rcthompson wrote: post #178
ChrisRackauckas wrote: post #44

Everything 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…

Is "for i in 1:length(A)" ever correct? Should Julia just emit a warning any time it encounters that pattern? Or maybe something slightly more complicated, such as that pattern followed by usage of i to index into A inside the loop?

It is correct if `A` is of type `Array` as normal Array in julia has 1-based indexing. It is incorrect if `A` is of some other type which subtypes `AbstractArray` as these may not follow 1-based indexing. But this case errors normally due to bounds checking. The OP talks about the case where even bounds checking is turned off using `@inbounds` for speed and thus silently gives wrong answers without giving an error.

An issue was created sometime ago in StaticLint.jl to fix this: https://github.com/julia-vscode/StaticLint.jl/issues/337

Post reply on HN