3 ms·

If you look at the history of lots of packages in matlab they fixed tons of bugs that sound similar to this stuff over the years. It requires consistent hard wo

by xt00 4y ago

If you look at the history of lots of packages in matlab they fixed tons of bugs that sound similar to this stuff over the years. It requires consistent hard work by a core group of people who understand the issues to get everything right. I have no idea who maintains Julia and these packages but the author of the article mentions this as language problems — aren’t these just bugs? Like if gcc was incorrectly multiplying some constant by the wrong value, that doesn’t sound like a bug with C but a bug with gcc right?

dandanua 4y ago
Julia has more than 18k closed issues on its github. No wonder such an active user encountered a lot of it. It's not a problem with the language, though. Yes, it allows to use offsetarrays and @inbounds together, but C can read out-of-memory locations too, so what? Edit: Julia is better than C in this regard, since the usage of @inbounds is explicit, i.e. everyone can see that the code is potentially unsafe.
- rob74 4y ago
  I think the point he was trying to make was that the example for @inbounds from the official documentation could cause out-of-bounds accesses, while it was clearly stated that you should only use @inbounds if you are sure that no out-of-bounds accesses are possible.
  - jakobnissen 4y ago
    The issue is that there is no way to verify if OOB access is possible given an abstract type, unless you know how that type behaves, i.e. how it's indexed. And Julia provides no way of specifying the behaviour of abstract types.
    - markkitti 4y ago
      > And Julia provides no way of specifying the behaviour of abstract types. I'm not sure if "no way" is accurate. There are interfaces and one could use traits. As cited above, we could use `eachindex` or `CartesianIndices` to get a list of the valid indices. The problem is enforcing and testing these interfaces.
      - jakobnissen 4y ago
        There are no interfaces in Julia. There is simply documentation, and the hope that people will read, understand, and follow it.
- Gwypaas 4y ago
  > but C can read out-of-memory locations too, so what? Simply decades of exploitable security issues.
  - krastanov 4y ago
    The Julia example is closer to Rust's `unsafe`. Pretty much every language let's you skip bound checks, in Julia (like other modern languages) it is elective. The author was complaining about a library that decided to skip the bound check in a clumsy way (there happens to be a "correct" way to skip the bound check). It is not really about the language.
    - Gwypaas 4y ago
      Then it makes sense. Thanks for the clarification. Was worried that skipped bounds checks was something more intricate than simply explicitly annotating a statement to say "trust me, I know what I'm doing!".
- masklinn 4y ago
  > but C can read out-of-memory locations too, so what? So it's widely considered a plague upon the field, suffered because of the lack of alternative?
kazinator 4y ago
The author's point seems to be something like: not only are there these bugs, but there is a lot of them that people are running into regularly, and the project isn't headed in a direction where the situation as such will improve (as in even if these are fixed, by the time that happens, there will be even more). Hard to prove or disprove.

by xt00 4y ago

dandanua 4y ago

Julia has more than 18k closed issues on its github. No wonder such an active user encountered a lot of it. It's not a problem with the language, though. Yes, it allows to use offsetarrays and @inbounds together, but C can read out-of-memory locations too, so what? Edit: Julia is better than C in this regard, since the usage of @inbounds is explicit, i.e. everyone can see that the code is potentially unsafe.

rob74 4y ago
I think the point he was trying to make was that the example for @inbounds from the official documentation could cause out-of-bounds accesses, while it was clearly stated that you should only use @inbounds if you are sure that no out-of-bounds accesses are possible.
- jakobnissen 4y ago
  The issue is that there is no way to verify if OOB access is possible given an abstract type, unless you know how that type behaves, i.e. how it's indexed. And Julia provides no way of specifying the behaviour of abstract types.
  - markkitti 4y ago
    > And Julia provides no way of specifying the behaviour of abstract types. I'm not sure if "no way" is accurate. There are interfaces and one could use traits. As cited above, we could use `eachindex` or `CartesianIndices` to get a list of the valid indices. The problem is enforcing and testing these interfaces.
    - jakobnissen 4y ago
      There are no interfaces in Julia. There is simply documentation, and the hope that people will read, understand, and follow it.
Gwypaas 4y ago
> but C can read out-of-memory locations too, so what? Simply decades of exploitable security issues.
- krastanov 4y ago
  The Julia example is closer to Rust's `unsafe`. Pretty much every language let's you skip bound checks, in Julia (like other modern languages) it is elective. The author was complaining about a library that decided to skip the bound check in a clumsy way (there happens to be a "correct" way to skip the bound check). It is not really about the language.
  - Gwypaas 4y ago
    Then it makes sense. Thanks for the clarification. Was worried that skipped bounds checks was something more intricate than simply explicitly annotating a statement to say "trust me, I know what I'm doing!".
masklinn 4y ago
> but C can read out-of-memory locations too, so what? So it's widely considered a plague upon the field, suffered because of the lack of alternative?

kazinator 4y ago

The author's point seems to be something like: not only are there these bugs, but there is a lot of them that people are running into regularly, and the project isn't headed in a direction where the situation as such will improve (as in even if these are fixed, by the time that happens, there will be even more). Hard to prove or disprove.