Featured image of post Why do I program Solana in plain Rust and not with Anchor

Why do I program Solana in plain Rust and not with Anchor

No, programming Solana in plain Rust is NOT unsafe.

Solana Vectors by Vecteezy

Thanks for reading, my name is Sergio Flores and I’m the Lead Consultant at SAFT.Industries, where I help entrepreneurs and business managers to execute their vision by enabling the technology to support it.

Today I’d like to talk to you about some of my views on Solana programming, specifically on whether to use Anchor or not, and why.

First of all, what is Anchor? And how does it relates to Solana?

So, Solana is a blockchain. For those of you not very connected with the blockchain world, there are several blockchains like Bitcoin, with Ethereum being the most famous, but there are many others with differing approaches to the technical solution of enabling a distributed ledger. Now, Solana uses a VM to execute programs on its nodes, and these programs can be written, in principle, in any language that can target the underlying VM. Somewhat like Java, I guess, where the JVM can be targetd by Kotlin or Scala. But, in Solana, the original deployed language was Rust. Rust is a modern language, with capabilities similar to C++, but more recent concepts.

Now, for the purposes of 3rd parties programming on chain, on Solana, its maintainers publish only the basic tools, like a minimum SDK, or libraries, and you can just use these libraries, and maybe some other publicly available ones to solve specific problems that you might need, and that’s it. This is what we could call “programming in plain Rust”, and while it is very doable for an experienced programmer, it is not very approachable for newbies, and it can be hard, and it requires a lot of boilerplate code, and of course, a fairly good understanding of how everything works.

Enter Anchor. Anchor is a framework, we could say “an organized way of doing things” already coded into a library, that you can use to create your Solana programs, with a ready made structure for you, and common best practices already included. Furthermore, its main advantage lies in helping newcomers to become productive quickly without needing such a deep understanding of the underlying platform.

All’s well and good, and?

Well, Anchor does work, and I do recommend it for some projects. At the time of this writing, there are also competitors to it, both at the framwork level, and at the language level, with projects promoting the use of Python or TS to program in Solana. To each its own. I subscribe to the philosophy of “Freedom of choice in technology”, which means that you should be able to freely decide on the tech tool you want to use to solve the problem at hand. However, there are some considerations to using Anchor or not, and the decision is more nuanced and not as clear cut as you might think:

  1. No, using plain Rust in Solana is NOT unsafe. This is a myth. Solana does not have the same problems that Ethereum has and people that come from the Ethereum world are just wired to think that it is this way everywhere. For example, “Reentrancy”. The capability of Ethereum programs to run the same function, before the previous run has finished, potentially producing weird side effects, is non-existent in Solana. Solana has guaranteed serialization execution for operations that change the same data. So, basically, as far as safety goes, you do need to know what you are doing, and there are some things that you need to watch out for (say, that data accounts are used only in the operation they are supposed to, hence a “discriminator” is used to differentiate them, and other similar details) but you can learn this, and you should, and once you do, it is very straightforward. Anchor does include these protections, some automatically, some you have to request, but the point I’m trying to make, is that the idea that if you do not use Anchor you are automatically exposing yourself to risk is simply not true. You will expose yourself to risk if you do not know what you are supposed to do. The differentiator is knowledge; not the presence of the framework.

  2. Anchor makes Solana development more accesible for newcomers. Or at least that’s the idea behind it. And it does make it easier, for some time. I do feel it introduces Rust language elements that you might do without in Solana development, and it also conceptually complicates matters down the line. Specifically, when there is an error, and you need to track the bug down, Anchor can be a more difficult to work with. Programming in plain Rust means that you have to deal with the underlysing Solana structure, which is VERY DIFFERENT from what you might be accostumed elsewhere, and Anchor hides this from you. Case in point: Solana does not have multiple functions. There is only 1 function, and the only parameter it has, is an undifferentiated byte array. Yet Anchor makes it look like Solana has multiple functions and these functions can accept normal programming parameters such as integers, or floats or whatever.

    So, what’s wrong with that? Well, it depends on how much you know of how things actually work. If you do need the layer of abstraction, ok, but if you don’t need it, it feels like an unnecesary restriction, where you could instead be free to define your inputs in the exact byte-way that you want. Some people are scared of byte manipulation. To them, I would tell they just need to study more, that’s all.

  3. Anchor produces big executables. May or may not be an issue, but it is a fact, because when you include its libraries, it comes with everything, whether you need it or not, and comes with a lot of programming logic to abstract things away from you. In my own tests, the difference comes to 5x. A plain Rust program might use 100kb of space, while the same functionality in Anchor might need 500Kb. Note however, that the code you do see in Anchor appears to be small, that is because you are doing function calls, and the real code is hiden in the library behind, and included in your project. So your plain Rust code might look bigger, when in fact, it’s smaller. Although it is verbose.

  4. Using copy-paste fragments of code instead of public libraries helps to defend from supply-chain attacks. This happened to Hardhat once, it happened to web3.js. Nobody is immune, but we can reduce the risk, and the exposure. A supply-chain attack happens when the code of a public repository gets compromised, and your own code depends on it, so you update it, and unknowingly ship to your users the compromised code. So the strategy to defend from this, is to limit your external dependencies as much as humanly possible, and one way of doing that is coding in plain Rust. That doesn’t mean that you have to reinvent the wheel for every project. Solana needs a lot of boiler-plate code that you can just use as a template.

  5. solana-program is very stable and generally you do not need to update it frequently. It is a mandatory dependency for all Solana programs though. Anchor tends to have more breaking changes and updates may be more involved.

  6. Less technical people are scared of breaking things. A normal fear, and that is why you hire experts to handle stuff for you. I’m also scared of performing a surgery…which is why I pay a doctor to do it when needed. That said, you can and you should study Solana plain Rust programming if you feel inclined to; it can be learnt obviously.

  7. In plain Rust, you have full control. Which is always useful, especially when you need to do optimizations, like when the stack blows up, when you are exceeding your compute budget, when you need to reduce the storage size of your data accounts because you are paying their rent and every byte counts for your 100,000+ users, etc. It is similar to the question of should I use C++ or Java for my Windows program? The answer is: it depends, each has its pros and cons, and it also depends on your skills, and interests.

Well, I think that’s a good primer on the topic. One final consideration that I’d like to mention, is that ultimately, the choice of tools depends on the project and situation; such a thing as an “universal solution” does not exist, and so, a qualified individual must make the call when approaching a particular problem.

Thanks for reading, and wishing you a very successful 2025!


Are you interested in learning more about this process or explore how could it be applied to your particular needs? Please send us a message using the form below, for a no-commitment, exploratory talk about your problem.

https://saft.industries - The future is what we make of it
Built with Hugo
Theme Stack designed by Jimmy