DEV Community: Syam SV

Rust for Gophers, Lesson 3: Structs, Enums, and Match

Syam SV — Wed, 28 Oct 2026 17:21:49 +0000

1. Structs

Rust structs look like Go structs, with three differences that matter: there are no zero values, there is no embedding, and behaviour like printing or comparing is opted into with derive.

#[derive(Debug, Clone, PartialEq)]
struct User {
    name: String,        // owned: the struct owns its data (Lesson 2)
    email: String,
    active: bool,
    login_count: u64,
}

let u = User {
    name: String::from("syam"),
    email: String::from("s@x.dev"),
    active: true,
    login_count: 0,       // every field must be set; no implicit zero values
};

let u2 = User {
    name: String::from("ana"),
    ..u.clone()           // struct update syntax: take the remaining fields from another value
};

No zero values. Go silently fills omitted fields with 0, "" or nil. Rust makes you write every field, so adding a field to a struct turns every construction site into a compile error until you handle it. That's a refactoring safety net. When you do want defaults, opt in:

#[derive(Debug, Default)]
struct Config {
    port: u16,
    verbose: bool,
    name: String,
}

let c = Config { port: 3000, ..Default::default() };  // the rest is 0 / false / ""

Struct fields are almost always owned types (String, Vec<T>), not references. A struct holding &str needs a lifetime annotation and can't outlive the data it borrows. That's sometimes right (Lesson 8), but owned fields are the default choice.

Tuple structs and the newtype pattern

#[derive(Debug, Clone, Copy, PartialEq, PartialOrd)]
struct Meters(f64);

let d = Meters(3.0);
let raw = d.0;         // fields are accessed by position

Wrapping a primitive in a one-field struct is called a newtype. It costs nothing at runtime, but Meters and Feet (or UserId and OrderId) become different types the compiler won't mix up. Go's type UserID int64 is similar, but Go converts between them freely with UserID(x). Industry Rust uses newtypes heavily for IDs and validated values.

`derive`: opting in to behaviour

Derive	Gives you	Go equivalent
`Debug`	`{:?}` printing	`%v` / `%+v` (automatic in Go)
`Clone`	`.clone()` deep copy	Manual copying
`Copy`	Implicit bitwise copy; only if every field is `Copy`	Value semantics for small structs
`PartialEq`, `Eq`	`==` and `!=`	`==` on comparable structs
`PartialOrd`, `Ord`	`<`, `>`, sorting	No built-in equivalent
`Hash`	Usable as a `HashMap` key	Map keys must be comparable
`Default`	`T::default()`	Zero values

A good habit is to derive Debug on every type, and Clone/PartialEq when they make sense. Copy is only for small, plain-data types; never derive it on something that owns heap memory (the compiler won't let you anyway).

2. `impl` blocks: methods and constructors

Methods live in an impl block separate from the struct definition, much like Go's func (u *User) ... methods live outside the type declaration. The difference is the receiver: Go has two kinds (value and pointer), Rust has three, and they are exactly the three ownership modes from Lesson 2.

impl User {
    // Associated function (no self): Rust's constructor convention, like Go's NewUser
    fn new(name: &str, email: &str) -> Self {
        Self {
            name: name.to_string(),
            email: email.to_string(),
            active: true,
            login_count: 0,
        }
    }

    fn display_name(&self) -> &str {   // borrows self read-only
        &self.name
    }

    fn record_login(&mut self) {       // borrows self exclusively, may modify
        self.login_count += 1;
    }

    fn into_email(self) -> String {    // takes ownership; u is unusable afterwards
        self.email
    }
}

let mut u = User::new("syam", "s@x.dev");   // :: calls an associated function
u.record_login();                            // . calls a method; &mut u is taken automatically
let email = u.into_email();                  // u is moved here

Receiver	Go equivalent	Use when
`&self`	`func (u User)` or `func (u *User)` that only reads	Getters, computations. Most methods
`&mut self`	`func (u *User)` that writes	Changing state
`self`	No equivalent	Consuming or converting: `into_*` methods, builders

Naming conventions you will see everywhere: new for the main constructor, with_* for alternatives (Vec::with_capacity), as_* for cheap borrowed views (as_str), to_* for expensive conversions that allocate (to_string), and into_* for conversions that consume self. Getters are named after the field (name()), never get_name().

Self (capital S) is an alias for the type the impl is for. Use it in constructors and return types so renaming the type later only touches one line.

The method call u.record_login() is sugar for User::record_login(&mut u). Rust auto-borrows the receiver, which is why you never write (&mut u).record_login(). Go does the same thing when it takes &u for pointer-receiver methods.

3. Enums: the feature Go doesn't have

A Rust enum is a sum type: a value that is exactly one of several variants, where each variant can carry its own data. This is the single feature Go programmers miss most once they've used it.

The simple case looks like Go's iota constants:

#[derive(Debug, Clone, Copy, PartialEq, Eq)]
enum Status {
    Active,
    Suspended,
    Deleted,
}

The difference is that Status is a real type. A Go type Status int accepts Status(42), which is a status that doesn't exist. A Rust Status can only ever be one of those three values.

The powerful case is variants with data:

enum Shape {
    Circle { radius: f64 },          // struct-like variant
    Rect { w: f64, h: f64 },
    Triangle(f64, f64, f64),         // tuple-like variant
}

impl Shape {
    fn area(&self) -> f64 {
        match self {
            Shape::Circle { radius } => std::f64::consts::PI * radius * radius,
            Shape::Rect { w, h } => w * h,
            Shape::Triangle(a, b, c) => {
                let s = (a + b + c) / 2.0;
                (s * (s - a) * (s - b) * (s - c)).sqrt()
            }
        }
    }
}

How you would write this in Go:

type Shape interface{ Area() float64 }
type Circle struct{ Radius float64 }
type Rect struct{ W, H float64 }
// ... plus a type switch somewhere:
switch s := shape.(type) {
case Circle: ...
case Rect: ...
// forgot Triangle? compiles fine, silently does nothing
}

	Go interface + type switch	Rust enum + `match`
Set of variants	Open: anyone can implement the interface	Closed: exactly the variants listed
Missing a case	Compiles; bug at runtime	Compile error
Can be nil	Yes	No
Memory	Usually boxed behind an interface pointer, often a heap allocation	Stored inline: size of the largest variant plus a tag

Rust also has the open kind of polymorphism (traits, Lesson 5). Use an enum when you know all the cases (tokens, commands, HTTP methods, states in a state machine, errors). Use a trait when other code needs to add new types. In real Rust code, enums are everywhere: Option, Result, JSON values, AST nodes, and the messages sent between threads.

4. `Option<T>`: no more nil

Rust has no nil. A value that might be absent has the type Option<T>, which is just an ordinary enum from the standard library:

enum Option<T> {
    Some(T),
    None,
}

The point is that Option<User> and User are different types. You cannot call .name on an Option<User>; you must first handle the None case. So the Go bug "forgot to check for nil, panicked in production" becomes a compile error. And when a function returns plain User, you know for certain it's there.

It also costs nothing: Option<&User> is the same size as &User, because the compiler uses the impossible null address to represent None.

fn find_user<'a>(users: &'a [User], name: &str) -> Option<&'a User> {
    users.iter().find(|u| u.name == name)
}

(The <'a> is needed because there are two reference inputs, as in Drill 5. It says the returned reference borrows from users, not from name.)

Everyday ways to handle an `Option`

// 1. match: handle both cases explicitly
match find_user(&users, "ana") {
    Some(u) => println!("found {}", u.email),
    None => println!("not found"),
}

// 2. if let: you only care about the Some case
if let Some(u) = find_user(&users, "ana") {
    println!("found {}", u.email);
}

// 3. let else: unwrap or leave the function early (Go's `if x == nil { return }`)
let Some(u) = find_user(&users, "ana") else {
    return;
};

// 4. Combinators: transform without unwrapping
let name = find_user(&users, "zed")
    .map(|u| u.name.as_str())   // Option<&User> -> Option<&str>
    .unwrap_or("nobody");       // fall back to a default

// 5. The ? operator: inside a function returning Option, return None early
fn first_even(xs: &[i32]) -> Option<i32> {
    let first = xs.first()?;    // if None, return None from first_even right now
    if first % 2 == 0 { Some(*first) } else { None }
}

Method	Does	Use it when
`map(f)`	Transforms the inner value if `Some`	Chaining a computation
`and_then(f)`	Like `map`, but `f` returns an `Option` itself	Chaining steps that can each fail
`unwrap_or(v)` / `unwrap_or_default()`	Gives the value or a fallback	A sensible default exists
`unwrap_or_else(f)`	Fallback computed lazily	The fallback is expensive
`ok_or(err)`	Turns `Option` into `Result`	Lesson 4
`is_some()` / `is_none()`	Tests without taking the value	Only for checks; prefer `if let` when you'll use the value
`copied()` / `cloned()`	`Option<&T>` to `Option<T>`	Getting an owned value out of a lookup
`unwrap()` / `expect("why")`	Panics on `None`	Tests and genuinely impossible cases only

On unwrap(): in production code, treat it as a red flag. Each one is a potential panic. If you are certain it can't fail, use expect("reason it can't fail") so the panic message explains your assumption. In reviews, I'll ask you to justify each one.

5. Pattern matching in depth

A pattern describes the shape of a value and pulls pieces out of it in one step. Patterns appear in match, if let, let else, while let, let, and function parameters.

enum Command {
    Quit,
    Move { x: i32, y: i32 },
    Say(String),
}

fn run(cmd: &Command) -> String {
    match cmd {
        Command::Quit => "bye".to_string(),
        Command::Move { x: 0, y } => format!("vertical {y}"),        // literal inside a pattern
        Command::Move { x, y } if x == y => format!("diagonal {x}"), // match guard
        Command::Move { x, y } => format!("move {x},{y}"),
        Command::Say(msg) => msg.clone(),
    }
}

Things to notice:

Arms are checked top to bottom, and the first match wins. Put specific patterns before general ones. The compiler warns about an arm that can never be reached.
Matching on &Command gives references. Because cmd is a reference, msg binds as &String, not String, so nothing is moved out of the borrowed value. This feature is called "default binding modes" and it's why you rarely write & or ref in patterns.
Exhaustiveness is your refactoring tool. Add a Command::Jump variant, and every match that doesn't handle it becomes a compile error that lists exactly where to update. Avoid a lazy _ => arm on your own enums, because it switches that check off.

The pattern toolbox

match age {
    0 => "newborn",
    n @ 1..=12 if n < 3 => "toddler",   // @ binds the value while testing a range
    1..=12 => "child",
    13..=19 => "teen",
    _ => "adult",
}

match point {
    (0, 0) => println!("origin"),
    (x, y) if x == -y => println!("anti-diagonal"),
    (x, _) => println!("x={x}"),           // _ ignores a part
}

let User { name, email, .. } = user;      // destructure a struct; .. ignores the rest

let is_gone = matches!(status, Status::Suspended | Status::Deleted); // bool from a pattern

`if let`, `let else`, `while let`

if let Command::Say(msg) = &cmd {          // one variant you care about
    println!("{msg}");
}

let Some(expr) = env::args().nth(1) else {  // unwrap or exit: flat code, no nesting
    eprintln!("usage: rpn <expr>");
    process::exit(1);
};

let mut stack = vec![1, 2, 3];
while let Some(top) = stack.pop() {         // loop until the pattern stops matching
    print!("{top} ");                       // 3 2 1
}

let else is the closest thing to Go's guard-clause style (if err != nil { return }). It keeps the happy path unindented, and the else block must leave the scope (return, break, continue, or exit). Industry Rust uses it heavily at the top of functions.

6. Exercise: a stack, and an RPN calculator on top of it

You'll build the stack data structure, then use it to evaluate Reverse Polish Notation, where the operator comes after its operands: 3 4 + 2 * means (3 + 4) * 2. It's a classic stack problem, and it exercises structs, methods, enums with data, match and Option together.

cargo new rpn && cd rpn
cargo run -- "3 4 + 2 *"    # 14
cargo run -- "10 2 -"       # 8
cargo run -- "-3 4 *"       # -12  (a negative number, not the operator)
cargo run -- "1 0 /"        # stderr: error: invalid expression, exit 1
cargo run -- "1 +"          # stderr: error: invalid expression, exit 1
cargo run                   # stderr: usage: rpn "<expression>", exit 1

How RPN evaluation works: read tokens left to right. A number gets pushed. An operator pops two values (the first pop is the right operand), applies itself, and pushes the result. At the end, exactly one value must remain on the stack.

Part A: the stack

[ ] struct Stack wrapping a Vec<i64>, with #[derive(Debug, Default)].
[ ] Methods with the right receivers: new() -> Self, push(v: i64), pop() -> Option<i64>, peek() -> Option<&i64>, len() -> usize. Choosing &self vs &mut self for each is part of the exercise.
[ ] Tests: pop on an empty stack, push then peek, and LIFO order after several pushes.

Part B: the calculator

[ ] enum Op { Add, Sub, Mul, Div } and enum Token { Num(i64), Op(Op) }.
[ ] fn parse_token(s: &str) -> Option<Token>, written as one match on the string.
[ ] A method impl Op { fn apply(self, a: i64, b: i64) -> Option<i64> } that returns None on overflow and on division by zero.
[ ] fn eval(expr: &str) -> Option<i64> using your Stack. Use ? so you never write nested matches on pop().
[ ] main uses let else for the missing argument and exits with code 1 on any error. No unwrap(), no .clone().
[ ] Tests for eval: the examples above, plus empty input, an unknown token like x, and leftover values like "1 2".
[ ] cargo fmt --check && cargo clippy -- -D warnings && cargo test pass.

Hints (read only when stuck)

Most Stack methods are one line that forwards to a Vec method. Look at Vec::pop and slice::last in the docs.
In parse_token, a _ => arm can try s.parse::<i64>(). That returns a Result; .ok() turns it into an Option, and .map(Token::Num) wraps the number. Yes, an enum variant can be passed as a function.
Integers have checked_add, checked_sub, checked_mul and checked_div, and each returns an Option. checked_div already handles division by zero.
Op holds no data, so derive Clone, Copy on it. Then apply can take self by value without moving anything important.
Gotcha: in a binary crate, a method nobody calls triggers a dead_code warning, and -D warnings turns that into an error. Use len() and peek() in eval to check that exactly one value remains and to read it. That's their natural job anyway.

Rust for Gophers, Lesson 2: Ownership and Borrowing

Syam SV — Wed, 28 Oct 2026 17:17:28 +0000

1. Why ownership exists

Ownership is how Rust frees memory without a garbage collector and without you calling free. The compiler works out, at compile time, exactly where each heap value is freed. Every rule in this lesson exists to make that analysis possible.

Stack vs heap, quickly. Values with a size known at compile time (i32, bool, [u8; 4], a struct of those) live on the stack and are popped when the function returns, which is free. Values that grow (String, Vec<T>) keep a small fixed header on the stack (pointer, length, capacity) that points to a buffer on the heap. The question every language must answer is who frees that heap buffer, and when.

	Who frees heap memory	Cost	What can go wrong
C	You, with `free`	None	Use-after-free, double free, leaks
Go	The garbage collector, at some point later	GC CPU and pauses, more memory headroom	Data races, stale aliases, leaks through long-lived references
Rust	The compiler inserts the free at the end of the owner's scope	None at runtime	Prevented at compile time; you pay in learning effort

Go's escape analysis already decides stack vs heap for you, and the GC handles the rest. Rust asks you to state the relationships (who owns, who borrows, for how long), and in return you get C-level performance with no use-after-free, no double free, and no data races. That last one matters for your multithreading goal: the same rules you learn today are what make concurrent Rust safe in Lesson 10.

2. The three rules, moves, and Drop

Memorize these three rules; everything else follows from them.

Each value has exactly one owner (a variable, a struct field, a vector slot).
Ownership can be moved to a new owner, and then the old one can no longer be used.
When the owner goes out of scope, the value is dropped (its memory freed, its file closed, its lock released).

Moves

let s1 = String::from("hi");
let s2 = s1;          // ownership MOVES to s2. Only the stack header is copied
// println!("{s1}");  // error[E0382]: borrow of moved value: `s1`
println!("{s2}");

In Go, s2 := s1 for a slice copies the header and both variables share the same backing array. That is cheap but creates two handles to one buffer. Rust copies the header too, but then invalidates s1, so there is still exactly one owner and exactly one free. No double free is possible.

Passing to a function is also a move:

fn takes(s: String) -> usize {
    s.len()
} // s is dropped here; the heap buffer is freed

let name = String::from("Syam");
takes(name);
// takes(name);  // error: use of moved value

Copy vs Clone

let a = 5;
let b = a;               // i32 is Copy: a bitwise copy, `a` is still valid
println!("{a} {b}");

let s = String::from("hi");
let t = s.clone();       // explicit deep copy: allocates a new heap buffer
println!("{s} {t}");

Copy types are plain data with no heap ownership: integers, floats, bool, char, and tuples and arrays of those. Assignment copies them implicitly, so they never "move".
Clone is an explicit, possibly expensive duplicate. Rust never deep-copies behind your back, so every allocation is visible in the code as .clone(), .to_string() or .to_vec().

A beginner habit to avoid: sprinkling .clone() to silence the borrow checker. It compiles, but it hides a design problem and allocates. In reviews I'll flag every clone that a borrow could replace.

Drop: `defer` that you can't forget

{
    let f = std::fs::File::open("data.txt")?;
    // use f...
} // f is dropped here: the file is closed automatically

In Go you write defer f.Close() and hope nobody forgets. In Rust the cleanup is tied to the owner's scope (this pattern is called RAII), so files, sockets, mutex locks and DB connections are always released, even on early return or panic. You'll see this pay off with MutexGuard in Lesson 10 and connection pools in Lesson 15.

3. Borrowing: references without ownership

Moving everything everywhere would be unbearable, so Rust lets you borrow: hand out a reference that uses the value without owning it. The owner keeps responsibility for dropping it.

fn len_of(s: &str) -> usize {   // shared borrow: read-only
    s.len()
}

fn excite(s: &mut String) {     // mutable borrow: can modify
    s.push('!');
}

let mut g = String::from("hello");
excite(&mut g);                 // the call site says &mut, so mutation is visible
println!("{} {g}", len_of(&g)); // 6 hello!

A reference is a pointer that the compiler has proven is valid. Unlike a Go pointer, it can never be nil and can never outlive the thing it points to.

The one rule of borrowing

At any moment, a value can have either any number of shared references &T, or exactly one mutable reference &mut T. Never both.

This is the readers-writer lock pattern, enforced at compile time with zero runtime cost. Think of &T as "shared, read-only" and &mut T as "exclusive". The precise names matter more than the keywords: &mut really means unique access.

The Go bug this prevents

// Go: compiles, runs, and is silently wrong
v := []int{1, 2, 3}
first := &v[0]
v = append(v, 4)   // may reallocate to a new backing array
*first = 100       // writes to the OLD array; v[0] is still 1

// Rust: refuses to compile
let mut v = vec![1, 2, 3];
let first = &v[0];       // shared borrow of v starts
v.push(4);               // error[E0502]: cannot borrow `v` as mutable
                         // because it is also borrowed as immutable
println!("{first}");     // shared borrow is still alive here

In Go the GC keeps the old array alive, so it isn't a crash, just a quiet logic bug. In C++ the same code is a use-after-free. In Rust it can't be written. The exact same rule, applied across threads, is why Rust has no data races: two threads can't both hold &mut to the same data.

Borrows end at their last use

let mut v = vec![1, 2, 3];
let first = &v[0];
println!("{first}");   // last use of `first`: the borrow ends here
v.push(4);             // fine

The compiler tracks where each reference is last used, not where its variable goes out of scope (this is called non-lexical lifetimes). Reordering code like this is often the whole fix for a borrow error.

No dangling references

fn make() -> &String {        // error[E0106]: missing lifetime specifier
    let s = String::from("hi");
    &s                        // s is dropped at the end of make()
}

In Go, returning &s is fine because escape analysis moves s to the heap. Rust won't silently heap-allocate. The fix is to return the owned value, fn make() -> String, which moves ownership out to the caller at no cost. "Missing lifetime specifier" is the compiler asking how long the reference should live; we cover lifetimes properly in Lesson 8.

4. Slices, and `String` vs `&str`

A slice is a borrowed view into a contiguous sequence: a pointer plus a length, with no capacity. It is Go's slice header minus cap, and it never owns its data.

fn sum(xs: &[i32]) -> i32 {
    xs.iter().sum()
}

let v = vec![1, 2, 3, 4];
sum(&v);        // &Vec<i32> coerces to &[i32] automatically
sum(&v[1..]);   // a sub-slice: [2, 3, 4]
sum(&[5, 6]);   // an array works too

You cannot append to a slice in Rust. Growth needs ownership, so only the Vec can grow. That removes Go's entire class of "did my append alias the caller's array" bugs.

Two string types

	`String`	`&str`
What it is	Owned, growable UTF-8 buffer on the heap	Borrowed view into UTF-8 bytes somewhere
Analogy	`Vec<u8>` that is guaranteed valid UTF-8	`&[u8]` that is guaranteed valid UTF-8
Go analogy	`strings.Builder` / `[]byte` you own	Go's `string` (an immutable view)
Literals	`String::from("hi")`, `"hi".to_string()`	`"hi"` is a `&'static str` baked into the binary
Use for	Struct fields, return values, anything you build	Function parameters that only read

fn first_word(s: &str) -> &str {
    match s.find(' ') {
        Some(i) => &s[..i],   // a slice of the input; no allocation
        None => s,
    }
}

let line = String::from("hello world");
first_word(&line);             // &String coerces to &str
first_word("literal works");   // so does a literal

The returned &str borrows from the input, so the compiler won't let line be modified or dropped while the result is in use. In Go, bytes.Fields gives you zero-copy sub-slices too, but nothing stops you from mutating the underlying []byte while they are in use.

UTF-8: bytes are not characters

let s = String::from("héllo");
s.len();               // 6, bytes (é is 2 bytes), like len() in Go
s.chars().count();     // 5, Unicode scalar values, like utf8.RuneCountInString
// s[0]                // error: strings can't be indexed by integer
// &s[0..2]            // compiles, but PANICS: byte 2 is inside 'é'
for (i, ch) in s.char_indices() { /* like `for i, r := range s` in Go */ }

Rust forbids s[0] because it would be ambiguous (byte or character?) and O(1)-looking while really needing a scan. Slicing by byte range is allowed but panics if you cut through a character. In real code, find boundaries with find, split_whitespace, char_indices, or work on s.as_bytes() when you truly have ASCII, as you will in the base64 lesson.

5. Choosing function signatures

Every parameter answers one question: does this function need to own the value, change it, or just look at it? Pick the weakest access that works.

Signature	Meaning	Caller writes	Use when
`fn f(x: &T)`	Read-only borrow	`f(&x)`	Default for reading. Most parameters
`fn f(x: &mut T)`	Exclusive borrow, may modify	`f(&mut x)`	Changing the caller's value in place
`fn f(x: T)`	Takes ownership	`f(x)` (moved)	Storing it, sending it to another thread, or consuming it
`fn f() -> T`	Gives ownership to the caller	`let x = f();`	Creating new values. Returning owned values is cheap: a move, not a copy

Industry conventions clippy will push you towards:

Take &str, not &String, and &[T], not &Vec<T>. The slice form accepts more callers (literals, arrays, sub-slices) and gives up nothing. Clippy's ptr_arg lint flags the other form.
Return owned types (String, Vec<T>) from functions that build new data. Return &str/&[T] only when you are handing back a piece of an input.
Go's habit of passing a pointer "to avoid copying" doesn't carry over. Moves never deep-copy, so fn f(x: BigStruct) is fine when you want ownership.
mut in a signature is visible at every call site (&mut x). When you read Rust code, you always know which calls can change your data. Go gives you no such signal for pointers or slices.

6. Compiler error drills

Before you write the exercise, work through these five snippets. Each one is broken. For each one, predict the problem before you compile it, then paste it into src/main.rs, read the full error (cargo check), and fix it in the most idiomatic way, without using .clone(). Learning to read borrow-checker errors is the real skill here; they are some of the best error messages in any language.

Drill 1

fn main() {
    let v = vec![String::from("a"), String::from("b")];
    for x in v {
        println!("{x}");
    }
    println!("{}", v.len());
}

Drill 2

fn main() {
    let mut s = String::from("a");
    let r1 = &s;
    let r2 = &mut s;
    r2.push('b');
    println!("{r1}");
}

Drill 3 (fix it two different ways)

fn make() -> &String {
    let s = String::from("hi");
    &s
}

Drill 4 (this one compiles; what happens when it runs?)

fn main() {
    let s = String::from("héllo");
    let part = &s[0..2];
    println!("{part}");
}

Drill 5 (stretch: a preview of Lesson 8)

The compiler's suggestion will add <'a>. Apply it, then explain in one sentence why the compiler couldn't figure this out alone when it could for first_word in section 4.

7. Exercise: `wordy`, a word counter

Build a small wc-style tool. The point is to practice choosing between &str, String and &mut String, and returning borrowed slices from your inputs. Finish fizzbuzz v2 first if you haven't yet.

cargo new wordy && cd wordy
printf 'The quick brown fox\njumps over the lazy dog\n' | cargo run
#        2       9      43      43
# longest: quick
# long words: ["quick", "brown", "jumps"]
cargo run -- notes.txt     # reads a file instead of stdin
cargo run -- missing.txt   # stderr: error: No such file or directory (os error 2), exit 1

Requirements

[ ] fn count(text: &str) -> (usize, usize, usize, usize): lines, words, chars, bytes. Print them right-aligned in 8-wide columns like wc.
[ ] fn longest_word(text: &str) -> Option<&str>: the longest word measured in characters (not bytes), first one wins a tie, None for empty input. It must return a slice of text, with no allocation.
[ ] fn words_longer_than(text: &str, n: usize) -> Vec<&str>: all words with more than n characters, as slices of text. Print them for n = 4.
[ ] fn normalize(text: &mut String): lowercases ASCII letters and strips trailing whitespace in place, without creating a new String.
[ ] main reads the file named by the first argument, or stdin if there is none. Any I/O error goes to stderr with exit code 1. No unwrap().
[ ] Tests: at least one per function, including empty input, a tie in longest_word, and a non-ASCII word such as héllo where chars and bytes differ.
[ ] Zero .clone() calls, and cargo fmt --check && cargo clippy -- -D warnings && cargo test pass.

Hints (read only when stuck)

str already has what you need: lines(), split_whitespace(), chars(), len(). Look them up in cargo doc --open under str.
Reading input: std::fs::read_to_string(path) and std::io::read_to_string(std::io::stdin()) both return Result<String, io::Error>. Match on env::args().nth(1) to choose which one to call, then match the result once.
For longest_word, keep an Option<&str> for the best so far. A match arm can have a guard: Some(b) if condition => ....
For normalize, look for a make_ascii_* method on String, and for a method that shortens a String to a given length. trim_end() tells you what that length should be.
When the compiler says something "does not live long enough" or "cannot borrow as mutable", draw on paper who owns each value and when each borrow is last used.

Rust for Gophers, Lesson 1: Hello, Cargo

Syam SV — Wed, 28 Oct 2026 17:14:17 +0000

The roadmap

We go from hello world to an async web service with a database in 16 lessons, and every lesson ends with a program you write by hand. Each phase builds the muscle the next one needs: you cannot write a sane async server until ownership and traits feel natural, so we don't rush there.

#	Lesson	What you build	Go concept it replaces
1	Toolchain, basics, tests (today)	`greet` + `fizzbuzz` with tests	`go mod`, `go test`, `gofmt`, `go vet`
2	Ownership, borrowing, slices, `String` vs `&str`	Word counter	GC + pointers
3	Structs, enums, `match`, `Option`	Stack data structure	structs, `nil`, iota
4	Error handling: `Result`, `?`, custom errors	Base64 encoder/decoder	`if err != nil`, `errors.Is`
5	Traits and generics	Generic stack + `Display`/`Iterator` impls	interfaces, generics
6	Collections and iterators	Log file analyzer	`for range`, maps, slices
7	Modules, crates, workspaces	Split the base64 tool into lib + bin	packages, `internal/`
8	Lifetimes in depth	Zero-copy tokenizer	escape analysis
9	Real CLIs: `clap`, `anyhow`, `thiserror`	`grep`-like CLI tool	`flag`, `cobra`
10	Threads: `std::thread`, `Arc`, `Mutex`, channels	Parallel file hasher	goroutines, `sync`, chans
11	`Send`/`Sync` and fearless concurrency	Thread pool from scratch	`sync.WaitGroup`, worker pools
12	Raw HTTP over `TcpListener`	Tiny HTTP/1.1 server by hand	`net` package
13	Async Rust: futures, `tokio`	Async chat server	goroutines + `select`
14	Web with `axum`	JSON REST API	`net/http`, chi/gin
15	Databases with `sqlx` + Postgres	CRUD service	`database/sql`, pgx
16	Production polish: tracing, config, testing, CI	Ship the CRUD service	`slog`, `testing`, CI

How each lesson works: I explain the concepts, you write the exercise yourself and paste your code here, then I review it like a senior engineer would on a PR. I give hints before answers, and a full solution only if you ask for one.

1. Setup and tooling

Install Rust with rustup, the official toolchain manager. It is like having go plus a version manager in one tool.

curl --proto '=https' --tlsv1.2 -sSf https://sh.rustup.rs | sh
rustup component add rustfmt clippy   # usually installed by default
rustc --version && cargo --version

The pieces you get:

Tool	What it does	Go equivalent
`rustup`	Installs and switches toolchains (stable, beta, nightly)	`go install golang.org/dl/...`
`rustc`	The compiler. You almost never call it directly	`go tool compile`
`cargo`	Build, run, test, deps, docs, publish	`go` command
`rustfmt` (`cargo fmt`)	The one true formatter	`gofmt`
`clippy` (`cargo clippy`)	700+ lints for bugs and non-idiomatic code	`go vet` + `staticcheck`
`rust-analyzer`	Language server for your editor	`gopls`

Install the rust-analyzer extension in your editor now. It shows inferred types inline, which is the single biggest help while learning.

Creating a project

cargo new hello_rust      # binary crate (has main.rs)
cargo new mylib --lib     # library crate (has lib.rs)

hello_rust/
├── Cargo.toml     # manifest: name, version, edition, dependencies (like go.mod)
├── Cargo.lock     # exact resolved versions (like go.sum); commit it for binaries
├── src/
│   └── main.rs    # crate root for a binary
└── target/        # build output; git-ignored

[package]
name = "hello_rust"
version = "0.1.0"
edition = "2024"

[dependencies]

The edition is a Rust-specific idea. Editions (2015, 2018, 2021, 2024) let the language make small breaking syntax changes without breaking old code, and crates of different editions link together fine. Always use the latest for new code.

The commands you will type every day

Command	What it does
`cargo check`	Type-checks without producing a binary. Fastest feedback; run it constantly
`cargo build` / `cargo build --release`	Debug build (fast compile, slow code) / optimized build
`cargo run -- arg1 arg2`	Build and run; everything after `--` goes to your program
`cargo test`	Runs unit, integration and doc tests
`cargo fmt`	Formats all code
`cargo clippy -- -D warnings`	Lints, and treats warnings as errors (what CI should do)
`cargo doc --open`	Builds HTML docs for your crate and all its dependencies
`cargo add serde`	Adds a dependency to Cargo.toml

Industry habit: before every commit run cargo fmt && cargo clippy -- -D warnings && cargo test. Clippy is a teacher, not a nag; read every lint it gives you, because each one links to an explanation.

2. Hello world, dissected

fn main() {
    println!("Hello, world!");
}

Three lines, and four ideas worth understanding properly.

fn main() is the entry point. Like Go's func main() but with no package main line: the crate root file (src/main.rs) plays that role. main can also return Result<(), E>, which we will use from Lesson 4 so errors exit with a non-zero code.

println! is a macro, not a function. The ! marks a macro call. Macros run at compile time and generate code. That is why println! can take a variable number of arguments and check your format string at compile time: println!("{} {}", a) is a compile error, while Go's fmt.Printf only catches that in go vet. Formatting basics:

let name = "Syam";
let pi = 3.14159;
println!("Hi {name}");          // inline variable capture
println!("Hi {}", name);        // positional
println!("{pi:.2}");            // 3.14, like %.2f
println!("{:?}", [1, 2, 3]);    // Debug output, like %v
println!("{:#?}", some_struct); // pretty Debug, like %+v on multiple lines
eprintln!("to stderr");         // like fmt.Fprintln(os.Stderr, ...)
let s = format!("{name}!");     // like fmt.Sprintf

{} uses the Display trait (human-facing output) and {:?} uses Debug (developer-facing). A type must opt in to each one; we cover traits in Lesson 5.

Semicolons matter. They turn an expression into a statement. This sounds trivial, but it is the key to the next section.

The compile model. cargo build compiles your whole crate as one unit and produces a single native binary with no runtime and no garbage collector, so there is no GC pause and the binary starts instantly. The price is slower compiles than Go. That is why cargo check exists: it skips code generation and is usually several times faster.

3. Core basics, the Go programmer's way

Variables are immutable by default

let x = 5;         // immutable binding, type inferred as i32
// x = 6;          // compile error: cannot assign twice to immutable variable
let mut y = 5;     // opt in to mutation
y += 1;
const MAX_USERS: u32 = 1_000;  // compile-time constant, type always required

In Go everything is mutable and you trust yourself. In Rust, mut is a signal to the reader: "this value changes, watch it." Industry style is to make things mutable only when you need to; clippy and the compiler warn about unneeded mut.

Shadowing

let spaces = "   ";          // &str
let spaces = spaces.len();   // new variable, now usize; the old one is hidden

This is not mutation; it creates a new binding, and the type can change. It is idiomatic for transforming a value step by step (parse input, then validate it) without inventing names like spacesStr and spacesLen. Go forbids this in the same scope.

Scalar types

Rust	Go	Notes
`i8 i16 i32 i64 i128`	`int8 … int64`	`i32` is the default integer
`u8 u16 u32 u64 u128`	`uint8 … uint64`	`u8` is a byte
`isize` / `usize`	`int` / `uint`	Pointer-sized. Indexes and lengths are always `usize`
`f32` / `f64`	`float32` / `float64`	`f64` is the default
`bool`	`bool`
`char`	`rune`	4 bytes, one Unicode scalar value

Two differences that bite Go programmers:

No implicit conversions, ever. Not even i32 to i64. You write x as i64 for a lossy/primitive cast, or i64::from(x) for a lossless one. Prefer from/try_from in real code because as silently truncates (300_i32 as u8 is 44).
Integer overflow is a bug, not a feature. In debug builds u8::MAX + 1 panics; in release it wraps. When you want a specific behaviour say so: checked_add (returns Option), wrapping_add, saturating_add.

Compound types

let t: (i32, &str, f64) = (1, "two", 3.0); // tuple, fixed size, mixed types
let (a, b, c) = t;                         // destructuring
let first = t.0;
let arr: [i32; 3] = [1, 2, 3];             // fixed-size array, like Go's [3]int
let zeros = [0u8; 1024];                   // 1024 zero bytes

The growable list (Go's slice) is Vec<T>, and the empty tuple () ("unit") is what functions return when they return nothing.

Functions, and the big idea: everything is an expression

fn add(a: i32, b: i32) -> i32 {
    a + b      // no semicolon: this is the return value
}

Parameter and return types are always written; Rust never infers function signatures, so a signature is a contract you can read. The last expression in a block, written without a semicolon, is the block's value. Add a ; and it becomes a statement that evaluates to (), giving you the classic beginner error expected i32, found (). Use return only for early exits.

Because blocks are expressions, if and match produce values. Rust has no ternary operator because it doesn't need one:

let name = if args.len() > 1 { &args[1] } else { "world" };

Control flow

// loop: infinite loop that can return a value via break
let mut counter = 0;
let result = loop {
    counter += 1;
    if counter == 10 {
        break counter * 2;
    }
};

// while
while counter > 0 {
    counter -= 1;
}

// for over a range: 1..5 is 1 to 4, 1..=5 includes 5
for i in 1..=5 {
    println!("{i}");
}

// for over a collection, like `for _, v := range items`
for item in &items { /* borrow each */ }
for (i, item) in items.iter().enumerate() { /* like `for i, v := range` */ }

There is no C-style for i := 0; i < n; i++. Ranges and iterators replace it, and they remove off-by-one and out-of-bounds bugs.

`match`: switch with superpowers

fn describe(code: u16) -> &'static str {
    match code {
        200 => "ok",
        301 | 302 => "redirect",
        400..=499 => "client error",
        500..=599 => "server error",
        _ => "unknown",
    }
}

match must be exhaustive: the compiler refuses to build if a case is missing, which is why _ (the catch-all) exists. Unlike Go's switch, there is no fallthrough and arms are expressions. This becomes enormously powerful with enums in Lesson 3.

Ignore the &'static str for now. It means "a reference to a string that lives for the whole program", which is what string literals are. Lesson 2 is entirely about what & means.

4. Testing from day one

Rust's convention is to put unit tests in the same file as the code, inside a tests module that only compiles under cargo test. Go puts them in a separate _test.go file; Rust keeps them next to the code they check.

fn greeting(name: &str) -> String {
    format!("Hello, {name}!")
}

#[cfg(test)]          // compile this module only when testing
mod tests {
    use super::*;     // bring the parent module's items into scope

    #[test]
    fn greets_by_name() {
        assert_eq!(greeting("Syam"), "Hello, Syam!");
    }

    #[test]
    #[should_panic]
    fn overflow_panics_in_debug() {
        let x: u8 = 255;
        let _ = x + std::hint::black_box(1);
    }
}

assert_eq!(left, right) and assert_ne! print both values on failure; assert!(cond, "message {x}") for anything else. There is no t.Errorf: a failing assertion panics, and the test runner catches it.
Tests run in parallel threads by default, like t.Parallel() everywhere.
cargo test greets runs only tests whose name contains greets, like go test -run.
cargo test -- --nocapture shows println! output, which is hidden for passing tests.
Unit tests can call private functions, because the tests module is a child of the module under test. Integration tests (Lesson 7) live in a top-level tests/ directory and only see your public API, like Go's package foo_test.

5. Your exercise: `fizzbuzz` CLI

Build a small CLI that takes a number and prints FizzBuzz up to it, with tests, and passes fmt and clippy cleanly. Write it yourself, no AI autocompletion, and keep the compiler's error messages open: reading them is half the skill.

cargo new fizz
cd fizz
cargo run -- 15     # prints 1, 2, Fizz, 4, Buzz, ... FizzBuzz
cargo run           # prints to stderr: usage: fizz <N>   and exits with code 1
cargo run -- abc    # prints to stderr: error: 'abc' is not a valid number   exit code 1

Requirements

[ ] fn fizzbuzz(n: u32) -> String: "Fizz" for multiples of 3, "Buzz" for 5, "FizzBuzz" for both, otherwise the number. Implement it with a single match, not an if/else chain.
[ ] fn sum_of_multiples(limit: u32) -> u64: the sum of all numbers below limit divisible by 3 or 5 (for 10 it is 23). Note the return type is wider than the input; convert without as.
[ ] main reads the first argument with std::env::args(), parses it to u32, and handles a missing or invalid argument as shown above using eprintln! and std::process::exit(1).
[ ] After the FizzBuzz lines, print sum of multiples below N: X.
[ ] At least 6 unit tests, including edge cases: 0, 1, 3, 5, 15, and a large number for sum_of_multiples.
[ ] cargo fmt --check && cargo clippy -- -D warnings && cargo test all pass.
[ ] No mut you don't need, and no unwrap().

Hints (read only when stuck)

You can match on a tuple: match (n % 3, n % 5) { (0, 0) => ..., ... }. Think about which arm order is correct and what _ patterns do inside a tuple.
To turn a number into a String, look up to_string(). Notice every arm of a match must have the same type.
std::env::args().nth(1) returns an Option<String>, which is either Some(value) or None. You can match on it exactly like a u16 above.
"42".parse::<u32>() returns a Result<u32, ParseIntError>: either Ok(n) or Err(e). Also handled with match. We go deep on both in Lessons 3 and 4; for today pattern matching is enough.
For sum_of_multiples, u64::from(x) widens a u32 losslessly. Write it first with a for loop and a mut total, then, as a stretch goal, as one iterator chain using filter, map and sum (look them up in cargo doc --open or doc.rust-lang.org/std).

Unveiling Linux Command's - sar

Syam SV — Mon, 28 Aug 2023 05:08:57 +0000

In the world of computers, the SAR (System Activity Reporter) command is like a magic tool. It helps us understand how our computer is doing and where it might need some help. In this article, we'll take a look at the SAR command and see how it can tell us interesting things about our computer.

What is SAR?

SAR stands for System Activity Reporter. It's like a detective that watches over our computer and takes notes about what it's doing. It looks at what's happening on our computer and makes reports about it. It can tell us things like how busy our computer is, how much memory it's using, how the network is behaving, and much more. It's like a data historian that keeps track of what our computer has been up to.

For detailed matrix information, please refer to here* and here

sar [ options ] [ <interval> [ <count> ] ]

example:

sar -b 1 10

sar -r 1

SAR can do many helpful jobs for us. Let's look at some of them and see what they mean

Checking I/O and Transfer Rate

Imagine your computer is sending and receiving data. SAR can tell us how busy it is doing that. It can count how many times it's doing these jobs and how much data is being sent and received every second.

sar -b [ <interval> [ <count> ] ]

example:

sar -b 1 10

Paging Statistics

Sometimes, our computer needs to get information from the hard drive. This is called paging. SAR can tell us how often this happens and how much data is being moved between the hard drive and the computer's memory.

sar -B [ <interval> [ <count> ] ]

example:

sar -B 1 10

Network Numbers

If our computer is connected to the internet, SAR can tell us how much data is going in and out. It can show us how many packets of data are being sent and received. This helps us understand if our internet connection is fast or slow.

sar -n [options] [ <interval> [ <count> ] ]

example:

sar -n DEV 1 10
sar -n TCP,UDP 1 10

Load and Queue

When our computer is doing many things at once, it has a "load." SAR can tell us how heavy this load is. It can also tell us how many things are waiting to be done. This is like knowing how many people are waiting in line at a store.

sar -q [ <interval> [ <count> ] ]

example:

sar -q 1 10

Memory and Swap Info

Our computer uses memory to work. SAR can show us how much of this memory is being used. It can also tell us if the computer is using "swap space," which is like extra memory.

sar -r [ <interval> [ <count> ] ]

example:

sar -r 1 10

CPU Usage

The "brain" of our computer is called the CPU. SAR can tell us how busy the CPU is. It can say if it's mostly being used by programs, or if it's waiting for something to happen.

sar -u [ <interval> [ <count> ] ]

example:

sar -u 1 10

Page Swapping

Sometimes, the computer needs to exchange data quickly. This is called "swapping." SAR can tell us if this is happening a lot and if it's causing any problems.

sar -W [ <interval> [ <count> ] ]

example:

sar -W 1 10

Conclusion

SAR is like a helpful friend that watches over our computer. It tells us all sorts of things about what's happening inside. Whether it's how busy our computer is, how much memory it's using, or how well the internet is working, SAR gives us answers. So, the next time you're curious about how your computer is performing, remember to ask SAR! Keep in mind that this article provides a simplified overview of SAR, and if you're interested in diving deeper, be sure to refer back to the detailed explanations above.

Unveiling Linux Command's - dmesg

Syam SV — Thu, 24 Aug 2023 12:03:42 +0000

dmesg, short for "diagnostic messages" is a command-line utility in Linux that provides access to the kernel's ring buffer. This buffer stores messages generated by the Linux kernel during the boot process and while the system is running. These messages encompass a wide range of information, including device driver status, hardware initialization, and error messages. Users can rely on the dmesg command for several key reasons:

Boot Process Analysis: When a Linux system boots up, a plethora of hardware components and device drivers are initialized. In case of any failures or warnings during this process, dmesg becomes your go-to tool. Running dmesg immediately after boot can help you identify hardware issues, driver failures, and other critical information.
Kernel Error Diagnosis: Kernel messages displayed by dmesg include errors, warnings, and information about kernel modules. When something goes wrong at the kernel level, dmesg can provide insights into the root cause of the issue, helping you diagnose and rectify the problem promptly
Driver Debugging: dmesg allows you to examine the interaction between your drivers and the kernel, aiding in debugging and improving driver performance.
and more ...

Basic Usage

The simplest way to use dmesg is by running the command without any options

dmesg

This will display the most recent kernel messages, starting from the end of the ring buffer

Severity based filtering

You can filter messages based on their severity levels using the -l or --leveloption. The severity levels include emerg (emergency), alert, crit (critical), err (error), warn (warning), notice, info, and debug.

dmesg -l err,warn

Continuous monitoring

To monitor the kernel messages in real-time as new messages are logged, you can use the -w or --follow option

dmesg -w

Clearing the kernel ring buffer

Sometimes, you might want to clear the ring buffer, such as after diagnosing an issue and wanting to start with a clean slate. This can be done using the -c or --clear

dmesg -c

The dmesg command is a versatile tool that empowers system administrators to gain insights into the inner workings of the Linux kernel. By mastering its various options, you can effectively diagnose issues, analyze system behavior, and ensure the stability and reliability of your Linux systems. Whether you're troubleshooting boot failures, managing devices and drivers, or debugging kernel-level problems, dmesg remains an invaluable asset in your system administration toolkit

Formatting & Mounting Storage Volumes

Syam SV — Thu, 24 Aug 2023 04:48:56 +0000

Listing and Identifying Storage Devices

let's begin by learning how to list and identify the storage devices attached to your system. Using the lsblk command, you can get a comprehensive list of all the block devices, such as hard drives and USB flash drives, connected to your machine.

lsblk

Each storage device is uniquely identified by a device name like sda, sdb, etc., which will help you interact with them.

Creating a Partition Table and Partitions with fdisk

fdisk is a powerful command-line tool that allows you to create and manage partition tables on your storage devices. In this section, it'll walk you through the process of creating a partition table, creating partitions, and writing the changes to the disk.

Be cautious when using fdisk as it directly modifies the disk's partition table. Any incorrect actions may lead to data loss. Make sure you have a backup of your important data before proceeding.

Identify the Disk Device
Before using fdisk, you need to identify the disk device you want to partition. To list all available disks, use the lsblk command:

lsblk

Identify the disk you want to partition, such as /dev/sdX (e.g., /dev/sda, /dev/sdb, etc.), where "X" is the specific letter assigned to the disk by the system.

Launching fdisk

To start partitioning the disk, run fdisk with the chosen disk device:

sudo fdisk /dev/sdX

Replace /dev/sdX with the appropriate disk identifier.

Creating a New Partition Table

If the disk is not yet partitioned or you want to create a new partition table, follow these steps:
a. Press g to create a new GPT (GUID Partition Table) or m to create a new MSDOS (MBR) partition table.

Creating Partitions

To create a new partition, follow these steps:

Press n to start creating a new partition.
Specify the partition number (e.g., 1, 2, etc.).
Specify the starting sector (press Enter for the default).
Specify the ending sector. You can either:
Use a specific size (e.g., +1G for 1 gigabyte) or
Press Enter to use the remaining space on the disk.

Formatting a Storage Device

After creating partitions, you'll typically need to format them with a file system before using them. Once you've identified the storage device you want to utilize, you might need to format it with a specific file system type before you can use it. For Linux, the most common file system types are ext4, while for cross-platform compatibility with Windows, you can use exFAT. Here are the commands to format the partition:

sudo mkfs.ext4 /dev/<device_partition>

sudo mkfs.exfat -n "label" /dev/<device_partition>

Replace with the appropriate partition identifier, such as /dev/sdb1, for your device.

Mounting the Storage Volume

After formatting the partition, you can mount it to make it accessible within the file system. You have the flexibility to mount the partition to any folder you like, but commonly used mount points are /mnt for permanent volumes and /media for temporary ones.

Here's how you can mount the partition:

sudo mount /dev/<device_partition> /<mount_path>

Here, we can see each option can be supplied along with a value when mounting the device.

sudo mount -o uid=<uid>,gid=<group_id> /dev/<device_partition> /<mount_path>

Replace with the directory where you want to access the storage volume.

Analyzing Disk Usage with ncdu

Now, let's introduce you to a powerful storage management tool called ncdu. In case it's not already installed, you might need to install it first. For Fedora and Centos use:

sudo dnf install ncdu

For Debian-based systems, use apt instead of dnf.

Once installed, you can use ncdu to analyze disk usage on your system. This tool provides a detailed breakdown of files and directories consuming the most space. To use ncdu, simply run:

sudo ncdu

It will display the disk usage starting from your current directory. You can navigate through the results, drill down into directories, and identify which files are taking up the most space. This tool is incredibly handy when you need to reclaim storage space on your system.

Automating Mounts with /etc/fstab

For those looking to automate the process of mounting storage volumes during system boot, the /etc/fstab file comes to the rescue. However, editing this file requires caution, as mistakes can prevent your system from booting correctly.

The /etc/fstab file allows you to specify the devices and mount points you want to mount automatically at startup, using UUIDs or device names to identify the storage volumes. Please note that editing this file requires an understanding of the correct syntax and should be approached carefully. If you're unsure, it's best to seek expert guidance or create proper backups before making any changes.

Firewalld Basics and Usage with firewall-cmd:

Syam SV — Mon, 21 Aug 2023 05:54:09 +0000

Firewalld is a robust firewall management tool available for various Linux distributions. It provides a user-friendly interface for managing iptables, the packet filtering system within the Linux kernel. we will walk the fundamentals of setting up and configuring Firewalld using the firewall-cmd command-line utility.

Detailed documentation about Firewalld can be found at the provided link.

Basic Concepts in Firewalld

Firewalld introduces the concept of "zones," which dictate the behavior of the firewall based on the level of trust associated with the networks your system is connected to. Zones provide flexibility, enabling you to tailor rules depending on your environment. For instance, a laptop might need stricter rules on a public WiFi network while being more relaxed on a trusted home network. Predefined zones range from least trusted (e.g., drop, block) to most trusted (trusted, internal). The firewall-cmd utility facilitates the management of these zones.

Zones in Firewalld

In Firewalld, zones are a crucial concept that dictates how the firewall treats network traffic based on the level of trust associated with the networks your system is connected to. Each zone defines a set of rules that determine which traffic is allowed and which is denied. Firewalld allows you to assign different interfaces to different zones, allowing for a flexible approach to network security. Zones are particularly useful for systems that might move between different networks, such as laptops, and for segmenting trust levels on servers.

Default Zones

Firewalld comes with a set of predefined zones, each with a different level of trust. Here are the default zones provided by Firewalld, listed from least trusted to most trusted:

drop : This is the lowest level of trust. All incoming connections are dropped without a reply, and only outgoing connections are possible.
block : Similar to "drop," incoming connections are rejected with an ICMP message. Outgoing connections are allowed.
public : Represents public, untrusted networks. You allow selected incoming connections on a case-by-case basis. This zone is useful for public Wi-Fi networks.
external : Designed for external networks when your system is acting as a gateway. It configures NAT masquerading to keep your internal network private yet reachable.
internal : Used for the internal side of a gateway. This zone assumes more trustworthiness for the computers and allows some additional services.
dmz : Used for computers located in a DMZ (isolated computers that won't access the rest of your network). Only certain incoming connections are allowed.
work : Meant for work machines. You trust most computers on the network, and a few more services might be allowed.
home : Suitable for home environments. It implies a higher level of trust among computers, and more services will be accepted.
trusted : The most open option, to be used sparingly. It trusts all machines in the network.

Targets

Within each zone, there's a concept called "target." A target defines the default behavior of the firewall for incoming traffic. These targets are used to specify what happens when an incoming connection matches the rules of the zone. Here are the common targets used in Firewalld:

default : This is the default target. It allows the default behavior for the zone, which can be controlled further through rule definitions.
accept : Incoming traffic is accepted without restrictions.
drop : Incoming traffic is dropped without any response.
reject : Similar to "drop," but the system responds with an ICMP error message.
masquerade : Used for source NAT (Network Address Translation) to modify the source IP address of outgoing packets.
redirect : Used for destination NAT to redirect incoming packets to a different IP address and port.

Rule Permanence

Firewalld rules can be immediate (active during the current session) or permanent (persist after reboot). The --permanent flag designates permanent rules that apply across reboots. This separation allows testing rules in the current session before making them permanent.

Installing and Enabling Firewalld

To install Firewalld, use your package manager (e.g., sudo apt install firewalld). After installation, enable the service to start at boot:

sudo systemctl enable firewalld

It's recommended to configure your firewall rules and test them before enabling this behavior to avoid potential issues.

Verifying Firewalld Status

Check if Firewalld is up and running:

sudo firewall-cmd --state

A "running" status indicates that the firewall is operational with the default configuration.

Exploring Current Firewall Rules

Get the default zone:

firewall-cmd --get-default-zone

List active zones:

firewall-cmd --get-active-zones

View rules for a zone (e.g., "public"):

sudo firewall-cmd --zone=public --list-all

To move an interface to a different zone during the current session:

sudo firewall-cmd --zone=new-zone --change-interface=interface-name

Adjusting Default Zone

Change the default zone:

sudo firewall-cmd --set-default-zone=new-default-zone

Adding Services to Zones

List available services:

firewall-cmd --get-services

Add a service to a zone (e.g., "public"):

sudo firewall-cmd --zone=public --add-service=service-name

Make the change permanent:

sudo firewall-cmd --zone=public --permanent --add-service=service-name

Opening Ports for Specific Applications

Open a port for a zone (e.g., "public"):

sudo firewall-cmd --zone=public --add-port=port/protocol

Open a port range:

sudo firewall-cmd --zone=public --add-port=start-end/protocol

Defining Custom Services

Copy an existing service definition (e.g., SSH) to create a custom service:

sudo cp /usr/lib/firewalld/services/ssh.xml /etc/firewalld/services/custom-service.xml

Modify the custom service definition in /etc/firewalld/services/custom-service.xml.

Reload the firewall to apply changes:

sudo firewall-cmd --reload

Creating Your Own Zones

Create a new zone (e.g., "custom-zone"):

sudo firewall-cmd --permanent --new-zone=custom-zone

Reload the firewall to activate the new zone:

sudo firewall-cmd --reload

Assign interfaces to the new zone (if interface is not already assigned ):

sudo firewall-cmd --zone=custom-zone --add-interface=interface-name

Firewalld provides an effective way to manage firewall rules using zones and services. By understanding these concepts and the usage of the firewall-cmd utility, you can create tailored firewall configurations that cater to your network environment. Additionally, the installation of Firewalld with nftables enhances your firewall capabilities, contributing to improved security and network management.

Unveiling Linux Command's - rsync

Syam SV — Mon, 21 Aug 2023 05:42:15 +0000

Rsync (Remote Sync) is a command-line utility used for efficiently transferring and synchronizing files and directories between local and remote systems. It uses an algorithm to minimize the amount of data copied by only moving the portions of files that have changed.

Basic Syntax:

The basic syntax of the rsync command is as follows:

rsync [options] source destination

source: The source directory or file you want to transfer.
destination: The target directory or location where you want to copy the source.

Commonly Used Options:

-a or --archive: This option enables archive mode, which preserves file permissions, ownership, timestamps, and more. It's often used for full data synchronization.
-v or --verbose: Enables verbose output, showing details about the files being transferred.
-r or --recursive: Enables recursive mode, ensuring that all subdirectories and their contents are transferred.
--dry-run: Simulates the transfer without actually performing it. Useful for previewing what would be copied.
--delete: Deletes files at the destination that are not present in the source. Useful for maintaining exact synchronization.
-z or --compress: Compresses files during transfer, which can improve transfer speed over slow connections.

Use Cases and Examples:

Local Copy:

To copy files or directories locally, use the basic syntax:

rsync -av source_directory/ destination_directory/

Remote Copy:

To copy files or directories from a local system to a remote server:

rsync -av source_directory/ user@remote_server:/path/to/destination/

Remote Copy with SSH:

To copy files or directories from a local system to a remote server over SSH:

rsync -av -e "ssh -i /path/to/key.pem" source_directory/ user@remote_server:/path/to/destination/

rsync -av -e ssh source_directory/ user@remote_server:/path/to/destination/

Exclude Files or Directories:

To exclude specific files or directories from the transfer:

rsync -av --exclude="file_to_exclude" source_directory/ destination_directory/

Dry Run:

To preview the transfer without actually copying:

rsync -av --dry-run source_directory/ destination_directory/

Delete Unwanted Files:

To remove files at the destination that are not in the source:

rsync -av --delete source_directory/ destination_directory/

Compressed Transfer:

To enable compression during transfer:

rsync -avz source_directory/ user@remote_server:/path/to/destination/

Maintain Metadata:

To ensure metadata consistency during transfers:

rsync -av source_directory/ destination_directory/

Synchronize Remote Directory:

To synchronize a remote directory with a local one:

rsync -av user@remote_server:/path/to/source_directory/ local_destination/

Copying Remote to Local:

To copy files from a remote server to a local machine:

rsync -av user@remote_server:/path/to/source_directory/ local_destination/

Backup option in Rsync

Rsync’s --backup option can be used to store backups of important files. It’s used in along with the --backup-dir option, which specifies the directory where the backup files should be stored

rsync -a --delete --backup --backup-dir=/path/to/backups /path/to/source destination

Conclusion:

Rsync is a versatile tool for efficiently transferring and synchronizing files between local and remote systems. It provides various options that allow you to control the behavior of the transfer, maintain metadata consistency, exclude files, and even simulate transfers before executing them. Its ability to work over SSH ensures secure data transfers across networks, making it an essential tool for managing and backing up data in a Linux environment.

Unveiling Linux Command's - usermod

Syam SV — Mon, 21 Aug 2023 05:39:30 +0000

The usermod command in Linux is a powerful tool that helps system administrators modify various attributes of user accounts. These attributes include user groups, home directories, usernames, and more. It's like a tool that lets you change how a user works with the system.

Adding Users to Groups

Imagine you have a Linux server where you need to give specific users special permissions. This is where usermod comes in handy. You can add a user to an existing group using this command:

sudo usermod -aG <group-name> <username>

For instance, if you want to add a user named "alice" to the "developers" group, the command would look like this:

sudo usermod -aG developers alice

Moving User Home Directories

Home directories are where users store their personal files and settings. If you need to move a user's home directory to a different location, usermod can help:

sudo usermod -d <new-directory> <username>

Suppose you want to move the home directory of the user "bob" to "/newhome":

sudo usermod -d /newhome bob

Changing Usernames

Usernames might need to be changed for various reasons, like rebranding or making usernames consistent across systems. Usermod makes this process simple:

sudo usermod -l <new-username> <old-username>

For example, if you want to change the username "olduser" to "newuser":

sudo usermod -l newuser olduser

User Expiration

Security is crucial in user management. With usermod, you can set an expiration date for a user to enhance security:

sudo usermod -e <expiration-date> <username>

Suppose you want the password for the user "jane" to expire on January 1, 2024:

sudo usermod -e 2024-01-01 jane

Locking and unlocking user

Locking a user account prevents the user from accessing the system. Locking can be helpful in certain situations. To lock a user account using the usermod command:

sudo usermod -L <username>

Unlocking a user account is equally important, as you may need to restore access after resolving a situation. To unlock a user account:

sudo usermod -U <username>

Conclusion

In the world of Linux system administration, the usermod command plays a crucial role in managing user accounts effectively. Its ability to modify user attributes like groups, home directories, usernames, and password expiration dates empowers administrators to maintain a secure and organized system.

Unveiling Linux Command's - scp (Secure Copy)

Syam SV — Mon, 21 Aug 2023 05:37:11 +0000

SCP (Secure Copy) is a command-line utility in Unix-like operating systems that enables secure and efficient file transfers between a local and remote host or between two remote hosts. It is built on top of the SSH protocol, ensuring data confidentiality and integrity during the transfer process. SCP is widely used for transferring files and directories in a secure manner.

Basic Syntax:

scp [options] source destination

Common Options:

-r: Recursively copy directories and their contents.
-p: Preserve modification times, access times, and modes from the original files.
-P port: Specify a different port for SSH. Default is 22.
-i identity_file: Use an identity file (private key) for authentication.

Some common usecases

Copying a File from Local to Remote:

scp file.txt user@remotehost:/path/to/destination/

This copies the local file file.txt to the remote server at the specified path.

Copying a File from Remote to Local:

scp user@remotehost:/path/to/source/file.txt /local/destination/

This copies the remote file file.txt to the local machine at the specified path.

Copying a Directory Recursively:

scp -r directory/ user@remotehost:/path/to/destination/

The -r option allows you to copy the entire directory and its contents.

Copying with a Different Port:

scp -P 2222 file.txt user@remotehost:/path/to/destination/

This command specifies a non-default SSH port (2222) for the transfer.

Preserving File Metadata:

scp -p file.txt user@remotehost:/path/to/destination/

The -p option maintains the original modification times and permissions of the file.

Copying Between Two Remote Hosts:

scp user1@remotehost1:/file.txt user2@remotehost2:/path/to/destination/

This copies a file from one remote host to another.

Using Identity File for Authentication:

scp -i ~/.ssh/my_private_key.pem file.txt user@remotehost:/path/to/destination/

The -i option specifies the private key for SSH authentication.

Comparison with Other Tools:

SCP vs. rsync : SCP is suitable for simple one-time transfers, while rsync is more versatile for syncing and incremental transfers.

Conclusion:

The SCP command provides a secure and efficient way to transfer files and directories between local and remote hosts. Its use cases include simple file transfers, recursive directory transfers, specifying custom SSH ports, preserving file metadata, and more. By leveraging the SSH protocol, SCP ensures data security and integrity during the transfer process.

Unveiling Linux Command's - useradd & adduser

Syam SV — Mon, 21 Aug 2023 05:32:11 +0000

When it comes to managing user accounts on a Linux system, two commonly used commands are useradd and adduser. While both commands are used to create user accounts, they have distinct differences in terms of flexibility, user-friendliness, and functionalities. In this blog post, we'll delve into the nuances of each command and provide step-by-step guides on how to use them.

`useradd` Command

The useradd command is a fundamental utility for creating user accounts on Linux systems. It's a low-level command that allows system administrators to create new users with specific configurations. However, using useradd requires you to set various options manually, which can be more complex and time-consuming, especially for beginners.

To create a user named "newuser," use the following command

sudo useradd newuser

Set a password for the new user

sudo passwd newuser

To specify the home directory for the user, use the -d option

sudo useradd -d /home/customdir newuser

Assign a specific user ID (UID) using the -u option (replace UID with the desired ID):

sudo useradd -u UID newuser

To set an expiration date for the user account, use the -e option followed by the date in YYYY-MM-DD format

sudo useradd -e 2023-12-31 newuser

`adduser` Command

The adduser command is a higher-level utility designed to simplify the process of adding new user accounts. It prompts the user with a series of questions, allowing for interactive configuration. This makes it more user-friendly and suitable for those who are less familiar with command-line options

To start the interactive user creation process, type

sudo adduser newuser

The command will prompt you to set a password, full name, phone number, etc., for the new user. You can specify additional information such as the home directory, user groups, and expiration date for the account

Conclusion

In summary, both the useradd and adduser commands serve the purpose of creating user accounts on Linux systems. The choice between them depends on your level of familiarity with command-line options and the degree of user interaction you desire. If you're comfortable with configuring options manually, useradd offers fine-grained control. On the other hand, if you prefer a more user-friendly and interactive approach, adduser is a better choice.

Regardless of the command you choose, managing user accounts is a critical aspect of Linux system administration. Select the command that aligns with your needs and expertise to efficiently create and manage user accounts on your system.

Unveiling Linux Command's - find

Syam SV — Sat, 19 Aug 2023 14:28:13 +0000

Searching for files on your Linux system can sometimes feel like searching for a needle in a haystack. The find command is here to make your file-finding tasks easy. In this post, we'll walk you through various scenarios where the find command becomes very useful.

Finding files by name

Ever found yourself hunting for a file but forgetting where you stashed it? The find command can help you pinpoint it. When you're in your terminal, type

find /path/to/search -name "filename"

Just replace /path/to/search with your starting directory and filename with the elusive file's name.

Finding files by size

Sometimes you're dealing with large files, and sometimes it's the tiny ones causing a stir. find can help with that too! To locate files based on their size, use

find /path/to/search -size +size_unit

Replace/path/to/search with your directory and size_unit with the size you're after (like 10M for 10 megabytes). To find small files, use - instead of +.

Finding files by user

Who's the owner of that file? find can answer that. To discover files owned by a specific user or group

find /path/to/search -user username

Replace /path/to/search with your directory and username with the owner's name. Similar to the user scenario, you can also use -group groupname to find files owned by a particular group.

Finding files by permission

Permissions can be quite the puzzle. But findcan help you unravel it. To identify files with specific permissions, type:

find /path/to/search -perm permissions

Here, /path/to/search is your directory, and permissions are the numeric values (like 755 for read, write, and execute). If you want files with any of the specified permission bits, use -perm /permissions.

Finding files by date and time

The find command help you to navigate through time and locate files based on their access, modification, or change times.

find /path/to/search -atime/-ctime/-mtime +/-time_unit

Replace /path/to/search with your directory, pick atime, ctime, or mtime, and adjust +/-time_unit to specify the time frame.

Following are some example cases to understand

Find Recently Modified Files in the a directory

Imagine you've made some recent changes to your system configuration files in a directory, and you want to identify files that have been modified within the last 10 minutes

find /path/to/search  -mmin -10

This command will provide you with a list of files in the /etc directory that have been modified within the last 10 minutes.

Locate Recently Changed files

To find files that have been changed within the last 2 days across multiple important directories, use this find command

find /usr/bin /usr/sbin -ctime -2

By executing this command, you'll obtain a list of files that have undergone changes in the specified time frame.

Identify Unused Files in Web Directories

When managing websites, it's important to keep track of files that haven't been accessed for a while. For instance, let's say you want to find files in the /var/www directory that haven't been accessed for over 300 days. Here's the find command to achieve that:

find /var/www -atime +300

Upon executing this command, you'll receive a list of files within the specified directories that meet the time-based criteria.

Finding files and executing commands

The find command is not just about discovering files; it's also about taking action on them. This is where the -exec flag comes into play. With it, you can execute a command on each file that matches your search criteria.

find /path/to/search -name "filename" -exec command {} \;

For example, find text files and print their contents

find /home/user/documents -name "*.txt" -exec cat {} \;

Interactively Approve Actions

Sometimes, before making changes to files, you want to be sure. The -ok flag in find enables an interactive mode that asks for your confirmation before executing a command on each file.

find /path/to/search -name "filename" -ok command {} \;

For example safely deleting files

find /home/user/trash_files -name "*~" -ok rm {} \;

With these scenarios, find becomes a tool not only for locating files but also for performing actions on them, whether you're printing file contents or confirming deletions. It adds a layer of efficiency and control to your file management tasks

DEV Community: Syam SV

Rust for Gophers, Lesson 3: Structs, Enums, and Match

1. Structs

Tuple structs and the newtype pattern

derive: opting in to behaviour

2. impl blocks: methods and constructors

3. Enums: the feature Go doesn't have

4. Option<T>: no more nil

Everyday ways to handle an Option

5. Pattern matching in depth

The pattern toolbox

if let, let else, while let

6. Exercise: a stack, and an RPN calculator on top of it

Part A: the stack

Part B: the calculator

Hints (read only when stuck)

Rust for Gophers, Lesson 2: Ownership and Borrowing

1. Why ownership exists

2. The three rules, moves, and Drop

Moves

Copy vs Clone

Drop: defer that you can't forget

3. Borrowing: references without ownership

The one rule of borrowing

The Go bug this prevents

Borrows end at their last use

No dangling references

4. Slices, and String vs &str

Two string types

UTF-8: bytes are not characters

5. Choosing function signatures

6. Compiler error drills

7. Exercise: wordy, a word counter

Requirements

Hints (read only when stuck)

Rust for Gophers, Lesson 1: Hello, Cargo

The roadmap

1. Setup and tooling

Creating a project

The commands you will type every day

2. Hello world, dissected

3. Core basics, the Go programmer's way

Variables are immutable by default

Shadowing

Scalar types

Compound types

Functions, and the big idea: everything is an expression

Control flow

match: switch with superpowers

4. Testing from day one

5. Your exercise: fizzbuzz CLI

Requirements

Hints (read only when stuck)

Unveiling Linux Command's - sar

What is SAR?

Checking I/O and Transfer Rate

Paging Statistics

Network Numbers

Load and Queue

Memory and Swap Info

CPU Usage

Page Swapping

Conclusion

Unveiling Linux Command's - dmesg

Basic Usage

Severity based filtering

Continuous monitoring

Clearing the kernel ring buffer

Formatting & Mounting Storage Volumes

Listing and Identifying Storage Devices

Creating a Partition Table and Partitions with fdisk

Launching fdisk

Creating a New Partition Table

Creating Partitions

Formatting a Storage Device

Mounting the Storage Volume

Analyzing Disk Usage with ncdu

Automating Mounts with /etc/fstab

Firewalld Basics and Usage with firewall-cmd:

Basic Concepts in Firewalld

`derive`: opting in to behaviour

2. `impl` blocks: methods and constructors

4. `Option<T>`: no more nil

Everyday ways to handle an `Option`

`if let`, `let else`, `while let`

Drop: `defer` that you can't forget

4. Slices, and `String` vs `&str`

7. Exercise: `wordy`, a word counter

`match`: switch with superpowers

5. Your exercise: `fizzbuzz` CLI

`useradd` Command

`adduser` Command