Doc: Solidity VS Rust Syntax Comparison

[Raad05]

What

Adds a new cheat sheet that compares Solidity and Rust smart contract syntax and patterns side by side.

Why

• Gives readers a quick reference for translating common concepts between EVM and Solana development.
• Helps developers moving between Solidity and Rust understand equivalent types, functions, error handling, logging, and storage patterns.

How

• Organizes the guide into sections for types, functions, error handling, events and logs, storage patterns, common operations, and deploy/test commands.
• Uses comparison tables and code examples to show equivalent constructs in both languages.

Checklist

• Tests pass locally
• No unrelated changes included
• Documentation updated (if applicable)

[PetarStoev02]

Hey @Raad05, nice initiative — a Solidity vs Rust cheatsheet is a great addition and aligns with issue #33. The structure and formatting are solid. However, there are several technical inaccuracies on the Rust/Solana side that need to be fixed before we can merge.

🔴 Must Fix

1. "CRATES (Anchor) or ASDROP" in the Deployment Differences table is incorrect — These are not real terms in the Solana ecosystem. Solana programs are upgraded via the built-in BPF Loader Upgradeable using an upgrade authority. With Anchor it's anchor upgrade. Replace with something like "Native upgrade authority (BPF Loader Upgradeable)".

2. Rust examples inconsistently mix raw Solana and Anchor without labeling — The Functions section uses raw Solana (program_id, accounts, instruction_data), then Error Handling switches to Anchor (ctx: Context<Transfer>, require!). Pick one consistently (Anchor is more common) or clearly label each example as "Native Solana" vs "Anchor".

3. HashMap as equivalent to Solidity mapping is misleading — Solana programs don't use HashMap for on-chain storage. The equivalent of a Solidity mapping is Program Derived Addresses (PDAs) — each "entry" is its own account derived from seeds. The HashMap example would only work in-memory during a single instruction, not as persistent storage.

4. require! macro used in a raw Solana example — In the Functions section, require!(from.is_signer, ...) is shown in a raw Solana program. require! is Anchor-only and won't compile without it. For native Solana, use:

   if !from.is_signer {
       return Err(ProgramError::MissingRequiredSignature);
   }

5. try_borrow_mut_data() is misleading as a "balance" — The variables are named from_balance and to_balance, but try_borrow_mut_data() returns raw bytes (&mut [u8]), not a balance. For SOL transfers, use try_borrow_mut_lamports():

   **from.try_borrow_mut_lamports()? -= amount;
   **to.try_borrow_mut_lamports()? += amount;

🟡 Should Fix

6. Typo: "Comparision" → "Comparison" — In both the PR title and commit message (the file heading is correct).
7. Anchor test example is non-standard — The Rust #[tokio::test] with anchor_client::Client pattern shown is not how Anchor tests are typically written. Default Anchor tests use TypeScript with Mocha. Either show the standard TS test or use a modern Rust testing approach (LiteSVM/Mollusk).
8. "Annual rent" is outdated — Solana moved to rent-exempt-only (SIMD-84). Rent collection is disabled. It's a one-time refundable storage deposit, not an annual fee. Update the Storage Cost table accordingly.
9. Link to issue #33 — This PR is part of the cheat sheets effort, should reference it.
10. 2 resource URLs are outdated and redirect:
    • https://docs.solana.com/ → should be https://solana.com/docs
    • https://spl.solana.com/token → should be https://www.solana-program.com/docs/token
11. Resources are too generic — They all link to homepages. Consider linking to specific relevant pages like solana.com/docs/core/accounts, anchor-lang.com/docs/features/errors, solana.com/docs/programs/deploying, etc.

🟢 Nice to Have

• SBPF (eBPF) — SBPF is a fork of eBPF, not eBPF itself. Consider "SBF (eBPF-derived)" to be more precise.
• Add a note at the top of the file clarifying whether Rust examples target Anchor or native Solana.

The Solidity side of the cheatsheet looks accurate and well-structured. Once the Rust/Solana side is corrected this will be a great resource 👍

[Raad05]

Hey @Raad05, nice initiative — a Solidity vs Rust cheatsheet is a great addition and aligns with issue #33. The structure and formatting are solid. However, there are several technical inaccuracies on the Rust/Solana side that need to be fixed before we can merge.

🔴 Must Fix

1. "CRATES (Anchor) or ASDROP" in the Deployment Differences table is incorrect — These are not real terms in the Solana ecosystem. Solana programs are upgraded via the built-in BPF Loader Upgradeable using an upgrade authority. With Anchor it's anchor upgrade. Replace with something like "Native upgrade authority (BPF Loader Upgradeable)".
2. Rust examples inconsistently mix raw Solana and Anchor without labeling — The Functions section uses raw Solana (program_id, accounts, instruction_data), then Error Handling switches to Anchor (ctx: Context<Transfer>, require!). Pick one consistently (Anchor is more common) or clearly label each example as "Native Solana" vs "Anchor".
3. HashMap as equivalent to Solidity mapping is misleading — Solana programs don't use HashMap for on-chain storage. The equivalent of a Solidity mapping is Program Derived Addresses (PDAs) — each "entry" is its own account derived from seeds. The HashMap example would only work in-memory during a single instruction, not as persistent storage.
4. require! macro used in a raw Solana example — In the Functions section, require!(from.is_signer, ...) is shown in a raw Solana program. require! is Anchor-only and won't compile without it. For native Solana, use:

   if !from.is_signer {
       return Err(ProgramError::MissingRequiredSignature);
   }

5. try_borrow_mut_data() is misleading as a "balance" — The variables are named from_balance and to_balance, but try_borrow_mut_data() returns raw bytes (&mut [u8]), not a balance. For SOL transfers, use try_borrow_mut_lamports():

   **from.try_borrow_mut_lamports()? -= amount;
   **to.try_borrow_mut_lamports()? += amount;

🟡 Should Fix

6. Typo: "Comparision" → "Comparison" — In both the PR title and commit message (the file heading is correct).

7. Anchor test example is non-standard — The Rust #[tokio::test] with anchor_client::Client pattern shown is not how Anchor tests are typically written. Default Anchor tests use TypeScript with Mocha. Either show the standard TS test or use a modern Rust testing approach (LiteSVM/Mollusk).

8. "Annual rent" is outdated — Solana moved to rent-exempt-only (SIMD-84). Rent collection is disabled. It's a one-time refundable storage deposit, not an annual fee. Update the Storage Cost table accordingly.

9. Link to issue Content: Cheat sheets (RPC methods, token standards) #33 — This PR is part of the cheat sheets effort, should reference it.

10. 2 resource URLs are outdated and redirect:

    • https://docs.solana.com/ → should be https://solana.com/docs
    • https://spl.solana.com/token → should be https://www.solana-program.com/docs/token

11. Resources are too generic — They all link to homepages. Consider linking to specific relevant pages like solana.com/docs/core/accounts, anchor-lang.com/docs/features/errors, solana.com/docs/programs/deploying, etc.

🟢 Nice to Have

• SBPF (eBPF) — SBPF is a fork of eBPF, not eBPF itself. Consider "SBF (eBPF-derived)" to be more precise.
• Add a note at the top of the file clarifying whether Rust examples target Anchor or native Solana.

The Solidity side of the cheatsheet looks accurate and well-structured. Once the Rust/Solana side is corrected this will be a great resource 👍

Hey @PetarStoev02 , I have updated the cheat sheet. Waiting for your review!

[PetarStoev02]

Hey @Raad05, great job on the updates — you addressed almost everything from the first review. I pushed a small fixup commit for the remaining issues in the Common Operations section (require! string literals → error codes, load()/load_mut() → direct field access, and SPL token transfer → CPI pattern).

This is ready to merge now. Solid cheatsheet, thanks for the contribution! 🤝

Feel free to pick up another issue from the repo if you're interested — there's more cheatsheets and guides to work on.