This is a submission for the MLH x DEV Writing Challenge
What I Built
I built RUDRA — a fast, safe, and easy systems programming language with its own native backend. It compiles .rux source files directly to x86-64 machine code and writes a native ELF executable itself. No C compiler. No assembler. No linker. No LLVM.
Most new languages bootstrap on top of someone else's toolchain. RUDRA doesn't. You download one archive and you have a complete toolchain:
| Tool | Job |
|---|---|
rudra |
Project driver: new, run, build, fmt, test
|
rudrac |
The compiler: one .rux file → native binary |
ruxpkg |
Package manager |
rudra-lsp |
Language server (VS Code extension: rakshanex.rudra) |
Why build a language at all? Every systems programmer knows the ritual: write C, fight the build system, install GCC, then Clang, then argue with the linker. Half of "programming" becomes toolchain plumbing. RUDRA is my bet that low-level control, memory safety, and simplicity don't have to be a pick-two triangle:
- Safety: statically typed, no null, bounds-checked access, immutability by default
-
Power: generics, traits, closures, sum types with exhaustive pattern matching,
Option/Resulterror handling with the?operator — and a growing standard library (files, networking, threads, JSON, HTTP) - Simplicity: a small, readable syntax inspired by Rust and Go
It looks like this:
fn greet(name: str) -> str {
return "Hello, " + name + "!";
}
fn main() {
let name = "world";
print(greet(name));
print("2 + 2 = {2 + 2}");
}
rudrac greet.rux --run
# ✅ Compiled: build/greet
# Hello, world!
# 2 + 2 = 4
What I learned: Building the backend taught me more than a decade of using other people's languages. Three honest lessons from RUDRA v1.1.0:
- Your own backend changes every trade-off. When you emit machine code yourself, a hello-world binary is a few kilobytes and starts in ~1 ms — but every platform quirk is now your bug.
-
Honest limitations build trust. RUDRA closures capture nothing (a closure sees only its parameters — verified live, it errors with
unknown variable). String-returning closures print garbage. I document these quirks publicly in my chapter-by-chapter course instead of hiding them, and developers respect that more than a polished lie. - Teaching is the best debugger. I'm publishing a 25-chapter YouTube course from the official book (The RUDRA Programming Language, v1.1.0). Every chapter's terminal segments are 100% real compiler captures — writing the course keeps finding real compiler behaviour the book got wrong.
Demo
🎥 Chapter 1 — Introduction, Installation & Your First Program:
https://www.youtube.com/watch?v=-adNF7Fi0Pg
The full series ("Learn RUDRA — Chapter by Chapter") is live up to Chapter 13 (Closures), with new chapters premiering daily at 10:00 AM IST.
📥 Download RUDRA v1.1.0 (free): https://github.com/rakshanex/rudra/releases/tag/v1.1.0
💻 GitHub: https://github.com/rakshanex/rudra
📖 Book: The RUDRA Programming Language by Piyush Kumar (RAKSHANEX TECHNOLOGIES)
Try it in under a minute:
# download + extract the release, then:
rudra new hello && cd hello
rudra run
Partner Technologies
Honest answer: RUDRA deliberately uses no partner/cloud technology in its core — the entire point of the project is a zero-dependency toolchain. No LLVM, no GCC, no hosted build service. The compiler, package manager, and language server are all self-built.
Where the ecosystem around the project lives:
- GitHub — source, releases (v1.1.0 toolchain binaries), and issue tracking: github.com/rakshanex/rudra
-
VS Code Marketplace — the
rakshanex.rudraextension powered byrudra-lsp - YouTube — the chapter-by-chapter course that serves as the project's living documentation
If a future iteration adds a hosted playground, that's where partner technology would genuinely belong — I won't pretend it exists before it does.
Hackathon Experience
Full honesty, because that's the theme of this whole project: RUDRA is a solo build. No team, no stage, no demo-day pitch — just one developer, a blank file, and the stubborn question: "What if a systems language needed nobody's toolchain but its own?"
It was built the way the best hackathon projects are built, though: in intense sprints, one impossible problem at a time. One sprint for the lexer. One for the type checker. One very long night for the native backend, when the first .rux file finally compiled into a real executable that actually ran. That moment — a program written in a language that didn't exist a few weeks earlier, running natively — is the moment every builder chases, in hackathons and outside them.
What I'll remember most: you don't need permission, a team, or a framework to build the thing. You need a problem you can't stop thinking about — and the honesty to document what breaks along the way.
Piyush Kumar — Founder & Director, RAKSHANEX TECHNOLOGIES. Cybersecurity specialist (CompTIA PenTest+, TryHackMe SAL1, Global Top 145), author of "The RUDRA Programming Language" and four cybersecurity books, builder of RUDRA, OmniCore OS, and AgentTrace.
If you're into compilers, language design, or systems programming — what's the first program you'd write in a new systems language? Tell me in the comments. 🔱
Top comments (0)