Business & Finance
Blorp Language
Key Points
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...
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
match
make mistakes harder to hide. - Purity tracking
pure func
separates 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.
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,
match
exhaustiveness, 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
ARC
andCOW
keep 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 IR
to generated C, then a C compiler produces a native binary.