StaticLint.jl VS JET.jl

Yes, tooling around this is being developed in the form of linters (e.g. https://github.com/julia-vscode/StaticLint.jl) and through real compiler integration tools like the very cool https://aviatesk.github.io/JET.jl/dev/ but this is definitely somewhere that the tooling in julia is weaker than in other languages. It seems to be picking up a lot of speed though.

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 giving 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

Statically lint = find errors in the Julia file like using variables that are not defined, and functions with the wrong arguments. For Julia, StaticLint.jl is an actively developed library that does static linting. It basically provides a bunch of functions that spit out errors in your Julia file like those that I mentioned above. If you are an Emacs editor user, this project is like a "convenience" which will run Julia silently in the background, and communicate with it to extract errors in the file that you currently have open. These errors are then highlighted in your editor view using the Flycheck package that is one of the ways to highlight errors in Emacs.

An informative discussion on julia forum. Have you tried using https://github.com/aviatesk/JET.jl to minimize type instabilities?

For instance, https://github.com/aviatesk/JET.jl is still in its relative infancy, but it's played a big role in detecting quite a few potential bugs that had never been reported to use by users or caught in our testing infrastructure. There's also been a lot developments like interfaces to RR the time travelling debugger https://rr-project.org/ which helps us better understand and catch some very hard to debug non-deterministic bugs.

Have you seen Shuhei Tadowaki's work on JET.jl (?)

If you're curious: https://github.com/aviatesk/JET.jl

This may seem more about performance (than IDE development) but Shuhei is one of the driving contributors behind developing the capabilities to use compiler capabilities for IDE integration -- and indeed JET.jl contains the kernel of a number of these capabilities.

This is sort of being done right now, as dynamic languages have begun to adopt gradual typing... at least Python and Julia, that I know of.

If something like [JET.jl](https://github.com/aviatesk/JET.jl) become ubiquitous in Julia, one could add a function that pointed out all the places in the code where types are not fully inferred by the compiler.

It'll never be quite the same level of safety as a static language, however.

- Pattern matching (sometimes you don't want the overhead of a method lookup)

[1]: https://github.com/aviatesk/JET.jl

You can use the `@code_warntype` macro to check for type stability, which is very helpful for detecting such performance pitfalls on single function level. In the future, https://github.com/aviatesk/JET.jl may give a more powerful way to do it.