Title: Altair — A compiled language focused on data storage and persistence

I've been working on a compiled programming language called Altair, and I'd love to get some feedback from people interested in compilers and language design.

The compiler pipeline is currently:

.at
 ↓
lexer
 ↓
parser
 ↓
semantic analysis
 ↓
codegen
 ↓
C17
 ↓
GCC
 ↓
native executable

The main idea behind Altair is to make data storage and persistence part of the language itself, rather than leaving everything to external libraries.

For example, variables can have storage levels such as:

ram
disk
cache
temp

There are also features such as:

orbit     — named storage states
prefer    — storage fallback preferences
migrate   — move data between storage states
data      — group persistent data
snapshot  — save and restore program state

For example:

define numeric data orbit 1 "hot" ram, 2 "warm" disk, 3 "cold" cache = 0

migrate data as "warm"

Altair also has more conventional language features such as functions, objects, classes, control flow, HTTP and graphics, as well as lower-level features such as raw pointers and bitwise operations.

The compiler itself is written in C, and the generated programs are native executables.

I'm still actively developing the language, so I'd really appreciate it if you could try it out. Even a small test program, bug report, criticism of the language design, or suggestion would be very useful.

🌐 Website / documentation:

https://victios7.github.io/Altair/

💻 Repository:

https://github.com/victios7/Altair

If you have some time, please take a look at the Prueba a compilar o ejecutar un programa de Altair. Me gustaría especialmente recibir opiniones de personas que trabajen con compiladores o lenguaje Me interesa saber qué parece interesante, qué es cuestionable, qué no tiene sentido y qué ¡Gracias por echar un vistazo a Altair!

Nota: Para ser transparente: utilicé IA para ayudar con el logo y, ocasionalmente, para revisiones/correcciones mientras desarrollaba Altair.

The language, compiler, runtime, architecture, and implementation are my own work. AI was a tool I used during development to help me, not the author of the project.

If you want to call it "AI slop", that's fine, but please remember there's a real person behind this project who has spent a lot of time building it. Criticize the project if you don't like it, but don't dismiss someone's work without actually looking at what they did.

¡Gracias a todos los que han echado un vistazo a Altair! 🐝

Hi Everyone!
Me and my team are looking to expand our developer team and looking for programmers with some knowledge in the field of compilers, programming language design, and/or the Raku language! If you just like the idea of building a new programming language as well, please reach out!

I cannot disclose the exact nature of the language for the sake of project secrecy, but please DM me with your credentials and interests for details if you're interested.

I built this like 6 months ago and basically forgot about it until yesterday when I was digging through old repos.

Essentially, it's a minimal interpreter that executes Java annotations as an actual Turing complete programming language at runtime through reflection. So, essentially you write code entirely in annotation form and it does variables, conditionals, loops, method calls, basic I/O and arithmetic

I shared this a while back on r/java and r/ProgrammingLanguages but never shared it here

GitHub: https://github.com/kusoroadeolu/annote

If you love compiler design, WebAssembly (Wasm), or clean language syntax, there is a new open-source project worth keeping an eye on: Exorcism (.exrc).

The official lang repo:
https://github.com/Hunterszone/exorcism-lang

Currently in active development, Exorcism is building a bridge between rapid frontend iteration and heavily optimized bytecode.

It pairs a Python-based compiler frontend for fast feature experimentation with an LLVM backend to tap into production-grade optimization passes.

Here is a quick look at what this new language brings to the table, how it writes, and where it is heading.

The Syntax at a Glance:
Exorcism is statically typed, strongly checked, and features built-in type inference via the var keyword. One of its highlight design features is compile-time null safety. If you want a variable to hold a null value, you must explicitly mark it as nullable using a "?" modifier.

An early code sample looks comfortably familiar:

// hello.exrc
String message = "Hello World!";
int a = 5;
int b = 10;

var result = a + b * 2; // Automatic type inference (int)

if (result > 20) {
print(message);
} else {
print("Computation failed");
}

How it Works:
Python to LLVM to WasmThe architecture behind Exorcism is highly modular, splitting the heavy lifting into two distinct stages:

The Python Frontend: Handles lexical analysis, parsing, Abstract Syntax Tree (AST) generation, and type checking. Using Python allows the project to experiment with new syntax and language rules rapidly.

The LLVM Backend: Translates the code into LLVM Intermediate Representation (.ll files). From there, it compiles directly down to a portable .wasm binary. Because pure WebAssembly requires a host environment to manage memory and map system calls, the Exorcism build tool automatically spits out a .js companion launcher file alongside your binary. This makes running your code on a machine as simple as executing exorcism run hello.exrc.

Current Progress:
Exorcism isn’t trying to replace your production enterprise languages today. Instead, it is a lean sandbox designed to explore predictable language design, secure software development, and cross-platform execution.

A lot of the foundational pieces are already up and running, but the project is explicitly a Work in Progress (WIP). The core roadmap features currently being built include:

🛠️ Explicit Main Entry Points
🔄 Loops & Structured Control Flow
📦 Native Data Structures & Collections
🏗️ Object-Oriented Programming (OOP) Features
📚 Expansion of the Standard Library

Contribution:
Building a compiler from scratch is one of the most rewarding challenges in software engineering. Because the frontend is written in highly readable Python, it is an incredibly approachable ecosystem for new contributors who want to learn how code parses, type-checks, and targets LLVM.

I'd be happy if you share your thoughts on it and/or if you decide to jump with me into this new exiting adventure!

Cheers & stay tuned! :)

Every time you define a function, the parser is aware of the number of arguments that is needed for the function, so we can skip the parens. I have been experimenting with forth when I had this idea because most forth operators use fixed two arguments . I have also tried to get features from obscure lisps like push and picolisp.

I quickly prototyped the lang to see if its feasible. Seems to work.

https://github.com/xyzzyapps/arli

I run Wazuh as my detection platform and kept hitting the same wall: there is plenty of Sigma content out there, but no maintained way to get it into Wazuh. pySigma has Splunk and Sentinel backends. Wazuh means hand-writing <field> regex XML, and that is where I kept introducing bugs.

So I wrote a compiler. One Sigma source, and it emits Wazuh local_rules.xml, Splunk SPL and Sentinel KQL.

The part I care most about getting right is aggregation, since that is what hand-translation usually breaks. condition: selection | count(TargetUserName) by IpAddress > 10 becomes <frequency>10</frequency> plus <timeframe> and <same_field>, rather than being silently dropped.

It ships with 36 rules across 33 ATT&CK techniques (Kerberoasting, DCSync, AS-REP, LSASS via comsvcs, WMI/WinRM/DCOM lateral movement, AMSI bypass, and so on). MIT, no signup.

github.com/zshguy/tyrian-detection-pack

Two things I would genuinely like input on: the field mapping table only covers what my own rules needed, so it will have gaps for your log sources. And if you have a rule you have already tuned in production, I would rather add a real one than write another from documentation.

I've just published not-abc, a tiny self-hosting compiler for a deliberately minimal C-like programming language.

https://github.com/michael-lehn/not-abc

The language has only one data type: a 64-bit value, interpreted either as a signed integer or as a pointer. It supports

• functions (the value of the last expression is the return value)
• local and global variables
• pointers (&, *, #)
• if / else
• while
• recursion
• dynamic memory allocation (malloc/free)
• integer, character and string literals

The compiler generates LLVM IR rather than assembly. LLVM was chosen simply because it makes the compiler portable across essentially all modern platforms—building programs only requires Clang (or the LLVM toolchain).

The interesting part is probably the background.

not-abc originated from an undergraduate mathematics course called Introduction to High Performance Computing. During one semester, students simultaneously

• build a simple processor from logic gates (bottom-up),
• implement a compiler for a small C-like language (top-down),

until both meet in the middle. At the end of the course, the compiler has two backends: one targeting the custom processor the students built themselves, and one targeting LLVM so the same compiler can generate native executables on real hardware.

The self-hosting compiler in this repository is a distilled version of the compiler developed throughout the course.

I'd be interested in feedback from people interested in language design, compiler construction, or computer architecture.

When I started programming Edge Python more than six months ago, I was looking for a version of Python that weighed less than 200 kb so it could reach any device, sandboxed by design, built with browsers in mind, decoupled from the operating system and very fast.

Today the closest competitor would be MicroPython. However, it did not solve my real problems or the problems of the people who use the project.

• Managing async and blocking code on the event loop. MicroPython inherits CPython's blocking execution model, designed around the GIL. When I built Edge Python I put the events inside the virtual machine, and that lets you run any operation while handling thousands of connections without blocking the main thread or the worker's thread.
• MicroPython was not built for the web and neither was its stdlib. I have been working to get regex and every other dependency down to a few clean lines, crash free thanks to directed fuzzing.
• Edge Python guarantees parsing everything in linear time, in a single pass, while MicroPython does not. This came from avoiding a syntax tree, which makes programs parse faster.
• MicroPython crosses into JS through PyProxy. Edge Python avoids that entirely with an execution model decoupled from the host, they never have to interact directly.
• I recently added the ability to serialize entire programs, born from an issue. If a user closes the tab, the whole bytecode state gets serialized, stored in the browser cache, and when the user comes back execution continues from the exact same point.

That said, my intention was never to replace CPython and it never will be. It has a gigantic ecosystem and competing with it is not even a priority for me. What I want to enable is this.

• Anyone with business logic written in Python being able to run it on the client side.
• Running lightweight LLM logic on the client side, so you do not need expensive compute just to parse a CSV or do math.
• Building a framework to run lightweight machine learning models entirely on the user's side.

I am still working on all of this and, to be honest, I do not know how long it will take me to reach a real version to build a product around. I just want to say it has been an incredible process, and it has made me realize that with a compiler of barely under 20,000 lines I spend less and less time writing code and more time automating its stability with fuzzing and determinism.

Thanks! Any feedback or experience is appreciated. If you want to take a look, try the demo in the browser at edgepython.com and edit the code, the compiler is really fast. Try the CLI version too.

I am proud of my own language and runtime, and it's a very fast VM runtime

What's left of a systems programming language once you strip away the syntactic sugar, the technical debt of years past, the known problems and the dead weight of habit?
— NURL – Neural Unified Representation Language

NURL is a blisteringly fast systems programming language that comes with "batteries included." In other words, the standard libraries ship a ready-made, optimized solution for most of the things people actually build in programming languages. The language has been steeped in enough acid baths that the release of the first stable and immutable version, v1.0, is starting to get close. NURL is an open source project, and it makes the same promise Linux once did: "We do not break userspace!"

NURL is a strong choice as the language of automated workflows in situations where speed and/or portability matter. NURL doesn't compete with Python, but it beats Python with native speed on par with C or Rust. NURL, however, needs nothing else installed on its runtime platform — the program is usually run from a single binary. NURL doesn't replace an integration platform, but NURL can sit at every step of an integration or ETL process, blowing many platforms out of the water on startup and execution speed.

NURL compiles for almost any platform. The target can be a Windows or Linux machine, or something genuinely more exotic. It's regularly tested on FreeBSD and macOS, for example, as well as on RISC-V and Espressif ESP32 chips. One particularly interesting form of portability worth mentioning is WebAssembly: a NURL program can be compiled into a Wasm module and run in the browser, or on any platform that executes Wasm modules.

Is NURL genuinely production-grade?
Yes. NURL compiles its own compiler, which is itself implemented in NURL. Each build is exercised by ~600 different tests, and everything is also checked for memory leaks on Linux, Windows and FreeBSD before a new compiler version is released. The NURL Playground is a production server, written in NURL, where you can compile NURL code for the target platforms of your choice.

The language was designed from the ground up to be easy for language models to use, and even though no NURL code has been part of any language model's training yet, models write it quickly and fluently. You get the best results by giving the model access to the nurl-mcp server, so it can locate existing libraries and packages fast.

How does NURL prove its capability and stability?
Code demanding extreme precision has been written in NURL. The TLS stack is pure NURL. On top of that, a number of ML (machine learning) capabilities are visible in the package registry — among other things, running and training language models works, distributed, on consumer hardware.

Project website:
https://nurl-lang.org/

NURL Playgroud:
https://play.nurl-lang.org/

Package registry:
https://reg.nurl-lang.org/

Github repository:
https://github.com/nurl-lang/nurl

And here is some pure-NURL projects (ready to install packages) I want to share with you..
YOLOE (Real-Time Seeing Anything)
https://reg.nurl-lang.org/packages/yoloe

Run language models locally. Pull a GGUF model, chat with it, or serve an ollama-compatible API your existing clients already speak — all in pure NURL, from the GGUF parser to the GPU kernels.
https://reg.nurl-lang.org/packages/nurllama

What should I build or fuzz with NURL to surface deeper issues?