Proton-lang

Proton is a systems-flavored language and tooling stack that now includes a compiler, an analyzer engine, Git-aware developer tooling, a lightweight package registry workflow, and editor support. The current implementation targets a JavaScript runtime, but the language surface is aimed at low-level control, static guarantees, and platform-style workflows.

• Unique Abilities
• View Repository
• View Changelog
• Why Proton-lang was created

• Previous

Unique Abilities of Proton-lang

Below is a list describing what was added to the Proton language

• Previous

Changelog

• Previous

Syntax

Syntax Guide## Modules, Imports, Plugins, PermissionsEvery file starts with a module path.proton
module demo.main;
Regular imports stay explicit, and plugins are declared separately.proton
use core.io::print;
use plugin "git";requires net, file;
## Execution Modes and ModifiersFunctions can declare execution intent and modifier-style capabilities.proton
inline fn fast_add(a: int, b: int) -> int :: strict {
return a + b;
}gpu fn render(batch: int) -> int :: parallel {
return batch;
}fn sanitize_input(input: str) -> str :: secure {
return sanitize(input);
}adaptive fn choose_strategy() -> int :: strict :: parallel {
return 0;
}
Supported mode keywords:- strict
- unsafe
- parallel
- secure
- gpu
- adaptive## Ownership BindingsProton keeps the ownership model introduced earlier:- core: owning binding
- link: shared mutable-capable link
- ghost: read-only shadow viewproton
core data: Vec<int> = [1, 2, 3];
link shared: Vec<int> = data.link();
ghost view: Vec<int> = shared.ghost();mutate(shared) {
push(4);
}
## Types, Generics, and Constraints### Built-in Types- int
- i32
- i64
- f32
- f64
- bool
- str
- void
- *T
- &T
- Vec<T>
- named structs and algebraic types
- builtin runtime structs such as MemBlock and HttpResponse### Generic Constraintsproton
fn process<T: Numeric + Serializable>(input: T) -> T :: strict {
return input;
}
Current built-in constraint names with special handling:- Numeric
- SerializableContract names may also be used as constraints for struct types that implement them.## Structs and Algebraic Data Typesproton
struct Circle {
radius: int,
}type Result<T, E> {
Ok(T),
Err(E)
}
Variant constructors can be written as Ok(value) or Result::Ok(value) when the type is clear.## Pattern MatchingPattern matching is an expression.proton
fn unwrap_or_zero(result: Result<int, str>) -> int :: strict {
return match result {
Ok(value) => value,
Err(error) => 0
};
}
Supported patterns:- wildcard: _
- identifier capture: value
- variant patterns: Ok(value) or Err(error)
- boolean patterns
- integer patterns
- string patterns## Contractsproton
contract Drawable :: O(n) {
fn draw(self: Circle) -> void :: strict;
}impl Drawable for Circle {
fn draw(self: Circle) -> void :: strict {
return;
}
}
## Meta Functionsmeta fn declarations still run at compile time for top-level constants.proton
meta fn factorial(n: int) -> int :: strict {
if n == 0 {
return 1;
}return n * factorial(n - 1);
}const result: int = factorial(10);
## Systems Runtime SurfaceCurrent built-in runtime paths:- core::mem::alloc
- core::mem::stack_alloc
- core::mem::heap_alloc
- core::mem::free
- core::net::http_get
- core::net::http_post
- core::net::socket_connect
- core::net::json
- core::meta::type_of
- core::debug::panic
- core::plugin::loaded
- warn
- log
- runtime
- systemExample:proton
requires net;fn main() -> int :: strict {
let block: MemBlock = core::mem::alloc(128);
let response: HttpResponse = core::net::http_get("https://example.internal");
core::mem::free(block);
return response.status;
}
## PluginsPlugins are imported explicitly.proton
use plugin "crypto";
use plugin "git";fn main() -> int :: strict {
let digest: str = crypto.hash("hello");
let diff: str = git.diff();
return 0;
}
Current built-in plugin surface:- crypto.hash
- crypto.verify
- git.commit
- git.branch
- git.diff## Concurrency, Intent, Sandbox, Graphs, Channelsproton
spawn audit {
core::concurrent::yield();
}sync {
await audit;
}intent optimize {
core::math::abs(-4);
}sandbox {
core::io::print("isolated");
}graph {
node fetch -> node hash -> node persist;
}channel events;
send events { user_logged_in };
intent, sandbox, graph, and channel/send compile today; graph and channel activity are tracked in the runtime metadata.## Temporal ProgrammingTime is a first-class syntax surface through timeline blocks and duration literals.proton
timeline {
at "startup" -> init();
after 5s -> refresh_cache();
every 10s -> monitor_runtime();
}
Supported duration suffixes:- ms
- s
- m
- hCurrent runtime behavior:- at "startup" actions execute automatically before main()
- after and every actions are preserved as runtime metadata for host schedulers and tooling## Self-Observation and Adaptive Executionobserve blocks expose tracked runtime values inside a function body, and adapt blocks let code branch on environment state.proton
adaptive fn handle_requests() -> int :: strict :: parallel {
let mut profile: str = "balanced";adapt {
if system.cpu < 4 {
profile = "low_power";
} else {
profile = "high_performance";
}
}observe {
track: execution_time, memory_usage;if execution_time > 100ms {
warn("Slow function detected");
}
}return 0;
}
Built-in runtime values available today:- runtime.time
- runtime.uptime
- runtime.mode
- system.cpu
- system.memory
- system.profile## Behavior InjectionBehavior can be wrapped around a function without editing the function body directly.proton
inject into handle_requests {
before {
log("Starting request handling");
}after {
observe {
track: execution_time;
if execution_time > 100ms {
warn("Slow function detected");
}
}
}
}
The current implementation generates safe wrappers around the function body at compile time.## Outcome-Oriented ProgrammingTop-level goals describe system intent, and local goal statements annotate hot paths.proton
goal {
minimize latency;
maximize throughput;
}fn handle_requests() -> int :: strict {
goal optimize_performance;
return 0;
}
Goals currently feed runtime metadata and analyzer insights.## Analyzer and Detector BlocksAnalyzer blocks configure the rule sets the CLI should emphasize.proton
analyze {
target: main.ptn;
rules: [
performance,
memory,
security
];
}
Custom detectors define rule-based findings.proton
detector MemoryLeak {
when alloc without free {
warn("Possible memory leak detected");
}
}
## Algorithms, Networks, Builds, Monitoring, SuggestionsThese Phase 4 blocks are declarative today and feed the analyzer/inspection layer.proton
algorithm SortAlgo<T> {
requires Comparable;fn run(data: Vec<T>) -> Vec<T> :: strict {
return data;
}
}network cluster {
node "auth" at "10.0.0.1";
node "db" at "10.0.0.2";
route auth -> db;
}build {
mode: optimized;
analyze: true;
detect: memory, performance;
}monitor {
track: cpu, memory;
alert if memory > 80%;
}suggest {
if loop inefficient {
recommend("Use parallel execution");
}
}
## CLIbash
protonc check file.ptn
protonc analyze file.ptn
protonc build file.ptn --out-dir build --analyze
protonc run file.ptn
protonc inspect file.ptn --jsonproton git status
proton ci initprotonpm search git
protonpm add web 0.1.0
protonpm list
protonpm publish my-lib 0.1.0 "Local Proton package"
## Current Boundaries- match arms currently produce expressions, not statement blocks
- algorithms are parsed and analyzed, but not yet emitted as callable runtime namespaces
- network/build/monitor/suggest blocks are currently declarative metadata, not full autonomous subsystems
- the analyzer is rule-based today rather than ML-driven

• Previous

Roadmap

Current Release: 0.5.xPhase 5 establishes Proton as a runtime-aware language platform with:- temporal declarations
- self-observation blocks
- adaptive execution markers
- behavior injection wrappers
- outcome-oriented goal metadataNear-Term Priorities1. Native scheduling for after and every timeline entries
2. Stronger runtime metrics beyond synthetic memory/execution placeholders
3. Goal-aware optimizer passes that can rewrite generated code paths
4. Expanded plugin ABI beyond built-in demo plugins
5. Hosted registry workflow for protonpmPhase 6-Style Opportunities- native or LLVM-backed code generation
- long-running runtime monitor and debugger hooks
- richer cluster/network orchestration semantics
- structured package publishing and version resolution
- production-grade hot behavior swapping with rollback guaranteesQuality BarFeatures should land only when they have all three:- language syntax
- compiler/runtime behavior
- docs and testsThat rule keeps Proton ambitious without drifting into placeholder-only language design.

• Previous

Proton Architecture

OverviewProton is structured as a compact language platform with four major layers:1. Frontend: lexer, parser, and AST construction
2. Semantics: typechecker, permission checks, contract validation, and module summaries
3. Execution: meta evaluator and JavaScript code generator
4. Tooling: analyzer engine, CLI commands, package workflow, and VS Code supportCompiler PipelineSource compilation flows through:1. compiler/lexer.ts
2. compiler/parser.ts
3. compiler/typechecker.ts
4. compiler/meta.ts
5. compiler/codegen.ts
6. compiler/compiler.tsThe output is JavaScript plus rich analysis metadata used by the CLI and docs tooling.Runtime ModelThe generated runtime exposes:- ownership-friendly cell wrappers
- plugin bridges for crypto and git
- memory and networking helpers
- graph and channel logs
- timeline metadata
- goal metadata
- runtime/system inspection helpersPhase 5 features are represented in two ways:- executable behavior for startup hooks, injected before/after wrappers, observation locals, and adaptive runtime branches
- metadata for future host/runtime evolution, including deferred timeline entries and optimization goalsPhase 5 SystemsTemporal Executiontimeline declarations are gathered at compile time and emitted into globalThis.__proton_timeline.- at "startup" hooks execute before main()
- after and every entries remain declarative metadata todaySelf-Observationobserve blocks synthesize runtime locals such as:- execution_time
- memory_usageThese values are available to normal Proton control flow and also inform analyzer messaging.Adaptive Executionadaptive fn is a semantic marker, while adapt { ... } emits environment-aware branches using runtime system info.Current runtime signals:- system.cpu
- system.memory
- system.profileBehavior Injectioninject into target wraps generated functions with before and after blocks. This is compile-time weaving, not live machine-code hot patching.Outcome-Oriented Goalsgoal declarations and statements are collected into summaries and runtime metadata. Today they are advisory and analyzable, not auto-optimizing compiler directives.Analyzer ArchitectureThe analyzer in compiler/analyzer.ts walks AST structures and merges:- built-in rule packs
- custom detector declarations
- system-level heuristics from timelines, observation blocks, injections, goals, and adaptive functionsThis keeps Proton's "intelligence" layer explicit and inspectable rather than hidden in opaque compiler behavior.Tooling SurfaceCLI entrypoints:- cli/protonc.ts: check, inspect, analyze, build, run
- cli/proton.ts: Git passthrough and CI scaffolding
- cli/protonpm.ts: local package/registry workflowEditor support:- vscode-extension/ for language registration and syntax highlightingCurrent Technical Boundaries- JavaScript is the only backend
- plugins are curated and host-assisted
- timelines beyond startup are metadata rather than background schedulers
- goals and suggestions do not yet rewrite generated code automatically
- runtime monitoring is modeled through observation and analyzer insight rather than a daemonized profiler

• Previous

Why Proton ExistsProton exists because there is still a gap between what systems developers want to express and what most mainstream languages let them express directly.Many languages are good at one or two of these:- low-level control
- expressive abstractions
- strong tooling
- runtime insight
- adaptive behaviorVery few try to treat all of them as part of the same language story.Proton exists to explore that missing combination.The Core ProblemModern software is no longer just "run this function and return a result."Real systems need to answer questions like:- What should happen at startup versus later over time?
- How should code react to the environment it is running in?
- How can we observe behavior without bolting on a separate profiling universe?
- How can we declare goals like latency or throughput in a way the toolchain can understand?
- How can we evolve behavior safely without turning production code into ad hoc patchwork?In most stacks, those concerns are split across:- the language
- the runtime
- the scheduler
- the profiler
- the deployment platform
- a pile of custom toolingProton exists because that fragmentation makes complex systems harder to reason about than they should be.Why Not Just Use Existing Languages?Existing languages are powerful, but they usually make tradeoffs Proton wants to challenge.1. Time Is Usually Outside the LanguageTimers, schedulers, cron jobs, and lifecycle hooks are usually framework or platform concerns.Proton asks a different question:What if time was part of the language model itself?That is why features like timeline exist.2. Runtime Insight Is Usually Bolted OnMost languages require external profilers, dashboards, tracing systems, or runtime agents before code can understand how it is behaving.Proton wants runtime observation to be something the language can talk about directly, which is why constructs like observe and runtime exist.3. Adaptation Is Usually Manual and ScatteredDevelopers often hand-roll environment checks, deployment-specific switches, and hardware-specific branches.Proton exists to make adaptive behavior explicit and analyzable rather than hidden in incidental conditionals.4. Intent Rarely Reaches the CompilerDevelopers care about throughput, latency, memory use, safety, and execution mode. Most of the time, those intentions live in comments, tickets, or tribal knowledge.Proton exists to move more of that intent into code the toolchain can inspect.5. Tooling Is Too Often an AfterthoughtGreat language syntax without analyzers, CLI workflows, documentation, package flows, and backend integration is not enough.Proton exists as a language platform, not just a parser.What Proton Is Trying to BeProton is trying to become a language for systems that are:- performance-aware
- environment-aware
- time-aware
- observable
- behaviorally programmableThat does not mean Proton is trying to replace every language.It means Proton is trying to define a category where:- systems intent is first-class
- runtime metadata is useful, not incidental
- tooling and language design evolve together
- advanced behavior is explicit enough to analyzeGood Reasons Proton Should Exist1. To Make Systems Intent ExplicitA lot of serious engineering work is about intent:- this path must be secure
- this work should be parallel
- this system should prefer low latency
- this code should adapt to weaker hardwareProton exists so those ideas can be encoded directly instead of being spread across documentation and conventions.2. To Reduce the Distance Between Code and OperationsBackend systems, compilers, runtimes, schedulers, and monitoring tools often evolve separately.Proton exists to reduce that gap by letting execution behavior, analysis, and runtime signals live closer to the source language.3. To Encourage Better Tooling from Day OneMany languages grow syntax first and tooling later.Proton exists with the opposite instinct:- analyzers matter
- inspection matters
- runtime metadata matters
- backend/service integration matters
- docs matterThat is a healthier foundation for real-world adoption.4. To Explore Safer Runtime AdaptationProduction systems often need to change behavior based on:- machine capabilities
- observed latency
- memory pressure
- deployment contextProton exists to make that kind of change more structured and reviewable.5. To Provide a Place for New Systems IdeasNot every language project needs to be conservative.Proton exists as a place to test ideas that mainstream languages usually leave to frameworks, infrastructure, or custom platform code.Examples include:- temporal programming
- goal-oriented directives
- compile-time/runtime observation loops
- safe behavior injectionEven when those ideas start as metadata or constrained implementations, the language gives them a place to mature.6. To Build a Language That Feels Like a PlatformProton is not only about syntax.It is also about:- compiler behavior
- analyzer workflows
- execution metadata
- editor support
- backend APIs
- documentation qualityThat platform mindset is a good reason for Proton to exist, because modern development is shaped by ecosystems, not syntax in isolation.What Keeps Proton HonestAmbition alone is not enough. Proton should only exist if it stays honest about what is real today versus what is aspirational.That means:- documenting boundaries clearly
- testing features end to end
- avoiding fake "AI" or fake optimizer claims
- treating metadata as metadata until it becomes executable behaviorProton does not need to pretend to be finished to justify its existence.It only needs to pursue a meaningful direction with discipline.The Short VersionProton exists because systems software deserves a language that treats execution, time, observation, adaptation, and tooling as part of one design space.That is a strong enough reason to build it.

Contact:

• Instagram
• TikTok
• GitHub
• Email