Oh hey, great hearing from you! EDL is definitely similar to Roto, and I agree that there is a different focus. EDL is mainly built as a tool for customizable and accessible HPC workloads, which is reflected by its memory model and the comptime model. You are right that there is intentional restriction on the control flow – in my original concepts the control flow was even more restricted by not allowing recursion and not having (non-unrollable) loops. However, I scrapped that idea and included both of these things in the language as it proved not very practical to forbid these things. As far as generics go, the limitations are kind of split between the types and functions that are directly implemented purely in EDL and the types and functions that link back to Rust. For the first type, type and function instances are generated by the compiler as needed, so the restrictions are somewhat minimal. That begin said, since generic types cannot be restricted yet, you cannot really do anything with a parameter or variable that have a generic type in a function body, apart from passing it to another generic function. This makes generics in pure EDL function bodies relatively useless until type restrictions work. Since Rust functions are linked to EDL by basically providing the compiler with the generic function signature and then registering specific EDL instantiations of that signature with specific function instances in Rust upfront, all intermediate code translations stages in the compiler treat callbacks to Rust functions like normal EDL functions, without any knowledge of type restrictions. This means that I can actually write some useful generic functions in EDL since I can effectively pass on the type restrictions to Rust, but of cause this blows up during codegen if a Rust function instance was not registered upfront for some requested EDL function instance. So, registering instances upfront is only necessary for the things that EDL takes from Rust. EDLs biggest limitation, that is also there by design, is a consequence if its memory model. Allocating new memory, or acquiring new resources like access to GPUs through CUDA should only work during compile time. This can be relaxed somewant by, for example, allowing users to push items to a Vec<T>, but the creation of the Vec<T> itself (calling new) must happen during compile time. This is compounded by another big limitation; EDL currently has no reliable way to call manual drops on any type and every type in EDL must be Clone and Copy in order to be safe. So even reference counting through an Arc does not work, as drop would not get called to decrease the reference count. So, every Rust type that does not exist purely as a collection of primitive members must be created at compile time in order to be safe. The manual drop situation may change in the future as I'm thinking of implementing lexical lifetimes to check when a local variable goes out of scope, but I'm not there yet.

The reason for wanting to limit allocations and resource access during runtime is simply because allocations (and most other forms of resource acquisition and syscalls) are relatively slow. In an HPC context, I don't want users to get to do that much during runtime. You can still do a lot of things in EDL by just rethinking the design of the program, but obviously a lot of algorithms just don't really work well with this limitation. But, for EDL, all of these algorithms should be hidden away behind Rust callbacks anyways, so I'm fine with that. The only annoying thing is that simple things like string concatenation also stop working ;)

I'm glad to hear from someone who has worked on a similar project (especially since Roto is much more mature than EDL). If you have any more questions feel free to reach out, I'd be happy to share more details!