JET.jl VS StaticArrays.jl

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.

Performance is already 100 times faster than Sympy, but I was running into slowdowns computing the adjugate of the matrices I'm working with. I turned to the StaticArrays.jl module, which did speed up performance, but threw an error at me when the matrix in question went from a 4x4 to a 5x5. Here is the code used to generate the matrices:

I know this is the Rust subreddit, but I have to ask if you considered Julia? It seems purpose-built for what you're trying to do. It has built-in multidimensional arrays which are significantly more ergonomic to use than either Python or Rust, and because of the way the type system works there are tons of specialized array types you can use with optimized operations (and writing your own is quite easy). In particular you might be interested in StaticArrays.jl which if your arrays have a known, small size at compile-time can give a massive speedup by essentially automatically doing many of the optimizations you did by hand. They show a 25x speedup on eigendecompositions for a 3x3 matrix on their microbenchmark.

Use StaticArrays.jl instead of the built-in Array whenever you need some statically sized array/matrix.

2. Persistent data structures as found in most FP languages.

Note how neither of these capture the large, (semi-)contiguous array types used for most numerical computing. These arrays are only "easier to optimize" if one has a Sufficiently Smart Compiler to work with. Here we don't even need to talk about Julia: the reason even Numba kernels in Python land are written in a mutating style is because such a compiler does not exist. You may be able to define something for a limited subset of programs like TensorFlow does, but the moment you step outside that small closed world you're back to needing mutation and loops to get a reasonable level of performance. What's more, the fancy ML graph compiler (as well as Numpy and vectorized R) is dispatching to C++/Fortran/CUDA routines that, not surprisingly, are also loop-heavy and mutating.

Should Julia do a better job of trying to optimize non-mutating array operations? Most definitely. Is this a hard problem that has consumed untold FAANG developer hours [2] and spawned an entire LLVM subproject [3] to address it? Also yes.

> The iteration protocol can be made more memory-efficient for large collections and simpler...

Yup, this has been a consistent bugbear of the core team as well. The JuliaFolds ecosystem [4] offers a compelling alternative with fusion, automatic parallelism, etc. in line with that blog post (which, I should note, is a much different beast from Rust's iterator interface/Rayon), but it doesn't seem like the API will be changing until a breaking language release is planned.

> In general, systems languages don't make language decisions lightly. They have committees, discuss how other languages do things, make proposals. This allows more perspectives on each decision. That would be an improvement over the more ad-hoc style of Julia development, as long as Julia can avoid adding every possible feature, which is a risk of expanding the decision-making body.

I'd argue this is a property of mature, widely used languages instead of systems languages. Python, Ruby, JS, PHP, C# and Java are all examples of "non-systems" languages that do everything you list, while Nim and Zig (note: both less well adopted) are examples of "systems" languages that don't have such a formalized governance model.

Julia (along with Elixir) are somewhere in between: All design talk and decision making is public and relatively centralized on GitHub issues. There is no fixed RFC template, but proposals go through a lot of scrutiny from both the core team and community, as well as at least one round of a formal triage (run by the core team, but open to all). Any changes are also tested for backwards compat via PkgEval, which works much like Crater in Rust. There was a brief effort to get more structured RFCs [5], but I think it failed because the community just isn't large enough yet. Note how all the languages with a process like this are a) large, and b) developed it organically as the userbase grew. In other words, you'll probably see something similar pop up when the time savings provided by a more structured/formal process outweighs the overhead of additional formalization.

[1] https://github.com/JuliaArrays/StaticArrays.jl

If you want to lift your value into the type domain, you may be able to use value-types, like Val(2). If you are interested in seeing how to use value-type parameters efficiently, https://github.com/JuliaArrays/StaticArrays.jl does that to great effect.