Thanks. To answer your question, the current Rust codegen is pretty terrible performance wise, and all stack manipulations happen to a global mutable Vec. I’m hoping by switching to Erlang, I can take advantage of some of its list and pattern matching optimization, as well as TCO. It would also mean a new focus for the language, as I could add concurrency features as a goal rather easily.
This sound weird. Erlang is "slower" than Rust, like a lot and specially in this kind of stuff.
It’s not that Erlang is faster than Rust, but that the way I would translate Mlatu to Erlang would be more natural and Erlang-like than the current translation to Rust is, which would probably entail performance improvements.
I understand that clashing semantics could lead to this, but also think maybe you need a different data structure/patter on Rust? Anyway if you also will leverage more stuff from the Erlang ecosystem is certainly the way to go.
I was/am using a `Vec<Rep>` where `Rep` is an enum containing the different primitive types of Mlatu, which worked fine semantically but was just very slow for the amount of pushing and popping off I had to do. Thanks for your response, I do think I want to leverage more stuff from the Erlang.