IntroductionPolyglot Architecture

The Multi-Process
Engine

Vextor AI abandons the monolithic JavaScript architecture of traditional editors. By distributing heavy workloads across native Rust and Go binaries, we have engineered an IDE that refuses to bottleneck.

01. The Monolith Fallacy

Virtually every modern editor (including VS Code, Cursor, and their derivatives) relies on an Electron/Node.js monolith. In this architecture, the UI rendering, the integrated terminal, the file-system watcher, and the extension host all share the same underlying V8 JavaScript engine.

This creates a fatal ceiling. When an AI extension attempts to parse an entire 10,000-file repository to build a context graph, the single-threaded event loop becomes completely saturated. The result is UI stuttering, dropped terminal inputs, and high RAM consumption.

The Legacy Bottleneck

1. User types in Terminal ➔ Node.js Event Loop

2. AI Scans File System ➔ Node.js Event Loop (BLOCKING)

3. Terminal input drops because Event Loop is busy.

02. The Tri-Core System

Vextor AI introduces a Polyglot Sidecar Architecture. We split the IDE into three isolated processes, each written in the language best suited for its task.

1. The Presentation Layer (React & Electron)

Handles rendering the UI, code editor visuals, and animations. Because no heavy background tasks run on this thread, the UI consistently hits 60FPS.

2. The Intelligence Layer (Rust)

An independent Rust binary handles file-system watching, Abstract Syntax Tree (AST) parsing, and context mapping. Rust's zero-cost abstractions allow it to track 100,000+ file dependencies using less than 40MB of RAM.

3. The Execution Layer (Go)

A concurrent Go server manages the Pseudo-Terminal (PTY). Go's goroutines provide perfect, non-blocking I/O streaming, meaning your terminal will never freeze even if a compiler spits out millions of lines of logs.

03. Inter-Process Communication (IPC)

Having three isolated environments is useless if they cannot communicate instantaneously. Vextor avoids standard JSON-over-HTTP due to parsing overhead, opting instead for highly optimized memory bridges and raw socket streams.

Architecture Diagram // Data Flow

[React UI] (Main Thread)
   │
   ├───> IPC Bridge (WebSockets / Binary Protocol)
   │        ├──> [Go Server] ──> Manages PTY / shell execution
   │        └──> [Rust Engine] ──> Parses AST & File Tree
   │
[llama.cpp GGUF] <────> Memory Mapped (Zero-Copy) into Rust

The Go WebSocket Bridge

The terminal in the React UI is a lightweight xterm.js canvas. It acts purely as a dumb display. Every keystroke is sent as an ArrayBuffer over a local WebSocket to the Go server. The Go server pipes it into the native Windows/Linux shell, and streams the binary output directly back to the canvas. No string manipulation occurs in Node.js.

The Rust Native Interface

Rust communicates with Electron via Node-API (N-API). Instead of serializing large syntax trees into JSON and sending them over local network ports, Rust writes the parsed code flow directly into shared memory buffers that the V8 engine can read instantly.

04. Security Isolation

By physically detaching the AI logic from the terminal execution logic, we achieve a deterministic security model that is impossible in legacy editors.

🛡

The Go Execution Interceptor

When the Natural Language CLI generates a command like rm -rf .git, the React UI does not have permission to execute it. It sends a "Command Request" to the Go server. The Go server cross-references the command against a hardcoded list of destructive keywords. If flagged, the Go binary physically blocks the PTY stream until the user manually confirms the action in the UI.

The Multi-Process Engine