Ostrin

Experimental scientific-computing language by Andrés Monreal.

A programming language built from first principles.

Ostrin is an experimental programming-language project for scientific computing. It is implemented in Rust and brings syntax, examples, tests and release tooling into one open-source project.

Why Ostrin?

Scientific work depends on how ideas are represented, calculated and shared. Ostrin explores language design as a place where numerical reasoning, reproducibility and developer tooling can meet.

Design principles

  • Start from clear language and computational concepts.
  • Keep examples close to the implementation.
  • Make releases and test inventories inspectable.
  • Explore scientific-computing ideas without presenting an unfinished system as a finished solution.

What works today

  • A public Rust implementation with public source code and examples.
  • An MIT license and public release v0.1.0.
  • A stable release test inventory and a separate development inventory.
  • Public documentation, repository history and release artifacts.

Language and tooling

The public repository describes Ostrin as a design-validation compiler and interpreter for scientific computing. Its documented direction includes:

  • physical quantities as types, with dimensional checks before execution;
  • immutable-by-default state, records, enums, generics, traits and pattern matching;
  • a compiler, checker and interpreter implemented in Rust;
  • deterministic cooperative scheduling with optional native-thread support;
  • JSON Lines diagnostics and compiler indexes for editor tooling;
  • LSP and debug-adapter tooling, plus a VS Code extension;
  • an experimental native C backend and a reproducible WASI release workflow.

These are capabilities and project descriptions reported by the public repository. They are not independent scientific validation, production-readiness claims or benchmark results. See the Ostrin README and design documentation for the canonical technical record.

Tooling and documentation

The canonical documentation and examples live in the project website and repository. This page provides context and points back to those sources.

Status & Validation

Experimental · public · open source
Implementation: Rust
License: MIT
Stable release: v0.1.0

Track Test inventory Meaning
Stable v0.1.0 208 200 integration/example, 2 unit and 6 differential tests in the tagged release
Development main 246 238 integration, 2 unit and 6 differential tests in the development inventory

Development snapshot verified: 28 September 2026, commit d22c54750710d18be95932bce40c7777fe8d4d3a. The main count is read from the commit-pinned public repository README and may change as development continues. The 208-test and 246-test inventories describe the repository’s own test suite. They are not benchmark results, independent scientific validation, production-readiness claims or evidence of external adoption.

Release history

Reference Status Evidence boundary
v0.1.0 Public stable release record 208 tests in the tagged release; GitHub release
main snapshot Development line 246 tests at the dated commit above; the count is dynamic and can change

Roadmap

  1. Document a focused set of reproducible language examples.
  2. Define a benchmark protocol before publishing performance comparisons.
  3. Add citation metadata and archive an important version.
  4. Consider a technical report or software publication after the project has a mature validation record.