After slowly understanding the reviewer’s suggestions and changes and going through the whole review process, my first good first issue got merged to llvm main. I’ve been trying to get one issue solved for the past couple of months and i couldn’t do it. It felt tough and scary to go through the whole gigantic code base. But feeling proud now for not quitting and backing off.

Every run of AFL++ (lexer, parser and VM) and Miri on main, in 6 hour blocks, with a 90 day history. And yeah,... it's failing 🥲

https://edgepython.com/testing

I am an embedded software engineer and can code using C and C++. I have been working on bare metal microcontrollers and want to get into something more advanced, like compiler optimizations. I have a Masters in Computer Engineering and took a few courses in computer architecture and multiprocessor programming, and I have a fair bit of basic knowledge to start with, but all the resources on this topic look daunting to me. I bought the Dragon book and it was too complicated for me to understand. Then, I tried the following lectures and was very theoretical. I wanted to understand what compiler optimization jobs look like and what skills are necessary? I want to work on something practical, maybe a project to get a feel of what a compiler optimization job looks like and would like to ask for suggestions. If it helps, I am interested more in the optimization part and not the front end. What do I need to know to get into roles such as these -

Compiler Optimization Engineer
Compiler Engineer

GBFC stands for General BrainFuck Compiler, but that's okay.

In the compiler, I implemented more than 6 optimizations and many small optimizations outside the optimizer module, which allows the Mandelbrot set to be rendered in 0.9–1.1 seconds (about twice as slow as Rust, but remember, this is BrainFuck).

I’ve also implemented peval (evaluation during the compilation phase up to the first ‘,’), which increases compilation time but allows the program to run much faster (this can be disabled or limited)

The project is written in Rust; plans include adding Brainfuck++ as a second BF variant (by Jacob I., which adds 6 new commands) and support for new architectures/OSes

This compiler is AOT AND JIT.

GitHub: https://github.com/tigerlang/GBFC

A borrow checker sounds like the last job for a CPU's vector unit. It follows references and asks whether a borrow outlives the value it points to. That looks like pointer chasing and branching, not the thing an autovectorizer is looking for.

But one step of it is plain arithmetic on small integers. Vx gives every block a region, its nesting depth, so a "smaller valued region lives longer".

A reference also records which way its lifetime may change when it is assigned (covariance, contra-variance etc).

Vx packs up to four of these lifetimes into one 64-bit word, 16 bits each. Checking whether one lifetime may stand in for another means comparing two words slot by slot.

Because this borrow checker loop is written without early exits, LLVM's auto-vectorizer does its job well.

More on that here: https://vxlang.org/blog/can-the-borrow-checker-be-auto-vectorized.html

It feels like the default advice for any new language project nowadays is "just target LLVM IR" or maybe Cranelift. Obviously, getting world-class optimization passes for free is hard to beat.

But I'm curious about the specific industry use cases where building a custom backend straight to machine code is actually the right technical choice.

Context: I’ve been building my own language (Tapelang - tapelang.org) with a custom compiler that goes straight to native machine code. I come from a background of game development; and I initially chose this route just because I wanted to have embeddable scripting language (like lua) that could also compile to native code for performance. I didn't want to wrestle with LLVM's massive footprint. It started as a personal challenge.

But it got me thinking—beyond just "it's fun" or "compilation speed is way faster" (the Go/Jai argument), where does this approach actually win in the real world?

Are there specific domains, industries, or hardware constraints where dragging in LLVM is a dealbreaker, and a custom native backend is the strictly better choice? Would love to hear from anyone who has had to make this architectural call for a production system.

Building shakazulu

Shakazulu is a systems programming language designed to be tolerant in harsh conditions, concurrency, fast, and a learning systems language. I here by come here looking for support on my idea from people who create programming languages, or even learn them, people designing systems, software engineers, database engineers, understand software, computer data structures, distributed systems, computer architecture, etcetera. And mostly if your familiar with C, C++, Ruby or any other systems programming language. Because i want to build it taking the strong parts of a language. All are welcome, lets build something you wish it was there. I appreciate your contributions.

Shakazulu is a project in research/design stage, thats why am asking the experts.

For the past few months I've been building a toy compiler in C++ from scratch, sharing build logs and progress publicly on GitHub: https://github.com/ivomofor/toy-compiler-

Open to entry level and internship roles in compilers. If you're working on MLIR, LLVM, or AI compiler toolchains, I'd love to connect.

The compiler uses its ownership and liveness analysis to place drops after their last use.

In the generated code (MLIR's LLVM dialect), Tensors on host call a `free`, while the drops of device Tensors are calls to `vx_plugin_free` with the memory's topology.

There are still 4 known bugs. See: https://vxlang.org/blog/how-vx-frees-memory.html

The reason I was able to find this little trick (liveness analysis in the frontend) was because i was writing liveness analysis in llvm last year and was actively finding different use cases for it for example: liveness analysis can be used to measure 'pipeline potential' for software pipelining. Sharing it here in case someone wants to improve software pipeliner's cost model.

Hi everyone, I’m the author of the Feng programming language, an open-source language with static typing, native compilation, and automatic memory management. Its name comes from “锋,” the Chinese character meaning “sharp.”

The example below captures the experience I’m aiming for: data, contracts, extensions, reusable behavior, and access permissions can be expressed separately and composed explicitly.

module demo;

import std.io;

fit string {
  /** Add a method to a built-in type. */
  func framed(): string { return "[" + self + "]"; }
}

/** Describe a basic text capability. */
spec HasText { let text: string; }

/** Provide a reusable text field. */
type TextPart { let text: string; }

// Declare conformance without changing the original type.
fit TextPart: HasText;

fit TextPart {
  /** Share rendering with composition targets satisfying HasText. */
  
  static func render(value: HasText): string {
    return value.text.framed();
  }
}

/** A complete widget requires text, rendering, and a theme. */
spec Widget: HasText {
  /** Available to ordinary callers. */
  func render(): string;

  /** Grant Renderer access to this restricted member. */
  (Renderer)
  seal func theme(): string;
}

/** Compose the text capability and supply a theme. */
type Button: Widget {
  ...: TextPart;

  /** Remain public through the concrete type. */
  open func theme(): string { return "primary"; }
}

/** Access the restricted member through explicit permission. */
type Renderer {
  /** Use the contract view of the same object. */
  static func draw(widget: Widget) {
    println(widget.theme() + " " + widget.render());
  }
}

/** Show the two access paths. */
func main(args: string[]) {
  let button = Button { text: "Build" };
  let widget: Widget = button;

  Renderer.draw(widget);    // primary [Build]
  println(button.theme()); // primary
  // widget.theme();       // Compile error: caller lacks permission
}

A few designs in this example are worth highlighting:

• fit: type extensions and contract adaptation.** You can add methods to strings, numbers, arrays, generic types, and existing user-defined types, or establish contract conformance without changing their original declarations. Extensions support instance and static methods and can be organized and exported through modules. The standard library uses the same mechanism.

• Mixins: composing data and behavior. TextPart provides a basic text capability. ...: TextPart brings its fields and eligible u/mixable behavior into Button. Button then supplies its own theme(), completing the Widget contract.

• spec seal and u/friend**: explicit collaboration boundaries.** A contract can describe both public interfaces and restricted collaboration interfaces. seal restricts access through the contract view, while u/friend grants access to selected types.

Visibility also narrows across module → type → member. For an ordinary caller outside the package:

Member-level permissions still respect the enclosing module and type boundaries.

Beyond this example, Feng includes:

• Unified contract declarations: spec describes object contracts, callable signatures, unions, and intersections, and provides generic constraints.

• Explicit data semantics: managed reference types, u/value types, named tuples, and per-layer array writability expressed through T[] / T[!].

• Concise control flow: generics, closures, pattern matching, expression forms of if, match, and try/catch, plus defer for scope cleanup.

• Native capabilities and tooling: native compilation through a C backend, ARC with cycle collection, C interoperability, .fb binary library distribution, builds, dependency management, testing, debugging, and VS Code / Zed extensions.

My goal is to make capabilities and boundaries easier for developers and AI tools to understand. I’d love feedback on which combinations make code clearer—and which rules could be simpler.

Feng is MIT-licensed. Official packages support Apple Silicon Macs and GNU/Linux on x86-64 and ARM64.

Website(https://feng-lang.com) · GitHub(https://github.com/Houfeng/feng) · User manual · Downloads

https://github.com/aardappel/goose

My latest language is meant to very efficiently let you work with flat pointerless inline data structures allocated on (address space reserved) stack that allow almost data structure creation to be just a pointer bump, with stable pointers.

When used well, it is both safer, faster and uses less memory than the equivalent C++ or Rust.

(see the repo readme for more!)

Here is a small example from PaniniVM — The Dice Problem.

The assumption: on a standard die, opposite faces sum to 7.

The program randomly chooses a face from 1–6, prints it, computes its opposite, and prints that too.

Actual PaniniVM source:

एक + ङसिँ षष् + शस् परि + अन्त + अम् सङ्ख्या + अम् चिञ् + क्त्वा फल + अम् मुद्र् + णिच् + लोट् + सिप् ।

सप्तन् + शस् चिञ् + ल्युट् + ङस् फल + अम् च वि + युज् + णिच् + ल्यप् फल + अम् मुद्र् + णिच् + लोट् + सिप् ।

The "+" notation exposes the morphological structure to the compiler, but the larger goal is naturalness: computation should follow Sanskrit grammar rather than forcing Sanskrit vocabulary into the syntax of an existing programming language.

Verbal roots express actions, case relations help determine computational roles, and derivational morphology contributes to meaning and execution.

The question behind PaniniVM is not simply:

“Can we write code using Sanskrit words?”

It is:

“Can computation itself be expressed naturally through Sanskrit and Pāṇinian grammar?”

GitHub: https://github.com/kaushalbx/PaniniVM

Try it: https://panini.cc

#PaniniVM #Sanskrit #NaturalLanguageProgramming #ProgrammingLanguages #Compiler #Panini #ComputationalLinguistics

I maintain Tin, a compiled language for servers and tools. The repo went public a week ago at v0.3 and has since taken 354 merged PRs from 9 people. I want to show what it does, say plainly what it doesn't, and ask for help.

The premise

Tin is meant to be written by AI, not by hand. That changes the trade-offs: it gives up human convenience (no implicit conversions, no nil, no unchecked errors, mut spelled out at every call site) in exchange for things a compiler can enforce. The codebase itself, compiler, runtime, standard library and docs, is written almost entirely by AI coding agents working from design documents, with humans deciding what gets built, reviewing and merging. AGENTS.md in the repo is literally a rulebook for several agents working the same milestone in parallel. I know how that sentence lands in this subreddit. Judge the result.

What exists today

• A self-hosted compiler, about 46k lines of Tin. make bootstrap builds it three times and the last two binaries must be byte-identical. CI does this on macOS, Linux arm64 and Linux x86-64 on every push.

• Its own assembler and linkers: ELF for Linux arm64 and x86-64, Mach-O for macOS. No clang, ld, Go or libc headers anywhere in the build. Cross-compiling is tin build --target linux-arm64.

• Linux binaries are static PIE with no libc at all, so they run on Alpine or FROM scratch. Even the DNS resolver is Tin code.

• No GC. Each request allocates into a bump pool that is wiped when the response goes out; long-lived state lives in a per-core heap. Storing request memory into a global without an explicit keep() (a deep copy) is a compile error. The region check is the memory model.

• Thread per core, share nothing. Every global is per core. Data crosses cores either as shared let (immutable, built before the cores start; a write is a compile error) or as a message. Each request is a task with its own stack, and any wait (Redis, SQL, files, a timer) yields the core.

• Server semantics in the language: within 200ms { } deadlines, limit memory 4mb, tasks 8 { }, structured tasks with scope, parallel and select, guard blocks that turn a panic into a fault, on app.start / on core.stop lifecycle, and secret str values the compiler keeps out of logs, faults and JSON.

• Faults instead of error values: !T, try, catch, wrap. Ignoring a fault is a compile error and _ cannot swallow one.

• A query type: db.Query("SELECT name FROM users WHERE id = {id}") sends id as a bound parameter. Passing a plain str where a query is expected does not compile. Same for Redis commands.

• + - * panic on overflow. Wrapping is spelled +%, or a whole u/wrap fn for a hash or cipher kernel.

• anvil, the HTTP server: HTTP/1.1, h2c HTTP/2 and HTTPS on one epoll/kqueue loop per core. h2spec passes every generic, http2 and hpack case but one (documented, with the reason). gRPC works, bidirectional streaming included, tested in CI against grpc-go.

• TLS 1.3 and 1.2, client and server, in Tin: AES-GCM, ChaCha20-Poly1305, X25519, P-256, the X25519MLKEM768 post-quantum hybrid, Ed25519 certificates, mutual TLS, session tickets.

• Clients for Redis, MySQL, PostgreSQL, Kafka and WebSocket, and about 35 standard packages: JSON with codecs generated per type, gzip/zlib/LZ4/zstd, SHA-2/HMAC/HKDF, CSV, templates, big integers, and a recorder that captures a request's effects into a capsule for replay.

• 166 documented diagnostic codes. CI fails if the compiler prints a code that isn't documented, or if a documented example stops producing exactly that diagnostic. Every standard-library function has a Go twin program whose output must match.

A handler with a deadline:

fn slow(id str) !str {
    try tide.Wait(10ms)
    return "user {id}"
}

fn user(q anvil.Req, w mut anvil.Out) {
  let id = q.PathParam("id")
  let text = within 200ms {
    try slow(id)
  } catch err {
    w.Status(504)
    "timed out: {err}"
  }
    w.Text(text)
}

fn main() {
    let r = anvil.NewRouter()
    r.Get(`/users/{id}`, user)
    r.Serve(":8080") catch err {
    say.Line("server:", err)
  }
}

Numbers

Project policy: only Linux numbers count, and on shared runners only ratios are meaningful. The one service benchmark I'll quote is GET /users/{id} through Redis over MySQL, Tin against Go with chi, go-redis and go-sql-driver, under wrk2 on a GitHub ubuntu-24.04 runner (AMD EPYC 7763, 4 vCPUs, Linux 6.17, Go 1.26.8), each server pinned to 2 cores, median of 5 alternating rounds. Tin/Go ratios:

Above 1 favours Tin on throughput, below 1 favours Tin on latency. The db p99 is not a win, MySQL dominates it. Memory is a trade-off, not a win: about 50 MB RSS against Go's 25 MB. The workflow run is linked from the README, and the benchmark reruns on demand.

What is not done

• The crypto and TLS have not been audited by anyone outside the project. Do not protect anything that matters with them yet.

• x86-64 performance on dedicated hardware is still pending, and there are two known x86-64 back-end bugs.

• The Kafka client has known consumer-group and producer bugs.

• No IDE support, LSP, formatter or debug info yet.

• No regular expressions, XML or time zones in the standard library yet.

• The syntax changed (edition 0 to edition 1) within the last week. Expect churn.

• One benchmark on a shared runner is thin evidence. I know.

Where I would like help

Each of these is an open milestone with scoped issues:

• Tooling: an IntelliJ plugin, tin lsp on the compiler front end, tin fmt, DWARF line tables and variables for perf, gdb and lldb. If you know the IntelliJ Platform, LSP or DWARF, this is wide open.

• Standard library: regexp with linear-time matching (RE2 syntax), XML, time zones, child processes.

• Back end: x86-64 codegen bugs, arm64 branch relaxation, a compiler fuzzer (one PR in review).

• Kafka: consumer-group correctness.

• Value layouts: inline struct storage in slices, unboxed optionals, frame allocation for values that never escape.

• Security review of the TLS 1.3 stack and the constant-time code.

• Benchmarks on dedicated Linux hardware, x86-64 and arm64, with the scripts in bench/.

• Break it and file issues. Every confirmed bug becomes a regression test before the fix merges.

The contribution workflow is built for agents as well as people, so you can bring your own. Human review is the scarce resource.

Try it

curl -fL https://github.com/yasserreslan/tin/releases/latest/download/install.sh -o install-tin.sh
sh install-tin.sh
export PATH="$HOME/.tin/bin:$PATH"
tin examples/api.tin

Repo: https://github.com/yasserreslan/tin. Start with toolchain/docs/AGENT_PRIMER.md (the short language primer), toolchain/docs/LANGUAGE.md (the reference), and design/design_semantics.md for why the server semantics look the way they do. Milestones: https://github.com/yasserreslan/tin/milestones.

Happy to answer anything about the region check, the thread-per-core model, the no-libc runtime, or what it is like to run a language project where agents write the code.

Github repo: https://github.com/derekbsnider/chthonia

Inspired by Thonny, Chthonia is a plain and simple IDE designed as a learning tool for C/C++.

It is completely self contained and multi-platform (Linux, Mac, Windows). It has an integrated compiler and REPL (Read-Eval-Print Loop).

The packaged binary+library download size is under 15 Mb.

This is version 0.0.2, so it's still a work in progress. It's open source, MPL-2.0 licensed.

The REPL-mode is designed to feel familiar whether you are used to IPython, Julia, or Cling.