New languages usually launch with a compiler and not much else. Editor support, a debugger and a fast backend tend to arrive years later, if at all. I wanted to see how far one person could go the other way, so saQut, a small statically-typed, C-flavoured procedural language written in C++20, ships all of this in a single binary:

• a bytecode VM as the reference backend
• a MIR-based JIT (--jit) that produces the same output as the VM
• an LSP server (saqut lsp): completion, rename, references across files, auto-import
• a DAP debugger (saqut dap): breakpoints, stepping, variable inspection
• a preview of threads, each in its own isolate
• a VS Code extension for highlighting

The other idea is that the compiler is a "glass box": every stage is a CLI command with machine-readable output.

saqut tokens code.sqt # token stream (JSON)
saqut ast code.sqt # AST (JSON)
saqut symbols code.sqt # symbol table (JSON)
saqut ir code.sqt # 3-address IR
saqut run code.sqt # compile and run

Technical notes

• A differential test harness runs every test program through the VM and the JIT and fails if the output differs.
• One garbage collector is shared by both backends (cycles are collected).
• Catchable runtime errors (try/catch/throw) with a code, message and source location.
• Threads: each thread has its own heap, GC and copy of the globals. Data crosses only through shared globals (atomic int/float/bool, plus Pool and List) or deep copies. This is a preview and not part of the 1.0 contract.
• No implicit conversions; nullable types (T?) with flow analysis.

It's a one-person project, so there are rough edges, and I'd rather hear about them from you.

Website: https://saqut.com
Source: https://github.com/saqutlang/saqut

Which compiler phase would you want to inspect that isn't exposed yet? And what would you add to this list?

We presented this a while ago at the LLVM-CGO workshop, but thought of sharing here as people might find it interesting. Pretty short paper.

Hi everyone! I built Hussain Compiler, a simple browser-based environment for writing and running Python.

It includes a code editor, an interactive terminal that supports `input()`, adjustable terminal text size, and resizable workspace panels. Python runs in the browser through WebAssembly, so you can try it without installing Python. Some packages that need native system extensions may not work.

- Try it: Hussain Compiler

- Source code: GitHub repository

I made this project to make getting started with Python easier. I’d appreciate your feedback and suggestions for what to improve.

The main goal isn't just to make Rust simpler and familiarity in syntax. Flame is designed to keep memory safety while providing Rust interoperability, so it can be used alongside existing Rust code and libraries. It's meant to complement Rust rather than replace it.

Looking for people interested in building a compiler / AI-systems project — potential GSoC 2027 goal

A few of us are exploring a long-term open-source project around compiler technology, systems programming and AI/ML.

We're currently in the research/learning stage. We don't want to simply build another tutorial compiler and stop there. The plan is to learn compiler implementation properly, study existing open-source compiler ecosystems, identify a real technical problem, and then build something substantial around it.

We're particularly interested in exploring:

• AI/ML-guided compiler optimization

• Detecting potentially harmful optimizations and miscompilations

• Compiler correctness and fuzzing

• AI-assisted compiler diagnostics/error recovery

• LLVM / MLIR

• Code generation and optimization

• RISC-V and systems programming

• CPU/GPU/NPU compilation

• Compiler security

• Firmware/compiler intersections

We're also considering GSoC 2027 as a long-term goal. This isn't a promise of selection; the idea is to spend the coming months building knowledge, contributing to open source, and eventually finding an organization/project where our work could become a legitimate GSoC proposal.

You don't need to already be a compiler expert.

We're looking for people who genuinely want to learn, experiment and build innovative projects. If you want this purely as a hobby/side project, that's completely fine too. If the idea interests you, give it a shot.

Useful backgrounds/interests include:

• Rust / C / C++

• Compiler design

• LLVM / MLIR

• Systems programming

• Machine learning

• Programming languages

• Computer architecture

• Embedded systems / firmware

You don't need to know everything above.

If interested, comment or DM with:

• What languages you know

• What area interests you

• Anything you've built

• GitHub, if available

We're looking for people who are curious enough to learn and consistent enough to build.

Ant Group's new Ling-3.1-flash built a Lua-to-x86-64 ELF compiler from scratch in approximately 17 hours. The final result passed 178 of 182 independent tests, a 97.8% pass rate.

The development sequence goes beyond emitting machine code. It includes fixing stack alignment for native execution, conditional branches and vararg semantics, Lua's indexing metamethod lookup, and garbage-collector root tracking. The compiler also gained source locations for runtime errors before delivering ELF binaries.

Ling-3.1-flash is currently available through Novita's two-week free trial on Vercel AI Gateway, with 256K context. Ant has an open-source release planned soon. The hosted model can be found by searching Ling-3.1-flash in Vercel's AI Gateway model catalog.

I’ve been building NetWasm: a CIL-to-WebAssembly compiler with its own CoreLib and runtime, designed around Wasm and WASI.

Browser playground | GitHub

A clean Release build containing Console.WriteLine(42) produces 84,513 bytes of final, uncompressed WASI Preview 2 component, including the runtime and precise garbage collector. This is a portable .wasm file that you can run with wasmtime.

Roslyn produces CIL; NetWasm compiles the reachable program into Wasm, specializes generics and links the runtime support it uses. The emitted application doesn’t carry CoreCLR or Mono.

Some architectural choices:

• An independent, deliberately smaller .NET library profile.
• No runtime type-name metadata, general reflection or dynamic.
• Precise Boehm GC in linear memory, rather than WasmGC.
• WIT imports/exports and WASI Preview 2 components, with core Wasm output also available.

Working features include generics, exceptions, virtual/interface dispatch, async/await, LINQ, JSON, XML, regex, HTTP and TUnit testing. It’s pre-1.0, and managed threading isn’t currently supported.

The playground compiles and runs entirely in the browser. The compiler tooling itself uses Microsoft’s .NET/Wasm toolchain, thus dotnet new dotnet build dotnet run dotnet test - yes it comes with TUnit with VSTest runner - dotnet publish all work as you're used to.

Oh and it already supports C# 15 syntax.

Hi everyone,

I've been building Udodi (v1.1.1), an open-source JavaScript UI runtime from Nigeria. It takes a different approach to reactive UI rendering by eliminating the Virtual DOM and connecting state changes directly to the DOM nodes that depend on them.

Udodi is designed to work without a build step while supporting restrictive Content Security Policies (CSP). Its architecture combines an interpreted template virtual machine, fine-grained reactivity, and native browser primitives.

I'd like to open a technical discussion about the trade-offs of this approach, particularly its potential scaling limitations and how it compares with the architectural choices made by other UI frameworks.

Architecture

1. Fine-grained DOM updates

Rather than maintaining and diffing a Virtual DOM, Udodi tracks dependencies at the expression level and updates only the affected DOM nodes. In my benchmarks, a targeted state update averages 0.11 ms.

2. Native CSS @scope

For component styling, Udodi uses native CSS @scope instead of runtime CSS-in-JS or generated class names. Component styles are registered in a shared <style> element in document.head and cached by scope. Subsequent mounts using an existing scope skip style registration entirely. Under the benchmark conditions, the warm style-handling path takes approximately 9.38 ms.

3. An interpreted template VM

Udodi uses a declarative HTML template DSL that is compiled into instructions for an internal virtual machine. Rather than generating executable JavaScript, the runtime evaluates these instructions directly, avoiding eval() and new Function(). This enables CSP-compatible template evaluation without requiring a build step.

In my benchmarks, compiling 10,000 expressions takes a mean of 4.12 ms on a cold path, while cached instruction compilation takes approximately 127 µs. The instruction cache allows the runtime to reuse compiled instructions rather than repeatedly compiling the same expressions.

Questions for the community

I'd particularly appreciate feedback from developers who have built or worked on UI frameworks and runtimes.

1. Interpreted VM vs. ahead-of-time compilation: Where are the practical scaling limits of an instruction-based template engine compared with generated imperative code? At what point does interpretation become a significant bottleneck?

2. Native CSS scoping: What performance or maintainability challenges might arise from relying on native @scope in applications with thousands of components and deeply nested scopes?

3. Reactive dependency tracking: How would you approach complex, interconnected reactive dependencies while retaining shallow reactivity and avoiding the overhead of deep proxies?

I'm particularly interested in architectural trade-offs, potential bottlenecks, and limitations I may have overlooked. Feedback on the implementation and benchmark methodology is also welcome.

Source code: https://github.com/udodi-js/udodi

Documentation and performance page: https://udodi.dev

I'll be following the discussion and responding to technical questions in the comments.

Я ооооочень давно занимаюсь низкоуровневвм програмирования пишу ОС , создовал более удобное продолжение C , язык для драйверов и прошивки , но сейчас я хочу обратиться к вам , потому что один я не справлюсь , если вы умеете писать низкорувневые программы или просто интересуетесь низкоуровневым програмированиеи или хорошо знаете как работают низкоуровневые программы то предлагаю поучаствовать в создании языка програмирования созданного для одной операционной системы , не создавать что то не обычное , а создать что то новое , свежее , но при этом максимально хорошо работающие , спасибо что прочитали , за нами будущее.

The virtual machine parser (generator).

• Built for front-ending compilers
• Can make one-shot parsers for almost any language
• Fast
• Easy to use and implement
• SDK for building into your project
• Command-line tools for your pipelines
• GUI app for convenience

Learn about it: https://algodal.github.io/Algodal_Parser_Machine_Manual/

See demonstration: https://youtu.be/5cKdGPXzBu4?t=6060

Get it: https://algodal.itch.io/algodal-parser-machine

Initial Discussion on r/Compilers:

https://www.reddit.com/r/Compilers/comments/1upju22/building_a_parser_generator/

Check it out!

I've been spending the last few days implementing async support in NXD, a systems programming language I'm developing; that also has 3 transpilation targets.

Recent work completed:

• `Task[T]` semantic type

• `AWAIT Task[T] -> T`

• `ProcessHandle[T]`

• `AwaitGroup[T]`

• Completion-order result semantics

• Semantic validation and diagnostics for async operations

I'm currently working through the remaining messaging primitives (SEND is next).

One thing I've found interesting while implementing this is that many languages expose similar async syntax, but the underlying semantics differ significantly. After spending time studying other implementations, I found myself focusing less on the keyword await and more on the type relationships and execution model behind it.

For example, in my current design:

`Task[T]`

`AWAIT -> T`

`ProcessHandle[T]`

Represents a spawned process producing T

`AwaitGroup[T]`

Allows waiting on multiple processes

Results are returned in completion order

The completion-order behavior felt natural from an async perspective, but it also raised questions about predictability versus throughput, ordering guarantees, and how much of the runtime model should be exposed to the programmer.

For those who have designed or implemented async systems, compilers, runtimes, or schedulers:

Looking back, what async design decision caused the most trouble later?

Was it task representation, cancellation, ordering guarantees, await semantics, scheduler behavior, channels/messages, error propagation, or something else entirely?

QuarkLang is a small statically typed language with two execution engines: a tree-walking interpreter (quark) and an LLVM compiler (qkc).

program main;
fn fib(int n) int { if (n <= 1) { return n; } return fib(n - 1) + fib(n - 2); }
fn main(IOStream io) { io.println(fib(35)); }

#include <stdio.h>
int fib(int n) { return n <= 1 ? n : fib(n - 1) + fib(n - 2); }
int main() { printf("%d\n", fib(35)); }

$ qkc -c -o fib fib.qk && ./fib        $ clang -O3 fib.c -o fibc && ./fibc
9227465                                9227465

Same machine, clang/LLVM 22 behind both. Level, not faster — and most of the credit belongs to LLVM.

• Execution: the same source file supports both interpretation and compilation.
• Consistency: CI strictly enforces interpreter/compiler consistency. For the same program, both must produce identical stdout, stderr, and exit code; otherwise the build fails.
• Unsupported constructs: constructs the compiler cannot lower yet are hard errors, not silent differences.
• Memory: block-allocated. delete returns a block with its data intact; clear wipes it.
• Runtime: compiled programs have no collector pause on the hot path.

It has a full toolchain: interpreter, LLVM compiler, linter with stable codes (QK101–QK115), doc generator, REPL, language server, formatter, test runner, project manager, debugger; ~25k lines of Go with no third-party dependencies; MIT; prebuilt binaries for Linux/macOS/Windows.

Repo: https://github.com/QuarkLangCommunity/QuarkLangQkc · Docs: https://quarklangcommunity.github.io/QuarkLangQkc/

Disclosure: I maintain QuarkLang. Both commands above are copy-pasteable; the benchmark suite with its methodology and fairness statement is in docs/benchmarks.md.

Vx is a heterogeneous systems programming language written mostly in Rust and C++. There are several key ideas that makes it worth taking a look at.

- First class support for topology and memory hierarchy

- Acts as a type safe MLIR frontend

- Pointer provenance in the type system

- Parallel compiler frontend

I released v0.0.2 last week so there is a ton of interesting compiler, standard library, benchmarking, performance work one can explore. Do checkout the repo (https://github.com/vx-lang/Vx), blog (https://vxlang.org/blog/). We started a discord channel (https://discord.com/invite/2w62dCg2Y) yesterday in case you want to ask questions.

Version 7.1.0 of the Farkle parsing library has been released. This version adds support for the more powerful IELR(1) parsing table generation algorithm; a first for .NET parsing libraries, as well as new APIs to define productions, powered by a source generator.

Farkle is an LR(1) parsing library for C# and F#. While in most LR(1) parsers, grammars are defined with a domain-specific language in an external file and generated by a tool, Farkle is a regular library and uses source code to define its grammars, in a way reminiscent of parser combinators. This brings the best of both worlds in terms of performance and developer experience.

Farkle also has a precompiler for ahead-of-time grammar precompilation, which can reduce startup times and validate grammars during the building of your project.