Challengers in Rust

1

Recently, I gave a look at the Rust ecosystem for Orekit’s related feature. And I found some challengers, I think.

First, I have to admit I have a superficial understanding of Orekit’s features. So, I’m clearly unable to evaluate if the challengers can effectively compete against Orekit or not. My journey is different. Java is a well established language, for years. The people contributing to Orekit and Hipparcus and Rugged did a fantastic job to propose efficient features on the Java ecosystem. But, nowadays, users look at Python. And interfacing Python and Java is not easy. I know some projects that failed to propose an efficient solution on top of Orekit+Rugged for Python.

This year, I decided to learn Rust by myself, and after passing the first learning step, I was impressed. So, naturally, I decided to look at the ecosystem related to Orekit’s features. I quickly identified two challengers:

So, I forged myself the feeling that something is happening with Rust in Space.
Did you experimented Rust for space?

Fun-fact, in Lox we can find a work in progress to wrap Orekit in Rust: Prototype Orekit integration by helgee · Pull Request #250 · lox-space/lox · GitHub
I imagine this could be a good reference to add in the Orekit website when the work will be done.

1 Like
2

Nyx smells really bad:

  • This component is released under GNU Affero GPL v3.0, a strong copyleft license which isn’t business-friendly, but if that were the only “problem”, I wouldn’t make a big deal out of it. It’s the copyright holder’s choice, and I respect that.
  • Nyx is an open core component, with certain “advanced” features reserved for the paid version. You might say that the company has to pay its developers and make a profit. Of course… But for a core component, I find this model frankly problematic and it already puts me off wanting to take an interest in it.
  • Obviously, with such a model, an asymmetric Contributor License Agreement is required, allowing Nyx Space to use third-party contributions in the commercial version that only this company can exploit. For me, asymmetrical CLA are a deal breaker. They destroy all trust and any possibility of constructive collaboration.

In light of these explanations, I invite you to enjoy the beautiful words found on the Nyx Space website, particularly the one in the “Can I use Nyx for commercial purposes?” and “External contributions” sections of the “Pricing” page:

Can I use Nyx for commercial purposes?

Yes, you are free to use Nyx for commercial purposes and to build proprietary software. However, any software that incorporates or depends on Nyx must also provide its source code and give users the freedoms that the AGPLv3 grants with Nyx. […]

The goal of these requirements is to protect user freedoms and encourage collaborative progress. By building on Nyx, your project also gains the benefits and protections of open source. […]

External contributions

We warmly welcome additions and modifications to Nyx! Contributing to open source projects benefits both individual users and the entire astrodynamics community. By building upon Nyx, your work gains the protections and access of the AGPLv3, and in turn contributes to tools available for all. […]

As stipulated by the license agreement, if you contribute code for which you hold a patent, you’re also granting Nyx users the permission to use that patented technology. This openness fuels innovation and ensures we all move forward together in our exploration of the cosmos. Let’s build a better Nyx, and in turn, a better future for astrodynamics!

1 Like
3

Nyx Space also provides GitHub - nyx-space/anise: ANISE provides a toolkit and files for Attitude, Navigation, Instrument, Spacecraft, and Ephemeris data. It's a modern replacement of the NAIF SPICE toolkit. under the MPL… and it is not based on Nyx but Nyx is based on ANISE :sweat_smile:

1 Like
4

I’ve been keeping an eye on satkit GitHub - ssmichael1/satkit: Satellite and Orbital Dynamics Toolkit, which looks interesting.

3 Likes
5

I declared satkit in AeroRust group: Astrodynamics crates - AeroRust (ÄR)

1 Like
6

Author of Nyx and ANISE here. I appreciate the deep dive into the Rust astrodynamics ecosystem. It’s a discussion worth having, and I’d like to offer some context from the maintainer’s perspective. As the Orekit forum mentions when writing a reply, remember that we’re all real people here.

To be transparent: I am the sole contributor to this codebase. Nyx and ANISE respectively represents over eight and four years of independent, unpaid development, supported by neither employers nor external sponsors. Despite this, both have been rigorous enough to be adopted by Rocket Lab, K2 Space, and several other leaders in the industry. Even STK is considering using ANISE. Notably, ANISE was throughout the operations of Firefly Blue Ghost, the first successful US-led lunar lander in 53 years.

The choice of AGPL and open-core isn’t about being “business-unfriendly.” It is a deliberate strategy for sustainability. When a project provides validated, mission-critical math used by billion-dollar entities, the AGPL ensures that the work remains a community asset. It encourages those who benefit from the engine to either contribute their improvements back to the “commons” or help fund the project’s survival through commercial licensing. Importantly, the AGPL still allows corporate entities to use Nyx in their business as long as they don’t distribute the tools built on it to third-parties. That’s how we’ve used Nyx at Rocket Lab, and I’m sure that’s how other companies use it.

Regarding ANISE: It is important to note that this isn’t a wrapper or a port. It is a full, ground-up rewrite of the NASA SPICE toolkit in Rust with Python bindings, offering modern safety guarantees, multi-core computations, and an expanded feature set. For reference, ANISE is over 72,000 lines of code as of today. It provides state of art event finding capabilities (in the analysis module) that run 500x faster than STK’s “Analysis workbench” (the former vector geometry tool). I have purposely released ANISE and foundational crates like hifitime under MPL license. In terms of organization, hifitime is a dependency of ANISE, which itself is a dependency of Nyx. My goal is to let the industry build on these foundational “bricks” without any friction.

I’ve kept the high-level engine (Nyx) under the AGPL to ensure its future. Building a flight-proven suite from scratch requires years of R&D and validation. I’ve chosen a model that balances my commitment to open-source innovation with the practical reality of maintaining a project that the industry trusts for actual flight.

If the AGPL is a dealbreaker for your organization’s specific policies, I am always open to discussing commercial licensing to find a path that works for everyone.

3 Likes