Programming should feel
like making something.

Keep simple things simple.

The friction: ceremony can make a small operation harder to read than the idea it expresses.

VOID uses indentation, compact declarations, inferred local types and direct construction. A function without a result omits the result annotation. Receiver methods name their receiver explicitly. One for keyword covers iteration, conditions and repetition.

The aim is a small, consistent set of rules that remains useful as the program grows. Powerful types and predictable behavior should still be there when you need them.

Bring readability to native execution.

The friction: a productive editing experience and control over native data should fit into the same workflow.

VOID brings readable source to a statically typed language built on LLVM. Exact-width numbers, value structs, managed objects, interfaces and generics give you ways to express the shape of your data and the behavior your code needs.

Performance work focuses on generated machine code, allocation behavior and collections measured with real applications. Native execution is a foundation to develop, not a substitute for measurement.

Keep lifetime machinery out of ordinary code.

The friction: memory bookkeeping competes with the work your application is supposed to do.

Automatic memory management is central to VOID. Ordinary code should not need manual frees, raw pointer arithmetic, an unsafe escape hatch, placement decisions or collector scheduling.

Values and shared objects still have distinct, explainable behavior. External resources have a separate lifetime: with, defer and deinit make deterministic release explicit rather than leaving it to garbage collection.

Make native integration feel like VOID.

The friction: using an existing library can expose foreign pointers, string formats and ownership rules throughout application code.

The direction is typed .void wrappers and trusted bindings that handle those boundaries. Application developers should work with language values and managed resource identities, rather than learn a second string type just to cross into C.

Implemented subset Trusted host-provided static bindings demonstrate scalar calls, owned UTF-8 transfers, resources and callbacks. General library loading and a public binding workflow are still ahead.

Protect the state you are working in.

The friction: restarting an interactive program can mean reconstructing a scene, replaying inputs or losing the state that revealed a problem.

VOID’s live-development goal is to apply compatible function-body changes while the program keeps running. An incompatible edit should lead to a deliberate decision, rather than a forced restart that discards your session.

Runtime support + future workflow Compatible function replacement exists in runtime integration. Automatic watching and save-triggered replacement remain planned. Changes to layouts, signatures or incompatible capture structures cannot be applied as simple body edits.

Give answers in the language you wrote.

The friction: an error is harder to fix when it points at generated machinery instead of the source you recognize.

VOID’s diagnostic direction is source-first: .void locations, useful ranges and understandable messages. Ordinary errors should speak about your program rather than require you to decode LLVM IR, mangled names or linker details.

The editor is part of that goal. Completion, hover, parameter help and navigation should help you understand your code while you write it. A shared language service keeps editor feedback tied to compiler analysis.

Let the program choose its purpose.

The friction: language choices can become tied to one engine, platform or kind of application.

VOID Language is independent of VOID Engine. Games are one use case alongside desktop applications, tools, systems software and everyday programs.

The portability goal is consistent behavior across Linux, Windows and macOS where dependencies support those platforms. The language should give projects a common foundation without pretending that platform-specific libraries disappear.

Make the pieces work together.

The friction: individually useful features can become a collection of overlapping rules and special cases.

KISS and DRY apply to the language’s construction as well as its surface. VOID favors one authoritative compiler model, shared native lowering and consistent rules for values, references, effects and diagnostics.

The goal is to earn each feature’s place. More syntax, another execution system or an extra spelling should solve a concrete problem before it becomes part of the language.