Building software becomes easier when the language understands the system it runs on.
A programming language is not just syntax.
An operating system is not just a runtime environment.
They define how software thinks about computation.
Most modern languages were designed for existing operating systems and processor architectures. They inherit concepts created decades ago:
- processes;
- files;
- threads;
- virtual memory;
- shared resources;
- system calls.
These concepts are powerful, but they also bring complexity.
While designing Sekura JS and Reganta OS, I started from a different question:
What if a programming language and an operating system were designed together from the beginning?
This idea became one of the foundations of my experimental computing stack.
From knowledge to systems
Before designing a language or an operating system, I encountered a more fundamental problem.
Complex systems contain thousands of decisions:
- why a component exists;
- why a specific model was chosen;
- which constraints must always remain true;
- which approaches were rejected;
- how different parts depend on each other.
These decisions are difficult to preserve.
That is why I am also building Sekura Noda.
Sekura Noda helps experts use AI to accumulate, improve, and monetize their unique expertise.
Noda provides a knowledge layer where important decisions can be captured, reviewed, and used by humans and AI.
This is especially important when designing systems that span multiple layers.
A programming language affects the operating system.
The operating system affects the hardware model.
Hardware limitations affect the language design.
Without explicit knowledge, these relationships become difficult to maintain.
Why create another programming language?
Creating a new programming language is usually unnecessary.
Most applications can be built with existing tools.
But a language becomes interesting when the underlying execution model changes.
Sekura JS is designed together with Reganta OS.
The goal is not to create another general-purpose language with hundreds of features.
The goal is to create a language where important system concepts are visible.
A programmer should understand:
- what a module represents;
- what data a module can access;
- how information moves between components;
- what contracts exist between parts of the system.
Instead of hiding system behavior behind multiple layers of abstraction, the language should help describe the actual architecture.
Modules instead of traditional applications
Traditional operating systems usually organize software around applications and processes.
Reganta OS explores a different model.
The primary unit is a module.
A module is a defined computational component with:
- inputs;
- outputs;
- resources;
- responsibilities;
- relationships with other modules.
Instead of thinking:
Start an application and let it manage everything internally.
The model becomes:
Connect specialized modules that perform specific functions.
For example:
Input Stream
↓
Parser
↓
Processing Module
↓
Output Stream
Each component has a clear role.
The system becomes easier to reason about because interactions are explicit.
Pages and streams
Reganta OS is built around explicit data movement.
Two important concepts are:
Streams
Streams allow modules to exchange information.
Small messages can move through lightweight communication channels.
A module can receive data, transform it, and send the result to another module.
Pages
Pages represent larger units of data.
Instead of every component copying and recreating data, pages can move through the system as identifiable objects.
This changes the way software thinks about memory.
Data is not only something an application temporarily owns.
It can be an explicit object moving through a chain of processing steps.
The kernel as an orchestrator
Traditional operating systems provide many universal mechanisms:
- process scheduling;
- filesystems;
- permissions;
- memory abstraction;
- background services.
Reganta OS focuses on a smaller role.
The kernel acts primarily as an orchestrator:
- connecting modules;
- managing communication;
- controlling resource access;
- coordinating execution.
The purpose is not to support every possible workload.
The purpose is to create a predictable environment for systems designed around explicit modules and data flows.
Why design language and OS together?
A programming language usually assumes an existing operating system.
The operating system usually assumes existing programming models.
This creates layers of historical decisions.
By designing Sekura JS and Reganta OS together, it becomes possible to align:
- language concepts;
- execution rules;
- memory model;
- communication model;
- system contracts.
A language can expose the strengths of the operating system.
An operating system can provide exactly the environment the language expects.
Neither has to compensate for the limitations of the other.
Building understandable systems
Modern software systems are extremely powerful.
But they are also difficult to understand.
Complexity accumulates through:
- hidden assumptions;
- undocumented decisions;
- incompatible abstractions;
- layers built on top of previous layers.
My goal with Sekura JS and Reganta OS is not simply to build different technology.
It is to explore whether systems can become more understandable by making their fundamental concepts explicit.
This is also why Sekura Noda is part of the same vision.
The ability to build complex systems depends not only on code.
It depends on preserving the knowledge behind the code.
The bigger picture
The relationship between the projects is:
Human expertise and system knowledge
↓
Sekura Noda
↓
Programming model
↓
Sekura JS
↓
Execution environment
↓
Reganta OS
↓
Hardware architecture
↓
Memora8
Each layer defines the next one.
The language describes the system.
The operating system executes the language.
The hardware supports the execution model.
And Noda preserves the knowledge required to evolve the entire architecture.
AI was used for English translation and editorial refinement. The ideas, architecture, and technical decisions described in this article are the author’s own.
Top comments (0)