I started as a Solidity developer.
Now I’m learning the art of blockchain security, one audit and one line of Rust at a time.
I share what I’m learning from @CodeHawks, real audit patterns, and my journey toward mastering Rust, formal verification, and ZK security......
Rust's lifetime elision rules mean most functions with references need zero annotations. The compiler handles the common cases. You only annotate when it genuinely can't tell.
#RustLang#LearningInPublic#Rust
A Rust function can't return a reference to a value it created. That value drops when the function ends. The compiler catches it before runtime. No crash. Just a build error.
#RustLang#LearningInPublic#Rust
Two things Rust taught me today about duplication and equality: Copy = silent bitwise clone. Only for stack types (int, bool, etc.) Clone = you call .clone() yourself. Required for heap types like String.
#Rust#RustLang#LearningInPublic#SystemsProgramming#SmartContracts
The borrow checker's entire job is to enforce that these loans never outlive the thing they borrow from, and that mutable loans are never concurrent with any other loan
#RustLang#Rust#LearningInPublic
In Rust, every value has exactly one owner at any moment. When that owner goes out of scope, the value is dropped. Borrowing is a temporary, scoped loan of access to a value. it does not transfer ownership.
#RustLang#Rust#LearningInPublic
Rust won't let you print a custom struct until you implement Display yourself. Debug you can derive. Drop runs on scope exit and you can customize it too. Explicit over magic.
#RustLang#LearningInPublic#Rust
🦀 Rust: Patterns & Engineering How-Tos
A practical guide from Microsoft on the patterns you actually need in production:
• type-state & newtypes
• PhantomData
• channels & concurrency
• async pitfalls
• testing with proptest
https://t.co/bK3mqnxL1I
#rust#rustlang
FFmpeg is moving to Rust 🦀
Our use of C and Assembly in FFmpeg has been an unacceptable violation of safety.
FFmpeg will be running 10x slower - but we're doing it for your safety.
All your videos will appear green - safety first, working software later.
Wasabi Protocol lost $5.9M in under 3 minutes. No bug. No exploit. Just one stolen private key and zero guardrails.
wrote a full breakdown of what went wrong and the six countermeasures that would have stopped it cold. Every single one of them is free and open source.
Link below
I'm a Solidity dev and Rust kept showing up everywhere I looked.
Foundry. Reth. Solana. NEAR. ZK proof systems.
So I'm documenting the whole journey from zero.
Articles. Written by someone learning it live.
Article 01 is up
https://t.co/zE7TjZO9Ef
#Rust#Solidity#Web3
Rust Learning Log: Glob Imports, Library Crates, Multiple Binaries
Today I learned about the glob operator, creating a library crate, and multiple binary crates
The Glob Operator:
The glob operator (*) lets you import everything from a module at once.
At first, it felt strong. Almost too powerful.
Up until now, Rust has been teaching me to be explicit, to name exactly what I'm bringing into scope. The glob operator relaxes that slightly.
That contrast made me think. Rust gives you convenience, but it also gives you responsibility.
Even as a learner, I can see how using a glob import might make code shorter but potentially less clear. It made me more aware of how imports shape readability.
Creating a Library Crate:
Learning how to create a library crate changed how I view Rust projects.
Before this, everything I built felt like "a program." Now I see that Rust encourages you to build reusable logic, code meant to be consumed by other parts of the project or even other projects.
A library crate feels like saying: this code is meant to be depended on.
That shift in perspective, from writing code for execution to writing code for reuse, feels like a major step in maturity.
Multiple Binary Crates:
This one surprised me. A single project can have multiple binary crates, meaning multiple entry points.
That made me realize Rust doesn't assume your project is a single purpose tool. You can structure a project to serve different commands, roles, or execution flows while sharing the same core logic.
It made everything I've learned about modules and visibility suddenly make more sense. Structure supports scale.
Some languages can have multiple main packages in a project, but they need to be in separate directories. Rust's approach with multiple binaries in the same workspace feels similar but more integrated.
At this point, I'm starting to see Rust in layers.
Ownership taught me about memory discipline. Enums taught me about modeling uncertainty. Modules taught me about structure. Visibility taught me about boundaries.
Crates and binaries are teaching me about architecture.
Rust doesn't just teach me how to code. It teaches me how to design systems.
I'm still learning and still early, I will get a clearer picture soon.
When you're building projects, do you start thinking about reusability and architecture upfront, or do you refactor toward it once things get complex?
#Rust #RustLang #LearningRust #Programming #SoftwareEngineering #SoftwareArchitecture #CodeOrganization #LibraryDesign #Documentation #Blockchain #Solidity #SystemsDesign #CleanCode
Rust Learning Log: Names, Boundaries, and How Rust Scales
Over the last few days, I've been learning how Rust organizes code: modules, paths, visibility, and navigation.
Rust keeps large codebases readable, intentional, and composable as they grow.
Everything still builds on the same theme: clarity over convenience.
Creating Aliases With 'as':
Sometimes a name is technically correct but not ergonomic. Instead of forcing you to live with awkward names, Rust lets you rename things locally.
This doesn't change the original item. It just improves how you interact with it.
That feels very Rust. No global side effects. No hidden behavior. Just explicit, scoped clarity.
It made me think more carefully about how naming affects readability.
pub use for Clean Public APIs:
Using pub use to re-export names from submodules was a big one for me.
Instead of exposing your internal structure directly, Rust lets you shape how others see your code.
Internally, things can be deeply nested. Externally, you can present a clean, intentional interface.
In Solidity, you typically expose what's public in a contract, and the structure you choose internally is what users interact with. There's not as much flexibility to reshape the public interface separately. Rust gives you more control with pub use to hide implementation details while keeping the API simple.
Even as a learner, I can see how this would matter in larger systems.
External Crates:
Instead of reinventing everything, Rust encourages reuse, but in a controlled, explicit way. You don't accidentally depend on something. You choose it.
That explicitness around dependencies feels especially important for reliability and security focused work.
Dependency management can get messy with transitive dependencies and version conflicts in some languages. Rust's Cargo handles this more deliberately, and you always declare what you're using in Cargo.toml.
The Standard Library:
Learning about the standard library was interesting because of what it isn't.
It's not massive. It's not trying to do everything.
Instead, it provides carefully chosen building blocks: types and tools that align tightly with Rust's core philosophy.
That restraint feels like Rust wants you to understand fundamentals deeply, rather than rely on abstractions that hide complexity.
As I move deeper into modules and crates, I'm starting to see Rust as a language obsessed with boundaries.
Boundaries between modules, between public and private, between internal structure and public API, between your code and external dependencies.
Every tool I learned today exists to help manage those boundaries cleanly: as for local clarity, pub use for API design, external crates for controlled reuse, and a focused standard library that doesn't try to do everything.
Rust is slowly teaching me how large, maintainable systems are designed, not just how code compiles.
In the codebases you work with, how much thought goes into API design versus just making things work? Do you reshape interfaces later, or plan them upfront?
#Rust #RustLang #LearningRust #SystemsDesign #Blockchain #Solidity #SoftwareArchitecture
Rust Learning Log: Paths, Context, and Navigating the Module Tree
The past days, I've been learning how Rust structures code using modules.
Today, I learned how Rust lets you navigate that structure. Not by guessing, but by being explicit about where things live and how you refer to them.
This lesson felt more about understanding how to move around a codebase.
The crate Prefix
Learning about the c:rate prefix helped me understand something basic but important: every path has a starting point.
Using crate makes it clear you're referring to something from the root of the current crate, not from the current module or a parent module.
That explicit starting point removes ambiguity. It answers: from where am I navigating this codebase?
Once I saw it that way, module paths made more sense.
The use Keyword:
The use keyword was interesting because it doesn't introduce new behavior. It just changes how readable your code is.
Instead of repeating long paths everywhere, use lets me bring a path into scope.
Rust doesn't do this automatically. You opt into the convenience consciously.
In Solidity, you use import to bring in contracts and libraries, and it's pretty flexible. You can import specific items or entire files. Rust's use feels similar, but it's more about managing paths within your own crate than importing external code.
Name Conflicts:
Learning about name conflicts made me realize why Rust is strict about paths.
If two things have the same name, Rust doesn't guess which one you meant. You're forced to be clear.
Instead of hiding complexity, Rust exposes it early, where mistakes are cheaper to fix.
In some languages, naming conflicts can cause subtle bugs because of scope hoisting and global pollution. Rust's module system makes you handle conflicts explicitly.
The self Keyword:
The self keyword helped me understand how Rust refers to the current module.
Rather than hard coding full paths, self lets you say: from where I am right now.
It's a small keyword, but it reinforces something important. Context matters. You're always somewhere in the module tree, and Rust gives you precise tools to move from that point.
The super Keyword:
Finally, learning super completed the picture.
If self is "here", then super is "one level above". It lets a module reach upward without breaking structure or clarity.
What I liked most is how limited and intentional this is. You can move up, but not in a messy or uncontrolled way. It keeps the hierarchy meaningful.
Today's lesson was about navigating structure safely.
Between crate, use, self, and super, Rust gives a clear map of the codebase and makes sure you always know where you are.
Just like ownership controls access to memory, these tools control access to names and functionality.
How do you navigate large codebases in the languages you work with? Do you rely on IDE tools, or do you find yourself using the language's path/import system directly?
#Rust #RustLang #LearningRust #Blockchain #Solidity
Rust Learning Log: Modules as Files, Folders, Visibility, and Submodules
Yesterday I was learning what modules are. Today I learned how they actually work inside a Rust project.
This felt like moving from concept to structure. From understanding modules to understanding how Rust expects code to be organized.
Modules as Files:
Learning that a module can live in its own file made things better.
A module isn't just a conceptual boundary anymore. It becomes a real, named place in the project. Another angle for ownership and responsibility.
Instead of everything being piled together, you start asking: does this logic deserve its own space?
In Solidity, you can split contracts across files using import, but the structure is more flexible. You can organize however you want. Rust has conventions that guide you toward clearer organization from the start.
Modules as Folders:
Learning about modules as folders made the organizational story even clearer.
Folders let related modules live together. Not randomly, but intentionally. Structure reflects meaning. This prevents chaotic codebases as projects grow.
Module Ambiguity:
Module ambiguity was one of the more interesting ideas today.
When multiple modules can contain items with the same name, context becomes critical. Rust doesn't guess. It forces you to be clear.
I've consistently learnt that ambiguity is risky. Explicit structure reduces mistakes.
It made me more aware of naming and layout, and how easily confusion can come in without clear boundaries.
Public Enums, Structs, and Fields:
Learning how enums, structs, and even individual fields can be marked pub was exciting.
Rust doesn't treat visibility as all or nothing. You can be precise about what's exposed.
That precision makes you think like an API designer. What should others rely on? What should stay internal? What am I comfortable exposing long term?
Submodules:
Submodules tied everything together.
Instead of flat structures, Rust encourages hierarchies with meaning. Each level adds context, not confusion.
What stood out is how deliberate this feels. Nothing is automatic. Nothing is hidden. You build structure step by step, and every decision is visible.
I read somewhere that in C, large projects can become hard to navigate because there's no enforced module system. Rust gives you tools to structure things clearly from the beginning.
Modules aren't just about organizing files. They're about designing boundaries.
Just like ownership controls access to memory, modules control access to functionality.
Rust keeps giving me the same ideas in different forms: be explicit, reduce ambiguity, design with intent.
This part of Rust made me think less like someone writing code and more like someone designing a system, and I love it.
How do you decide when to split code into separate files or modules? Do you do it early, or wait until things get messy?
#Rust #RustLang #LearningRust #Programming #CodeOrganization #SystemsDesign #Blockchain #Solidity
Rust Learning Log: Packages, Crates, Modules, and Why Namespaces Matter
After working through ownership, enums, Option, Result, and vectors, today's learning shifted to something different. Instead of writing logic, I was learning how Rust thinks about organizing code.
This felt like stepping back to look at the bigger picture.
Packages and Crates:
One thing that stood out right away is how early Rust introduces structure.
A crate is the smallest unit Rust compiles. A package is how related crates are grouped together.
Even at this early stage, it signals something: Rust doesn't want large, unstructured codebases. It makes you think about boundaries from the start.
What belongs together, what doesn't, how things should be grouped.
Coming from Solidity, I organize code using contracts, interfaces, and libraries, but there's no enforced project structure. I can put everything in one file and it'll compile fine. Rust starts nudging me toward structure before I even write much logic.
Introduction to Modules:
Learning about modules made things feel more intentional.
Modules aren't just about splitting files. They're about grouping related functionality under a clear name. Instead of having everything at the same level, you're saying: these things belong together.
That alone makes code easier to read and reason about, even before thinking about visibility or scale.
The pub Keyword:
The pub keyword really caught my attention.
By default in Rust, everything is private. You have to explicitly mark something as public to expose it.
That design choice feels intended. Instead of exposing everything automatically, Rust makes you ask: what should be accessible? What should stay internal? What am I committing to as part of my interface?
In Solidity, function visibility is also something you declare explicitly (public, private, internal, external). So this felt familiar, but Rust applies it to everything, not just functions.
Namespaces:
Namespaces seemed abstract at first, but the benefit clicked quickly.
By placing code inside modules, names stop colliding. Each item has a clear context. Instead of vague or overloaded names floating around, you know exactly where something comes from.
Some languages do not have real namespaces, which can lead to naming conflicts in large projects. Rust gives you modules to solve that problem cleanly.
Today wasn't about writing more logic. It was about understanding how Rust expects code to be structured, scoped, and protected.
Just like ownership and enums, the structure isn't strict for no reason. It's pushing you toward intentional organization, clear public APIs, and fewer accidental dependencies.
I'm still learning modules and crates, but it's connecting to everything I've learned so far.
How do you think about organizing code in the languages you use? Do you wait until the project gets big, or do you structure things from the start?
#Rust #RustLang #LearningRust #Blockchain #Solidity #SystemsProgramming