Pure-Rust vs C: Why We Rebuilt the Astrology Ephemeris from Scratch

If you search for a Rust ephemeris library for astronomy or astrology, you find a short list — and almost all of it bottoms out in the same place: a thin binding over the C-based Swiss Ephemeris. That's the honest state of the ecosystem. Swiss Ephemeris is excellent, battle-tested code, and it deserves its reputation. But "wrap the C library" comes with two costs that we were no longer willing to pay: a hard AGPL licensing dependency at the bottom of our entire SaaS stack, and a C FFI boundary that fights every modern deployment target we care about (WebAssembly, on-prem static binaries, zero-unsafe audits).

So we built XALEN — Vedika's own pure-Rust, Apache-2.0 ephemeris engine. This is the engineering rationale, the real accuracy numbers (including where we are not the best), and an honest comparison so you can decide whether it fits your project.

The short version

• Pure Rust, zero-unsafe core, thread-safe, compiles to wasm32. No C, no FFI, no build.rs linking a system library.
• ~336µs for a full chart (all classical bodies + derived placements), so it's cheap enough to run inline in a request path.
• JPL-class accuracy for the planets — sub-arcsecond agreement with NASA JPL DE440 across 1900–2050.
• Apache-2.0, so you can embed it in closed-source, white-label, or on-prem products with no source-disclosure obligation.
• Honest limit: the analytic Moon model is arcsecond-class (~2.8" RMS), not milliarcsecond. If you need JPL-grade Moon/outer-planet precision, load a DE440 SPK kernel.

Why not just wrap Swiss Ephemeris like everyone else?

Let's be precise about what Swiss Ephemeris is, because vague criticism is how blog posts lose credibility. Swiss Ephemeris reproduces the JPL ephemerides to roughly one milliarcsecond. It is the reference implementation in this field. We do not beat it on accuracy, and any vendor claiming to "beat Swiss Ephemeris" is either confused or selling you something. XALEN matches it to JPL-class parity for the classical planets; it does not surpass it.

The problem isn't accuracy. It's two things:

1. The license is copyleft all the way down

Swiss Ephemeris is dual-licensed: AGPL-3.0 OR a paid commercial license. AGPL §13 is the catch — if your networked service links Swiss Ephemeris and serves users over a network, you must offer those remote users the complete corresponding source of your service. For an open-core or proprietary SaaS, that's a non-starter unless you buy the commercial license.

To be fair: the commercial license is a legitimate, well-trodden path. It's a modest one-time fee with 99-year validity — not the "they'll bankrupt you" caricature you sometimes read. Plenty of serious products pay it and move on. Our objection was narrower and architectural: we did not want a copyleft legal dependency sitting underneath every other component we ship. With a permissive engine, white-labeling, on-prem enterprise deployments, and SDK redistribution are trivially clean. That freedom — not avoiding a fee — was the win.

2. The C boundary fights modern targets

Swiss Ephemeris is C. To run it in a browser or an edge worker you cross an FFI boundary or compile C to WASM and marshal across it. To ship a single static binary you manage the C dependency in your build. To pass a zero-unsafe security audit you carve out an exception for the FFI surface. None of these are fatal, but each is friction, and the friction compounds. A pure-Rust core that compiles straight to wasm32-unknown-unknown and links into a static binary removes that whole category of problem.

What's actually under the hood

No magic, no proprietary black box — XALEN is built on the standard analytic theories that the astronomy community has published and validated for decades:

• VSOP87A for the heliocentric planetary positions.
• Truncated ELP2000-82 for the Moon.
• Meeus algorithms for the derived reductions.
• IAU 2006 precession + IAU 2000B nutation for the frame transforms.
• Optional JPL DE440 SPK kernel reader for when you want numerical-ephemeris precision instead of the analytic series.

That last point matters: the analytic theories give you a fast, dependency-free engine that's correct to sub-arcsecond for planets; the DE440 kernel path gives you JPL-grade precision for the Moon and outer planets when a use case demands it. You choose per deployment.

The accuracy numbers (and how to reproduce them yourself)

A skeptical engineer should not take any of this on faith, so here are the real figures and the command that regenerates them. We validated XALEN against NASA JPL DE440 over 1900–2050:

cargo run -p xalen-validation

Every planet is sub-arcsecond. A separate 20,000-chart sweep across the 1900–2050 grid produced zero charts exceeding 0.1° total error — comfortably inside the tolerance that any downstream astrological interpretation (sign, house, nakshatra, dasha boundaries) needs.

The Moon is the honest asterisk. At ~2.8" RMS, the analytic ELP2000-82 truncation is arcsecond-class, not milliarcsecond-class. For the overwhelming majority of astrology work that's invisible — it never changes a sign, house, or nakshatra placement — but if you're doing precision lunar work (occultations, eclipse contact times, exact lunar return instants), load the DE440 kernel and you get the numerical-ephemeris Moon. We tell you this up front because the alternative — pretending the analytic Moon is JPL-grade — is exactly the kind of claim that gets a vendor caught.

Performance: cheap enough to run inline

A full chart computes in ~336µs. That's fast enough that ephemeris computation is never your bottleneck — it disappears behind network latency, serialization, and any LLM or rendering step downstream. Because the core is thread-safe with no global mutable state, you can fan charts across a thread pool without locking, and because it's pure Rust it compiles to a static binary with no runtime dependency to provision.

Install it in 30 seconds

XALEN is published natively to all three major registries — no vendoring, no submodules, no build scripts:

# Rust
cargo add xalen-ephem

# Python
pip install xalen

# JavaScript / WASM (runs in the browser or Node)
npm i @xalen/wasm

The published surface is 15 crates on crates.io at v0.6.0 (xalen-ephem, -coords, -houses, -vedic, -western, -time, -ayanamsa, -stars, -chart, -chinese, -world, -lalkitab, -iching, -numerology, -ffi), @xalen/wasm plus the @vedika-io SDK/MCP/CLI/React packages on npm, and xalen + vedika-sdk on PyPI. The source lives at github.com/vedika-io/xalen-ephemeris under Apache-2.0.

Honest comparison table

Read that table fairly: on raw precision, Swiss Ephemeris wins — especially on the Moon. XALEN's value is the combination of JPL-class planetary accuracy with a permissive license and a pure-Rust/WASM core. If milliarcsecond Moon precision is your hard requirement and AGPL is fine for your context, Swiss Ephemeris is the right tool and we'll tell you so.

The part most comparisons miss: almost everyone wraps Swiss

Here's the structural fact that reframes the whole conversation. Nearly every astrology API and library on the market is, at the bottom, a wrapper around Swiss Ephemeris — and therefore inherits its AGPL posture. That list includes Prokerala, AstrologyAPI.com, DivineAPI, FreeAstrologyAPI, and the popular open-source libraries Kerykeion, flatlib, immanuel, and VedAstro. They are good projects; this isn't a knock on their quality. It's an observation about provenance: when you build on one of them, the AGPL engine is still down there.

The one notable exception is RoxyAPI, which built its own engine (Roxy Ephemeris, JPL-Horizons-validated, MIT-licensed). Credit where it's due — they solved the same independence problem we did, with a permissive license too. Against RoxyAPI the engine-provenance argument is a wash; the comparison shifts to the full stack on top.

An ephemeris is the floor, not the building

This is the other thing to keep in perspective. Swiss Ephemeris — and XALEN's core — give you raw astronomy only: where the bodies are. They do not give you yogas, doshas, dashas, or compatibility scoring. All of that interpretive layer is separate engineering.

That's where the rest of Vedika's stack sits on top of XALEN: 25 systems across roughly 704 operations (~250 public in the sandbox), 104–131 computed yogas, doshas, Vimshottari and conditional dashas, 36-guna matching, Lal Kitab, KP, 60 divisional charts (D1-D60), 50 ayanamsas, and 23 house systems. There's a RAG-grounded conversational query endpoint (POST /api/v1/astrology/query) that answers from sourced material rather than canned templates, native voice (speech-to-text → reasoning → speech) in 30 languages, 30 languages platform-wide, and an MCP server exposing 36 tools for agent integrations. Plans start at $12/mo.

The point isn't "we have more features." It's that the engine and the interpretation are different problems, and conflating them is how people end up comparing a precision library to a product. XALEN solves the floor — accurately, permissively, in Rust. The systems above it solve the building.

Should you use XALEN?

• Use XALEN if you need a permissive-license ephemeris, you're targeting WASM or static binaries, you want a zero-unsafe Rust core you can audit, and sub-arcsecond planetary accuracy with arcsecond Moon (or DE440-backed Moon) is enough.
• Use Swiss Ephemeris if you need milliarcsecond precision including on the Moon by default and AGPL (or the commercial license) is acceptable.
• Use a hosted API like Vedika if you want the interpretation layer — yogas, dashas, matching, conversational answers — without building it yourself.

You can read the docs and try the calculations against your own birth data — no signup — in the free sandbox at vedika.io. Bring a chart you've already computed elsewhere and check our planetary longitudes against it; that's the fastest way to trust (or disprove) anything in this post.