alumina VS leo

You can go surprisingly far with C, though LLVM is probably a better long-term option for a serious compiler, because it's a tool made for the job (unless you target exotic and/or embedded platforms that don't have LLVM support - but that's fairly unlikely).

C is very easy to get started with if you don't already know LLVM. The downside is that once your compiler is reasonably complete, you may spend quite a bit of time working around quirks of C (e.g. int promotion is very annoying when you already have full type information, so your compiler either has to understand C semantics fairly well or defensively cast every subexpression).

I have a C backend in my compiler (https://github.com/alumina-lang/alumina) and it works really well, though the generated C is really ugly and assembly-like. With #line directives, you can also get source-level debugging (gdb/lldb) that just works out of the box.

There are a few goodies that LLVM gives you that you don't get with C, like coverage (https://clang.llvm.org/docs/SourceBasedCodeCoverage.html). It works when done through clang, but easily be made to track the original sources.

Totally agreed about FFI. I wanted to make it easy to interop with C code and write expressive bindings.

Check for example the language bindings to LLVM's C API (fairly low level) and Tree-Sitter which is used internally (a bit higher level bindings)

https://github.com/tibordp/alumina/tree/master/libraries/llv...

https://github.com/tibordp/alumina/blob/master/libraries/tre...

However, I am not super happy with the current structure of the compiler and for the self-hosted one I'd like to fix those mistakes. For example, mono.rs is a giant module that does everything from mixin expansion, lowering from AST to IR, type checking and monomorphization. There are some bugs in Alumina that are quite hard to fix without a big refactoring (e.g. if a nested function binds generic parameters of the parent) and I'd like to get it right the next time around.