GOALS = [
("confidence", ["pure functions", "explicit effects"]),
("speed", ["native code", "structured concurrency"]),
("approachability", ["small syntax", "direct control flow"]),
("durability", ["typed failure", "safe bounds"]),
]
pure func format_goal(goal: (String, List[String])) -> String:
(name, features) = goal
"${name}: ${features.join(", ")}"
func main(args: List[String]):
pitch = GOALS
.map(format_goal)
.join("\n")
print(pitch)
Features
Blorp keeps the language surface direct while making effects, failure, and concurrency easier to reason about.
- Readable syntaxIndentation, keyword operators, and method-style calls keep code easy to scan.
- Static safetyStrong types, checked imports, explicit fallibility, and exhaustive
matchmake mistakes harder to hide. - Purity tracking
pure funcseparates deterministic logic from code that can perform I/O. - Value semanticsAssignment behaves like an independent value, while ARC/COW keeps sharing efficient.
- Typed absence and failure
Option,Result,match, and?=put uncertainty in the type flow. - Structured concurrencyScoped tasks, joins, timeouts, and channels keep concurrent work bounded.
- Compile-time boundsFixed dimensions let the compiler prove safe indexing for arrays, vectors, and matrices.
- Native performanceBlorp compiles to C while keeping performance work visible.
- Tool-friendly designStable formatting and explicit effects make human and AI-written code easier to review.
Built for Humans and AI
AI can generate code quickly, but generated code still has to be reviewed, debugged, and maintained. Blorp makes that work easier. Pure functions, explicit effects, structured concurrency, typed failure, managed memory, and compile-time bounds checking reduce the number of things a human or model has to worry about.
Performance
Blorp compiles to C, so idiomatic Blorp code is intended to run within range of hand-written C. Below is a recent benchmark snapshot from the Blorp benchmark suite, run on an M4 MacBook Air. It's not meant to be authoritative, but shows broadly where blorp is positioned.
| Benchmark | Blorp | C | Go | Python |
|---|---|---|---|---|
| numeric_loop | 0.1242s | 0.1215s (1.0x) | 0.1726s (1.4x) | 5.1754s (41.7x) |
| fib | 0.1979s | 0.1970s (1.0x) | 0.2600s (1.3x) | 7.6289s (38.5x) |
| string | 0.1169s | 0.1071s (0.9x) | 0.1681s (1.4x) | 0.1323s (1.1x) |
| array_sum | 0.0011s | 0.0005s (0.5x) | 0.0045s (4.1x) | 0.0957s (87.0x) |
| array_ops | 0.0069s | 0.0056s (0.8x) | 0.0179s (2.6x) | 0.4976s (72.1x) |
| dict_ops | 0.1370s | - | 0.1340s (1.0x) | 0.3506s (2.6x) |
| list_ops | 0.1236s | - | 0.2074s (1.7x) | 0.4296s (3.5x) |
| set_ops | 0.2573s | - | 0.5509s (2.1x) | 0.2332s (0.9x) |
| threaded_cpu_map | 0.0150s | 0.0110s (0.7x) | 0.0191s (1.3x) | 0.9889s (65.9x) |
| channel_pipeline | 0.0262s | 0.0345s (1.3x) | 0.0092s (0.4x) | 0.1952s (7.5x) |
| sleep_fanout | 0.0084s | 0.0118s (1.4x) | 0.0061s (0.7x) | 0.0376s (4.5x) |
| options | 0.0148s | - | - | - |
| simd | 0.1302s | 0.1071s (0.8x) | - | - |
| nbody | 0.0539s | 0.0495s (0.9x) | 0.0489s (0.9x) | 3.0480s (56.5x) |
| binary_trees | 0.1217s | 0.1125s (0.9x) | 0.1158s (1.0x) | 0.6813s (5.6x) |
| fannkuch | 0.3254s | 0.1819s (0.6x) | 0.1493s (0.5x) | 2.6348s (8.1x) |
| spectral_norm | 0.0160s | 0.0106s (0.7x) | 0.0140s (0.9x) | 0.9081s (56.8x) |
| mandelbrot | 0.0020s | 0.0021s (1.0x) | 0.0195s (9.8x) | 0.0590s (29.5x) |
| knucleotide | 0.0231s | - | 0.0153s (0.7x) | 0.0601s (2.6x) |
| reverse_complement | 0.0003s | - | 0.0001s (0.3x) | 0.0022s (7.3x) |
Run details: in-process BENCH markers, 52 binaries compiled up front, 4 benchmark threads, Apple clang 21.0.0, Go 1.26.3, Python 3.14.4, and Python concurrency 3.14.4. Comparison cells show time plus the benchmark suite's reported factor relative to Blorp. A dash means that runner was not reported for that benchmark. See performance tools
Technical Details
Blorp is meant to feel direct at the surface while keeping the compiler's safety and runtime choices explicit.
- Static TypesThe compiler checks imports, calls,
matchexhaustiveness, and fallible values before code reaches the C backend. - Hindley-Milner-Style InferenceLocal names usually do not need annotations; types flow from literals, calls, branches, and generic uses.
- Value SemanticsAssignment and updates behave like independent values, while
ARCandCOWkeep common sharing cheap. - Perceus OwnershipThe compiler lowers ownership with Perceus-style dup/drop and reuse analysis, then runtime reference counts preserve source semantics.
- Native OutputTyped programs lower through
Core IRto generated C, then a C compiler produces a native binary.