These are some random thoughts on Rust and Julia in ACT that I was going to just send to @davidad, but thought others might be interested as well.
The type system of Rust provides a far better development experience than Julia, and it’s much easier to reason about performance and correctness in Rust. Rust compiles down to executables that are easier to distribute anywhere, including on the web as WASM, and provides a much better and more principled ecosystem for networking stuff.
So what does Julia have going for it? In short, cheap metaprogramming. Rust is a very good language, but it is restricted to only use the tools for abstraction that are baked into the language, i.e. traits, generics, macros, etc. The introspection and dynamism of Julia means that new paradigms of abstraction can be implemented directly in Julia. For instance, Gatlab is essentially a ML-style module system baked into Julia, but with some computer-algebra twists that rely heavily on the introspectability of the module signatures. Such a thing would be impossible to pull off in Rust, as traits are a compile-time feature that are not introspectable by Rust code. The fact that we can use weird dynamic tools for abstraction, then produce new code on the fly and JIT-compile it make Julia an incredibly flexible language for constructing totally new language paradigms.
I hope that out of the froth and chaos of AlgebraicJulia, we can identify some essential abstractions, and then build a well-typed language that has them as first-class citizens. But creating a new programming language is a massive undertaking, and we probably only have one shot to “get it right.”
So in the meantime, here’s what I’m hoping.
First of all, we should be discovering math and “patterns of computation” that transcend language, and can be implemented deeply (i.e. embedded DSLs) or shallowly (DSLs implemented via parsing strings) in many languages. This way we can interface multiple languages, including the more traditional functional programming languages like OCaml, Scala and Haskell, dependent languages like Agda, Coq and Lean, and then enterprise languages like Python, Javascript and Java. ACSets are an example of this, where we have ACSet libraries in Julia, Scala, Python, Typescript, and Rust (coming soon). It would be good to identify other parts of AlgebraicJulia that could be “exported” in this manner, like perhaps GATs.
Secondly, more concretely, it might be interesting to look into tools for bridging Julia and Rust via their C-interfaces. GitHub - rusterlium/rustler: Safe Rust bridge for creating Erlang NIF functions is good inspiration for how this could work; incidentally it might also be interesting to look at ACT systems built in a hybrid of elixir and Rust, with elixir providing dynamism and then passing the heavy lifting off to Rust.
And finally, if we really take the idea of dynamic code generation seriously, we could start to implement larger typed languages which compile to Julia, and can be included in Julia programs using include(::Function, ::String), which transforms the AST of the file included using the provided function before compiling it. This could allow us to be more confident in our programs, while still leveraging all of the powerful AlgebraicJulia tools that we have accumulated over the years.
Anyways, my goal here was just to record my current thoughts and not to provide a concrete plan of action; I hope these thoughts are useful to anyone who likes AlgebraicJulia but misses the safety and comfort of static typing to explain that a) there are some benefits to not having static typing and b) we understand that static typing is nice too, and hopefully in the future we will work towards getting some of those benefits.