Learning Solana as a Seasoned Ethereum Developer (Part 2)
Gather round the campfire as I regale you with part 2 of my series about learning Solana with many years of Ethereum development under my belt.
In Part 1 we had a high-level discussion about the rationale behind upskilling in Solana, the difference between the two ecosystems as a new dev, and some first impressions (both good and bad). I didn’t get too deep into anything technical, and it was really intended as a jumping off point
In this article, I’ll discuss the dev environment in more detail and some things that feel different when coming from the Ethereum perspective. The purpose of these articles is to give Eth devs an idea of what to expect if they’re considering making the jump.
Local Setup
There are a few options when it comes to Eth dev tools and environment, but for me I like to use Ganache for my local chain when doing frontend stuff and Hardhat for my dev framework. Any machine with nodejs installed can get these up in no time, and then I can dive straight into the contract code.
I mention my specific setup because my experiences with Solana will naturally be compared to it.
From the solana.com getting started page, the Solana dev environment has a couple more dependencies, but all are pretty simple to install too.
Rust, Solana CLI and Anchor CLI, as well as NodeJS and Yarn which you may already have installed. There’s a few extra steps if you’re on Windows, but blindly following the instructions here should at least get your dev environment up and running.
Networks
The first thing that stood out to me is the choice of different networks (or lack thereof!). In Eth we are generally accustomed to being able to arbitrarily hook up any network to whatever we are working with as long as we have the RPC url. This includes various L2s, testnets, or even multiple instances of our local chain.
Everything in the Solana ecosystem seems to be built around only their Mainnet, the two testnets, and occasionally a single instance of a local network, without the expectation that anything else is possible. In practice for me this doesn’t really matter, as I’m not intending on building an L2 and the only projects I’ve needed multiple Ganache instances for was when I was developing multi-chain stuff, but it was a bit of a shift in perspective to something that felt a bit on-rails.
There are a few other little quirks of the Solana CLI which felt slightly off in the same way that browsing a supermarket in a foreign country can be slightly uncanny, but overall you get used to it pretty quick.
I will say that getting testnet SOL is a breath of fresh air after the hoops required to get any sort of EVM testnet ETH. For the latter you usually need to have some sort of Mainnet balance and create some sort of account/make a social media post just to use a faucet. There may be reasons for this but its just an extra frustrating hurdle especially for those of us who keep our dev accounts and our real accounts well separated.
To get SOL on a testnet, you just point the CLI at the network you want to use, then type solana airdrop X (where X is the amount you want). So much simpler.
Accounts
One of the biggest brain stretches you are going to need to do moving from Eth to Solana is around accounts. I could probably write a whole article about the differences in the way accounts and data are managed between the two and the impacts that has on design considerations, but I think for this article we can cover most of the technical differences.
Firstly, to an extent, everything is an account. There is of course the normal relationship between private keys and accounts that you are familiar with. However, it gets a little weird because accounts with keys can also hold data or smart contract (program) code.
In ETH, when you deploy a contract, the address of the deployed contract is either derived from the deployer address or deterministically derived from certain parameters. In Solana, you actually generate a private key and deploy the contract to the address associated with that private key. Perhaps even stranger is that you can change code that has already been deployed, (the holy grail of the smart contract dev who doesn’t unit test properly!).
There is much more to be said on accounts but I will save this for a future article as this one is just supposed to be about the differences in dev environments. But like everything, this is something you get used to.
Rust
Of course, in an article about the Solana dev environment, we need to at least mention Rust. You are most likely aware that unlike Eth smart contracts, Solana programs are written in Rust (or C apparently, but I have no experience with the latter). I don’t really consider myself an expert in evaluating the pros and cons of one language vs another, and beyond the natural biases of preferring a language I have close to a decade of experience working with, Rust was pretty easy to adapt to.
I did find certain restrictions around naming with regard to case-systems a little annoying to deal with, however I’m not actually sure if this is a constraint of Rust or just my compiler settings. But there are a lot of Rust fans out there, and I’m sure they exist for a reason.
I should note that when initially coming to Solana dev, I briefly looked into Solang, a compiler that lets you write programs in Solidity and converts them to Rust, but given that it still compiles down to Rust, everything else in the ecosystem is Rust-based, and even the rest of your stack will be biased towards Rust-based programs unless you really wanna customise it, it seemed like just upskilling in Rust was the move. To be honest, I don’t regret it.
Anchor
The last big-picture part of the environment that needs to be mentioned is Anchor. To a certain extent, Anchor is analogous to Hardhat. It gives you a nice little framework to write, compile and test programs easily. However, unlike Hardhat, it also adds additional functionality within your Rust programs, as well as giving us the Solana equivalent of the ABI (the IDL).
I’m not actually sure what Solana dev would look like without Anchor, so I can’t say for sure how much heavy lifting it has done, but it seems like it’s doing some critical work.
I mentioned in the previous article that when I first started Solidity dev, nothing like this existed. In a time before Hardhat and Truffle we kinda had to hack our own stuff together, and despite giving a baptism by fire which forced you to have a little more familiarity with things like the Solidity compiler you were using, it was really more of a barrier to development than a blessing.
So Anchor is definitely a testament to the more well developed sides of the Solana dev ecosystem. There are some concerning issues regarding tests and the local test network, but we won’t be touching that today.
Front-end
I won’t go into too much detail on this now, but one thing that I found very lacking was the ecosystem regarding the frontend of our programs. As a full-stack web3 dev, I can’t just write nice contract code and then sling it off to some other dev and hope it comes out okay, it’s important that from top-to-bottom everything comes together. I don’t even like web dev, but a job worth doing is worth doing well.
That’s why it was disappointing to see how React-centric some of the Solana frontend dev ecosystem is. I will probably say this many times in this series, but React is a terrible framework to use for web3 projects. Yes, it’s basically too-big-to-fail at this point, but please do yourself a favour and use something like Svelte. Do not make the first decision you make (ie picking a framework) be the one that saddles you with the most unappreciated tech debt for your project.
We will litigate this further in a future article, but every time I see someone fighting against their own code to make a web3 project work “well” in React I die a little inside.
Next Steps
If I have piqued your interest thus far, I’d probably direct you to the quick-start page of the Solana.com docs. If you have a conscious or implicit Eth dev preference you may have to push through a few moments of “WTF? This is dumb.” but I’d say it’s worth indulging your curiosity.
I’m not sure exactly what the next article in this series will focus on, but the next logical step feels like digging into some actual code and design pattern differences.
I guess you’ll have to stay tuned to find out.
