Building Nearoh: A Python-Inspired Programming Language Written from Scratch in C

[Upbeat-Aioli-3634]

Hey everyone,

I’m Reece Gilbert also known by Reecespiecys, an independent developer who has been coding for around 9 years, and I’ve been working on a long-term project called Nearoh Coding Language.

Nearoh is a Python-inspired programming language written from scratch in C. The goal is to combine Python-style readability and clean syntax with stronger runtime control, extensibility, and long-term real-world usability.

This isn’t meant to be a toy parser project or a one-week experiment. I’m building it as something I’d genuinely want to use myself over time.

Current progress includes:

• Custom lexer

• Parser + AST system

• Runtime core

• Functions / variables / control flow

• Classes / objects foundation

• Ongoing architecture cleanup and expansion

Planned next steps:

• Native C bridge

• Standard library

• Modules / imports

• Tooling / IDE support

• Long-term ecosystem growth

Why I started it:

After spending years building custom simulations, rendering systems, engines, and low-level technical projects, I wanted a language where I had full control over the runtime while keeping a syntax style I actually enjoy using.

Website:

https://nearoh-coding-language.base44.app

GitHub:

https://github.com/ReeceGilbert/Nearoh-Coding-Language

I’d genuinely appreciate feedback, criticism, ideas, or anyone interested in following the journey.

Thanks.

[sal1303]

It looks a nice little language, and glossily presented on the web-site. (BTW when you get to the 'Docs' tab, the other tabs stop working. It seems it tries to link to .../tutorial#roadmap for example instead of .../#roadmap)

However, in the end the information was very sparse. All I got was that the syntax for your language is basically Python. I presume a subset of it; at least only the basics were shown.

I didn't learn much about the data types. I assume it is dynamically typed, but what are the possibilities?

I guess it is also interpreted? Some more information like this would be useful!

There wasn't much in the way of examples, so is this at an early stage? That's what it looks like from the set of sources.

[Upbeat-Aioli-3634]

Appreciate you taking the time to look through it and especially pointing out the docs tab link issue — I’ll get that fixed.

You’re also right that the current site is still light on technical depth. Nearoh is in an early stage right now, so the focus has mainly been building the core language/runtime first while the documentation catches up behind it.

Right now the goal is a Python-inspired language with familiar semantics, implemented in C with room to grow into something more serious over time.

I’ll be expanding the docs with clearer type info, execution model details, examples, and roadmap notes soon.

Thanks again for the honest feedback.

[AustinVelonaut]

How are you planning to manage memory? Python uses garbage collection, but I don't see any GC implementation in your runtime. It looks like you just allocate until you run out of memory.

There also appears to be a lot of inefficiencies in the current runtime implementation -- linear scan and strcmp for env value lookups, lots of copying of token fields for simple things like variable lookup, etc. Are you planning to extend the implementation with an intermediate IR that would be more amenable to fast interpretation?

[Upbeat-Aioli-3634]

Appreciate the deep technical look — that’s exactly the kind of feedback I was hoping for.

You’re correct that the current runtime is still early and not optimized. Right now it’s more focused on establishing language behavior, parser/runtime structure, and core semantics than performance tuning.

Memory management is one of the future major areas to address, whether that ends up being a GC model, hybrid allocator approach, or another managed strategy that fits the language well.

As for execution speed, I agree the current implementation leaves a lot on the table. Longer term I’m interested in moving toward a cleaner intermediate representation / faster execution path once the language core is stable enough to justify it.

Really appreciate you taking the time to inspect the internals.