Censera/asteri

asteri* is an ambitious and interesting project: a compiled, statically typed DSL aimed at game development, implemented in Rust with LLVM through inkwell. What stands out immediately is that this is not just a syntax sketch or toy README. The repository has a real compiler pipeline split into lexer, parser, semantic analysis, AST, codegen, errors, and CLI plumbing, plus integration-style tests that compile .ast files into native binaries and assert exit codes or output. The documentation is also refreshingly honest about the state of the language: the README gives users a clean quick start, while doc/prg.md separates what compiles today from what only parses/type-checks and what is still planned. That kind of transparency matters a lot for a language project, especially one with a broad goal like becoming an all-in-one environment for game development.

The strongest part of the project is the shape of the foundation. The language already has a coherent identity: fn, let, immut, explicit return types, casts with ->, pointer syntax, structs, lambdas/thunks, match syntax, and short aliases for scripting. The parser and semantic analyzer show thoughtful work beyond the happy path, including scoped symbol tables, function/type validation, loop context checks for break/continue, struct method lookup, optional pointer compatibility, and parser recovery. The CLI is practical too: run, build, check, dev, version, and help are the right early commands for this kind of tool. The Nix flake, release workflow, and LLVM 20 installation notes also show that the author is thinking about reproducible setup and distribution rather than leaving users to reverse-engineer the environment.

The main improvement area is production readiness and consistency between documented features and currently buildable implementation. The progress doc is clear that many features are not compiled yet, but the codebase itself appears to contain some compile-time issues in src/codegen.rs around formatted strings/string handling, including misspelled or undefined identifiers and type API mistakes. I could not run cargo check locally because this environment does not have cargo installed, but these sections look like they need immediate attention before users can rely on the published install flow. I’d recommend making CI the source of truth here: keep cargo fmt, cargo clippy, and cargo test passing on every push, and consider adding small “expected failure” tests for parsed-but-not-compiled features so the boundary is explicit.

For the next stage, I’d focus the README around one fully supported vertical slice: install, write a tiny program, type-check it, build it, run it, and explain exactly which language constructs are safe to use today. The current docs are promising, but a few typos and mismatches make the project feel rougher than the engineering effort deserves. A small examples directory with “works today” programs would help a lot, especially for functions, casts, printing, and eventually control flow. Overall, asteri* has a strong early compiler-project feel: ambitious, personally designed, already more substantial than a concept repo, and worth watching as the codegen catches up to the language design.