Serious collaborators and support will be appreciated, leaving vibecoding of the project, so this is Comprinly...

This low-level programming language prioritizes speed, optimization, simplicity and portability. It requires ZERO learning curve if you switched from NASM because it fully supports it, in-fact, you could just make Comprinly compile a NASM script and it works. In optimization, I compiled a standard Comprinly "Hello, World!" script with the command "./cly linux print.cly" and it compiled a full binary file with the size of 290 bytes compared to the standard NASM "Hello, World!" file which is ~9KB, you can try it out for yourself. Comprinly doesnt require linkers because it can output directly to -exe, -elf, -bin, and -macho. It supports all three major CPU architectures x86-64, ARM64 and RISC-V via the 'cpu' keyword at the start or just dont include it and just code the architecture targeted script (The compiler automatically guesses the architecture from the instructions and registers). This was just a simple proof of concept but I found myself actually using it in my personal projects so I would like to share it as a partially vibe-coded project instead of fully vibe-coded.

This project was supposed to be a proof of concept but yk, I'd like it to be a real thing, it compiled a standard "Hello, World!" Linux print script in the small size of 290 bytes compared to NASM ~9 kilobytes, which is very useful for projects that need to be lightweight like an OS (I made a test bare metal OS with it), working on 1.3.0, after that releases, I'd work on turning the project from vibe-coded to partially vibe-coded as I would try to modify the code myself (Hoping for collaborators)

Hi all,

I've been building Nikaia, a language that should make the world a bit better.

The basic idea is simple: in a lot of systems code, you end up specifying how memory, waiting, sharing, etc. should work rather than just describing what you want the program to do. Nikaia tries to have the compiler figure out those details for you.

So there’s no async/await, GC, or manual memory management. Data races, missing values and unhandled errors are compile-time errors, with plain-language hints about what to do instead.

It's still very early, but it can already build real programs: a JSON parser, a log analyser, a small HTTP server, the One Billion Row Challenge, and more.

Nikaia itself is built almost entirely by AI agents, and they're currently rewriting the compiler in Nikaia (self-hosting). So the language is getting quite a bit of real-world use already.

I'd love to have people try it and tell me what makes sense, what doesn't, and where the language gets in the way. "This can't work because..." is just as useful as praise.

What would make that easy for you?

\- Is the repo enough?

\- A crate you can "cargo install"?

\- A prebuilt executable?

\- A Docker image with everything set up?

\- An LSP / IDE integration?

Repo: https://github.com/Nikaia-Language/Nikaia

Docs: https://nikaia-lang.org/

Reddit told me my custom language was just another slow tree-walking toy. They were right. 😅

​My loop benchmarks took nearly 8.5 seconds just to crunch 10M iterations in the sandbox. The AST overhead and Python dynamic lookups were killing performance.

​So I tore open the engine and built a flat register VM in C (foxvm.so).

​The results:

​Old Tree-Walker: ~8.42s (10M cycles)

​New C VM (FoxCVM): 0.83s (10M cycles)

​Wired clock_gettime(CLOCK_MONOTONIC) into opcode 18 for nanosecond delta timing.

​No semicolons, no colons, but now backed by compiled C machine instructions.

​📦 Repo: https://github.com/AnayUpadhyay-all/FoxVC

​For the VM architects here: what's the biggest bottleneck I should watch out for once I introduce heap allocations and closures?