When I first heard about the new project allowing for writing Solana programs using Python, I was quite excited. I thought it was going to be a new Reach for Solana, bringing some new features to the ecosystem. Unfortunately, it turns out Seahorse is just a code generator for the Anchor framework using Python file as an input.
I saw a lot of excitement on Twitter and other social media caused by this project, so I decided to take a closer look about it. Is it any good?
What is Seahorse Lang?
Seahorse is a new way of interacting with Solana. It allows for writing Solana Programs with Python and is compatible with Anchor, the most popular framework in this ecosystem. Of course, Solana Programs are natively written in Rust.
Why would anyone want to build with Python on Solana if Rust is the go-to language? It might have something to do with its popularity. According to the PopularitY of Programming Language Index (PYPL) and TIOBE Index, it’s the most popular programming language in the world that accounts almost for a third of the market in the PYPL index.
Python is known to be simple and easy to learn, which could be the reason why it’s so popular. Rust, on the other hand, is just the 15th most popular, with 1.1% share in the same rankings. It sounds like a good idea to encourage all those Python programmers to build on Solana with a language they already know.
But does it mean they can get away without knowing anything about Rust? Not really.
An important note: Seahorse Lang is described as “beta software, with many features unimplemented and it’s not production-ready.” This hints us that the work is far from over, but we can already review the key concepts.
But what is the safety of Rust? In short, that is:
Type safety
Memory safety
Thread safety (does not apply to Solana programs)
Let’s expand on that a bit in the context of Seahorse.
Type safety
Type annotations are optional in Python, because they make Python code a little bit harder to write. However, they are required in some cases to successfully generate the correct Rust code. In fact, type annotations are required every time they are needed in Rust code. Hence, providing type safety is as easy (hard) as in Rust.
Memory safety
Python is memory safe, so there was no need to introduce any language mechanism to provide it. However, this characteristic makes porting Python to Rust even harder because Python developers must start paying attention to lifetimes, references, and moving. There are no built-in features to handle such cases without messy helper functions.
Is it really that easy?
It looks like writing code successfully translated to Rust requires the same skills and techniques as needed to write Rust code. Maybe it would be easier just to learn a bit about Rust and start coding natively?
Solana has a nice playground (WOW, seahorse is supported as well!), so if one wants to start writing first Solana Programs, he can do it nicely and immidetaly.
Here's what's good about Seahorse
I wanted to find one more serious project using Seahorse and I had found this seahorse swap. Let's forget about all the problems and limitations for a moment and look at the code.
It looks so clean, so simple. You can hardly find anything unnecessary there. Account infos are hidden, surprisingly developers don’t have to be afraid of references and other memory safety features, if the Python code is following Seahorse swap style. The analyzed piece of code is really attractive and I think the Seahorse framework should play such a role. Attract people to Solana and then force them to learn about Solana and Rust, because...
After all, it is easier to write in Rust
Of course, if you are creating a demo, it will work and it will look nice, but let's face it: to be sure that code really works in real world applications, understanding the output is mandatory. Even worse, if a project is successful, a new business case may require unsupported features and then Rust knowledge is needed to extend the framework or time to wait for new construction being supported. Code generators often tend to have a lack of native features.