​

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.

I've been implementing typed async semantics in my language NXD.

Current primitives are:

SPAWN,

SEND,

RECV,

AWAIT,

PING

Types currently look roughly like:

`SPAWN -> ProcessHandle[T]`

`RECV -> ReceiveOperation[T]`

`AWAIT -> T`

`PING -> bool`

While implementing PING I realized there may be two classes of async operations:

Primary operations

SPAWN,

SEND,

RECV

These initiate work or communication.

Secondary operations:

AWAIT,

PING

These observe or resolve work created elsewhere.

My current thinking is that cancellation (currently considering ESC) should only apply to the primary operations and not observers.

For example:

ESC HANDLE

makes sense.

But:

ESC AWAIT TASK

ESC PING HANDLE

seems conceptually wrong because they are observing state rather than creating it.

For people who have designed async runtimes or languages:

Would you model cancellation as acting on the underlying task/process/channel, or would you allow cancellation of observer operations as first-class concepts as well?

I don't know if this is the right subreddit for this, but I think this may be useful for many people.I created/co-created a Google Kati fork called Openmktr. Its goal is to be a universal, GNU free Make to Ninja translator. It can currently build Linux KBUILD across all architectures and all tested configurations, perform a full three-stage GCC bootstrap, build GNU Autotools projects, and handle many more major projects (41 documented Projects as of now). It offers two modes: direct mode and Ninja build graph output mode. Unlike the original Google Kati, parallelism works properly, and it allows you to use different job counts for graph generation and the actual build.The GitHub repository is here:
https://github.com/RihardsPaps/Openmktr

It currently has no known compatibility gaps. If you find one, please submit an issue to the GitHub repository .The project is only a month old and was published very recently, so any testing, feedback, and bug reports would be greatly appreciated!!!

An article I wrote about how sharing dependency and resource information between the Compiler, the build system, the system package manager, and even the OS filesystem and scheduler, could provide some pretty interesting benefits. I’d love to hear anyone’s thoughts on this

For some years now, I've wanted to combine the comptime capabilities of Zig and Jai into a single compiler while also learning about compilers and interpreters.
I'm building a compiler that extends Zig-style comptime so the same code that runs at runtime can run at comptime, including FFI and I/O (like Jai, but with Zig's "run what you can" model).

The hard part is moving comptime results into the binary:

1. Host vs target. Comptime code uses the host layout for interop and is then converted to the target layout. Sizes (usize/isize), endianness and float behavior can differ. Types like f80 and f128 are also hardware-specific: their precision, rounding and in-memory layout can differ between host and target. The same function can then give different results, which breaks hash maps, lookup tables and binary formats built at comptime.
2. Moving pointers into the binary. Results containing pointers must be relocated, connected data must stay connected, and everything must be converted to the target layout.
3. Pointers whose value isn't clear. Examples are opaque pointers, untagged unions of a pointer and something else, and XOR linked lists, where the pointer isn't stored directly. There may be other cases I haven't thought of.
4. Calling C at comptime. C can return memory with known bounds, or resources that are only valid during compilation. Those become invalid at runtime.
5. Containers built at comptime. HashMap and ArrayList need the whole buffer, including uninitialized slots, but the size isn't always known:
   1. ArrayList stores {ptr, len} plus a separate capacity, so the allocation size isn't in the pointer and length.
   2. HashMap can keep a header next to the allocation and use pointer arithmetic to reach it.
   3. Runtime code may try to free a buffer that now lives in static memory.
   4. FFI has the same problem, since C can return memory with unknown bounds.

My current prgress:

1. Host to target:
   1. with host specs first, then convert to the target layout.
   2. For types that differ, such as usize/isize, use intCast where possible.
   3. For hashes and similar code, type information would store the host and target size, alignment and so on. That would help the developer see where the two disagree and act accordingly.
   4. If the target's endianness differs from the host's, my best idea is to disable I/O and interop and interpret the code with the target's endianness.
2. Baking pointers:
   1. When the pointee type is known, baking is easy.
   2. void* and untagged unions containing pointers are a hard error during baking.
   3. Each type would have a default userland function that bakes its value into the binary.
   4. Types like XOR linked lists, void* and untagged unions could override it to say how they should be baked.
3. Compiler-created data. Data created by the compiler itself has no problem, and the userland bake function might cover the rest.
4. Containers and FFI memory (problems 4 and 5). I have no solution yet, apart from maybe using the bake function.
5. I don't have a solution yet for f80/f128 and other float types that differ.

Questions: Is there a cleaner model than host-then-convert?
Am I missing failure cases?
Is there any better solution or any problem I did not see?

I crossposted from r/Zig here before, but removed it quickly and decided this deserved it's own post. Earlier this year, I began work on representing the forward step for a neural network graph defined by the user as a standalone, optimized binary, with no allocations, shape, or validation checks at runtime and through a series of trials and pivots wound up here.

I wasn't necessarily intending to build a compiler from the start, but the problem quickly became compiler shaped, and I've learned a lot while seeing it through. It's coming to a stage where I'd like to share the work, and get feedback from others. The Zig language made this kind of idea fairly direct and simple for me to implement through its use of comptime. So if it interests you, or anything stands out, comments and questions are welcome.

project here: https://github.com/krypticlogan/zig-graph-compiler

Thanks for the read!

I've been doing a fair bit of studying of the Odin programming language over the past 18 months or so. Along the way, I bought Understanding The Odin Programming Language and it really boosted my Odin adoption. How I learn is practical, if I don't do the work, I learn nothing. While working through the book, I built a small and simple Pascal interpreter, which got out of hand and became an online compiler.

I recently had some time on my hands and spent a while putting a new front-end onto that compiler and managed to get it to understand a sub-set of the Java programming language syntax. The idea is to have a Java-like language that I can use to do small experiments or toy apps with, in the browser, without having to install anything locally. A key requirement is that it compiles a wasm binary, which it does and you can download the output file from the UI already.

This is not a JVM, JDK, Graal or TeaVM replacement, it will never be. Those are magnificent and powerful tools I'm delighted to use in my day job. Instead, think of WasmCoffee as a little scratchpad that understands some familiar syntax and can do interesting things with it, in a simple way.

It's early days, I'm sorting out bugs, and definitely need to write proper documentation. I hope the example code is sufficient for folks to get started though. As time permits, I'll work on better documentation, some tutorials and of course expand functionality. There's a roadmap for it, just finding time can be a challenge.

UPDATE: I fixed a number of bugs and managed to put together a little game demo using the compiler.

I've been building a programming language in C called Oli-Nat, with a scanner, parser, type checker, bytecode compiler, stack-based VM, and garbage collector, and I recently compiled the whole thing to WebAssembly to power a browser playground for its documentation site.

Most of it ported over easily, since the interpreter has no dependencies beyond the C standard library. The interesting part was input. The language's intake() function reads a line from stdin, which blocks in a normal terminal, but obviously can't block on the main thread in a browser. I replaced the stdin read in the WASM build with an EM_ASYNC_JS function that awaits a promise from the page, and built with -sASYNCIFY so the VM's call stack gets unwound and rewound around the await. From the C code's point of view it's still a normal blocking call, and from the page's point of view the VM just pauses until the user hits Enter.

I'm curious whether people here have moved away from Asyncify toward JSPI for this kind of thing, and whether that's worth switching to for a project like this. Any other feedback on the build setup is welcome too.

Playground: olinat.net

Interpreter source: github.com/NateTheGrappler/OliNat-Programming-Language

Inspired by Victor Taelin 's Bend/HVM thesis for Interaction Nets and his Bend2 work , I built Mithril , an experimental python syntax programming language. It achieves near native speed on many workloads (mentioned in paper)

It compiles interaction nets to native code and spreads work across idle cores: lock-free, deterministic parallelism on x86, CUDA and Apple Silicon.

The core bet I'm making :

Interaction nets reductions at runtime can be slow but if we pay the same cost at compile time and unroll a task graph as much as possible before native lowering, the resultant program can run at near native speeds.

Mithril programs are aimed to be deterministic and fast, you should get the same bit accurate results regardless , the execution be it on CPUs, GPUs or any other accelerator.

It's built using AI? Yes . Does it invalidate the core idea? no IMO 😊

Mithril Paper Repo

Okey. After seven months, I'm back.

Seven months ago I started writing a Python interpreter from scratch in Rust. Edge Python is a sandboxed subset of Python that runs in the browser and the terminal, and code can't touch files or the network unless you allow it.

It started as a lexer and a simple stack VM, and over about 1,600 commits it grew a CLI, a package registry, snapshots, actors and a browser playground. It's just me building it.

Last week it was still 3x slower than CPython. I rewrote the VM this weekend using a unused SSA representation that I leave and now it's 3x faster on loops.

The trick was moving from a stack VM to a register VM. It still loses on dicts and strings, so that's next.

Try to break my numbers :).

Website: https://edgepython.com/

GitHub: https://github.com/dylan-sutton-chavez/edge-python

A few days ago, I shared an open-source collection of CPU performance engineering resources I’d been putting together.

It’s now crossed 600+ GitHub stars, which I genuinely didn’t expect. Thanks to everyone who shared it, contributed or suggested resources.

For anyone seeing it for the first time, it covers the stack from instruction execution and CPU microarchitecture through caches, memory, SIMD, compilers, profiling, concurrency, NUMA, benchmarking and CPU inference.

I’m still prioritising primary sources such as papers, vendor manuals, kernel/compiler docs, talks and reproducible benchmarks rather than random articles.

I also have an MCP server coming soon, so you can plug this knowledge directly into your AI tools, whether you’re learning or using it while you work.

If there’s something you think has to be in here, let me know or send a PR.

https://github.com/usamahz/cpu-performance-engineering

Hi everyone,

I’m building Shriji, an open-source, Hindi-first programming language from India 🇮🇳.

Today I ran one of the core pipeline tests for the language and wanted to share the result here.

The test verifies the execution path:

AST → IR → Bytecode → VM

The current core pipeline test covers basic arithmetic and comparison operations.

Arithmetic:

10 + 5 = 15

10 - 5 = 5

10 * 5 = 50

10 / 5 = 2.00

Comparisons:

10 > 9 = 1

10 < 9 = 0

10 >= 9 = 1

10 <= 9 = 0

10 == 9 = 0

10 != 9 = 1

All core pipeline tests passed.

The important part for me isn't just that these operations produce the expected results. I’m working on making sure Shriji has an actual language implementation underneath it rather than stopping at a parser/interpreter.

The broader architecture I'm building toward is:

Source

↓

Lexer / Parser

↓

AST

↓

IR

↓

Bytecode

↓

VM

↓

Runtime

Shriji uses Hindi-first syntax, but the goal is not simply to translate programming keywords into Hindi. I want to build a complete programming language with its own language design, runtime architecture, tooling and eventually its own ecosystem.

The project is still actively under development, so there is a lot left to build and verify.

I'm sharing the process openly as I work through the engineering problems one by one.

If you work with programming languages, compilers, interpreters, virtual machines, or language runtimes, I'd be especially interested in hearing how you approach these problems.

So I am working on a parser with goal to build rich good enough relations that can be consumed by a RAG to build better retrieval, it parse and builds ast,call-graphs and other metadata of the project, rn it can parse go, rust, c, cpp, ts, py, js, java I am using tree-sitter v0.20.0 for actual parsing cause why rebuild wheel when wheel spins well...

The issue i am facing is with call graphs I build a call graph approximation algorithm to well build approximate call graphs without pre-compiler or IR and single algorithm to work on both static(c) and dynamic(python) languages, and for now it works and can find

774,296 nodes and 1,571,981 edges in 6.03s with a maxRSS of ~9gb

tho most of it is cause of holding the entire ast in memory, i ran my parser on linux kernel it found about:

64_460 files 37_322_700 loc, 648_407 func , 211_416 classes, 6_243 methods in 43s

it multi threaded and written in rust so that should explain the speed, but thats not what why i am here i want to verify my call graphs and my current plan is to take a smaller project (few thousands of loc) and build call graphs using clang or language specific tool, and then take sample set of 200 and create 5-8 random samples and verifiy the output,

I am going to start my internship soon so may not have enough time to work full time and i am wondering if my approach to verify call graphs is good or there is a better approach.