I just noticed this comment a few days late, so sorry for the delay in answering<p>Goals are documented in a roadmap doc: <a href="https://egranata.github.io/aria/ROADMAP.html" rel="nofollow">https://egranata.github.io/aria/ROADMAP.html</a> as well as issues on GitHub, and ideas are always very welcome, so please bring yours! I'd love to chat<p>I am not (yet) focused on performance, it's still at a point where the language and the library are changing. It runs decently well (as mentioned it's a stack based VM) such that you could actually use it to write some real programs. Good enough for a 0.9 I think<p>Technical choices, I have a few big ideas that stand behind the overall design:
- easy to pick up, flexible, run with, write code, "pleasing to the eye" is what you called, that's #1;
- a simple module system that works with you (with more improvements in the roadmap);
- easier to reason about errors (lots of things are Maybe/Result-style enums vs. exceptions) - this is somewhat inspired by Midori where errors are classified according to whether you can and should handle them (with exceptions as a somewhat middle ground);
- using Rust under the hood provides stronger memory safety guarantees than things written in C/C++ would out of the box (I have seen the occasional stack overflow error, and even that I would consider a bug, but no segfault core dump using Aria);
- no inheritance, prefer composition, reuse via mixins which are first class in Aria - I found this works quite nicely (for example, I can provide all comparison operators based on one function + a mixin: <a href="https://github.com/egranata/aria/blob/master/lib/aria/ordering/compare.aria" rel="nofollow">https://github.com/egranata/aria/blob/master/lib/aria/orderi...</a>)<p>Thanks for all the questions!