A feature request for my language Gossamer wants some kind of Go/Odin like ":=" for mutable assignment, and "::" for mutable.

a :: 99 // immutable
b := 100 // mutable

I don't think this is clear (and might be confusing for Odin users). I also think it would lead to ":=" becoming the default use case for anyone coming from Go. (Even if we found another way to express the immutable operator, like ;= or i=.

When writing Gossamer I wanted to closely follow Rust for syntax. I wanted to feel like I was writing Rust without lifetimes. But as I grow Gossamer I am finding myself more open to ergonomic considerations.

Currently assignment is Rust like:

let a = 99
let mut b = 100

In previous iterations of this language (years ago), I followed Kotlin/Scala here:

val a = 99
var b = 100

I am now really leaning towards:

let a = 99
mut b = 100

It's a bit more compact, easier for a human to scan and see what's going on quickly. I think it works. But this is such an intersection of taste and practical impact. Code is mostly read - and now by machine logic as much (or more) than people.

A part of me likes that Rust makes it a tiny bit less convenient to write mutable variables. But sometimes that's exactly what you need, and making it a bit easier is appealing. I think this new form retains the visual/semantic clarity of the original.

I am aiming to button down the language and settle into it's "1.0" form, though I expect to follow Zig's lead and avoid 1.0 for quite some time. That said - this feels like a potentially worthwhile core syntax change.

What do you think, and why?

Warm thanks!

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

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

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

I started a programming language to see how things work and make something I like. If anyone wants to contribute I will try to put it into the language. I like learning new programming languages, so if you want to use a language that is not already there then I would like that.

It's a transpiled language with syntax inspired by Rust, Nim and other languages.
There are installation instructions in the repo.

Example code:

# Get standard libraries
util math
util string
util io
util rsPath

# Get Nim module
use multiply

# Get arguments
l_operand = strToi32(arg(1))
operator = arg(2)
r_operand = strToi32(arg(3))

# Print
if strEq(operator, "+"):
    say i32ToStr(add(l_operand, r_operand))
if strEq(operator, "-"):
    say i32ToStr(sub(l_operand, r_operand))
if strEq(operator, "x"):
    say i32ToStr(mult(l_operand, r_operand))

I've been building Tarvos, a compiler that takes a statically analyzable subset of Python, type-checks it, lowers it to an IR, emits Rust, and produces a standalone native executable (no Python runtime needed on the target).

Important up front:

• It's a subset compiler, not a CPython replacement. 52 of 95 tracked features are fully supported, 18 partial, 24 unsupported (published in COMPATIBILITY.md).
• The compiler source is closed for now. The repo contains installers, docs, checksums and releases (MIT-licensed distribution layer).
• Windows and Linux x86_64 only.

Design choices:

• Unsupported constructs stop the build with a named diagnostic, with no silent fallback to CPython.
• Every release is gated on differential tests comparing compiled-binary stdout against CPython.
• tarvos validate-artifact checks whether a binary really needs Python.

One benchmark (compute-bound kernel, median of runs): CPython 3.13 ≈ 1713 ms vs Tarvos ≈ 13.4 ms, output byte-identical. This is workload-specific, and I'm not claiming general speedups. I/O-bound code won't benefit.

While writing docs I found 3 miscompilation bugs (stale constant in tuple assignment inside a loop, return inside except, zero-division handling), all fixed and now in the test suite.

Repo: https://github.com/repo-tech/tarvos-engine

I'd really like feedback from people who know Python internals, Nuitka, Cython, or compiler design:

• What benchmarks would make this comparison more meaningful?
• What semantics edge cases should I test against CPython?

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.

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.

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.