Perla

Why Perla?

Real Perl is wonderful for scripting and prototyping. Perla is for the moments where you'd rather ship a compiled artifact than a script that depends on a runtime.

📦

Single-binary deploys

One statically-linked executable. No perl to install on the target, no version skew, no CPAN bootstrap, no cpanm on boot. Drop it on a server or into a container and run.

⚡

Faster startup

No perl interpreter warm-up. For short-lived scripts and CLI tools that get invoked constantly, the difference between 40ms perl startup and a sub-millisecond native exec matters.

🏎️

Native-code performance

Tight inner loops compile to real machine code. Perla's backend is Strada — which consistently outruns Perl, Python, and Ruby on CPU-bound work. You choose the tradeoff: -O0 for fast compiles, -O3 for release.

🔧

Raw C when you need it

__C__ { ... } drops inline C into a Perl sub. FFI to libc, libcurl, zstd, or a custom .so — without writing XS. All of Perl's value for rapid development, all of C's value for the 5% that needs it.

🌐

Web framework ready

Runs well under Cannoli, Strada's preforking web server. Perla-compiled handlers load as .so's — see the cannoli_perla bridge for how large-scale apps serve HTTP.

🧠

Keep your Perl brain

Sigils, regex, map/grep/sort, bless, AUTOLOAD, Moose-style has/extends/with, Try::Tiny, DBI, JSON — the idioms you know from Perl work here. Native implementations of the most-used XS modules built in.

💾

Precompile once, run many

perla -M lib/ builds every module in a tree to .pm.o once. Subsequent compiles of scripts that use them skip re-parsing the source — a big speedup on programs with deep use trees.

🧪

Predictable memory

No GC pauses, no global interpreter lock, no mysterious memory growth. Reference counting with escape-analyzed tagged integers — allocation patterns are explicit and debuggable with valgrind.

Be honest — what Perla isn't

Not a drop-in Perl replacement. A 5000-line Perl codebase will usually compile, but you'll hit a few idioms that need rework — typically obscure XS modules, eval STRING at runtime, or very baroque overload dispatch.
Compile time is real. A large app with transitive use chains can take a minute or two. Use make precompile / -M DIR/ to warm the cache.
XS modules without native Perla equivalents are silently skipped. You'll need to provide a Perl-or-Perla implementation, or wrap the C library yourself via __C__.
Debugging is C-level, not Perl-level. --keep preserves the generated .c for inspection, but you won't have perl -d.

Example

This is just Perl.

Compile, run, ship. No preamble, no type annotations, no IDE setup.

# hello.pl
use strict;
use warnings;
use JSON;

sub greet {
    my ($name) = @_;
    return encode_json({ hello => $name, time => time() });
}

print greet("world"), "\n";

$ perla -O2 -o hello hello.pl
$ ./hello
{"hello":"world","time":1755123456}

$ file hello
hello: ELF 64-bit LSB pie executable, x86-64, statically linked

That's the entire workflow. perla reads your .pl, resolves its use tree, lowers it to Strada, compiles to C, and links a binary. No cpanm install JSON, no Carton bundling, no fatpack. The JSON encoder is wired into Perla's runtime as a native module.