DEV Community: OdaloV

A Go Dev's First Month with JavaScript

OdaloV — Fri, 24 Jul 2026 14:18:15 +0000

I learned Go first. When I started picking up JavaScript, I assumed it would just be "different words for the same ideas" I already knew. A week in, I realized it's not just different words, it's a different way of thinking about code entirely. Here's what stood out most in that first week.

Declaring variables: `:=` vs `let`/`const`

In Go, this is second nature by the time you've written a few programs:

count := 0
name := "Amina"

JavaScript has its own version, but it looks nothing like it:

let count = 0;
const name = "Amina";

My fingers kept typing := out of habit, which JavaScript just doesn't understand at all. And there's no single equivalent, JS gives you a choice between let (reassignable) and const (not reassignable), where Go's := doesn't make that distinction for you upfront.

Types are more of a suggestion than a rule

Go locks in a variable's type the moment you declare it:

value := "hello"
value = 42 // compile error

JavaScript doesn't care:

let value = "hello";
value = 42; // totally fine

This was the biggest adjustment for me, not because it's hard, but because nothing stops you. In Go, the compiler catches a mistake like this before the program even runs. In JavaScript, the same mistake might run just fine and only cause problems three functions later, somewhere completely unrelated to where the actual issue started.

`undefined` where Go would give you a zero value

Go never leaves a variable truly empty, every type has a default:

var name string  // ""
var count int    // 0

JavaScript has an actual concept of "nothing was assigned":

let name;
console.log(name); // undefined

At first this felt like less to worry about, no need to think about what a "default" looks like. Then I ran into null as well, which is different from undefined but similarly means "empty," and I realized JavaScript actually gives you two ways to represent nothing instead of Go's one predictable zero value. Keeping track of which parts of my code might produce undefined versus null versus an actual value took more mental effort than Go's zero values ever did.

Curly braces, but looser about it

if count > 0 {
    fmt.Println("positive")
}

if (count > 0) {
  console.log("positive");
}

JavaScript wants parentheses around the condition, Go doesn't. Small thing, but my hands kept leaving them out during that first week.

The bigger surprise: JavaScript will run code with unused variables, unused function parameters, and even unreachable code without complaint. Go refuses to compile if you've declared something you never use. I didn't realize how much I'd come to rely on that safety net until it wasn't there.

Functions: fewer rules, but also fewer guarantees

func add(a int, b int) int {
    return a + b
}

function add(a, b) {
  return a + b;
}

No types to declare on the parameters, which felt freeing at first. It stopped feeling that way the first time I called add("2", 3) and got "23" back instead of an error. JavaScript will coerce values instead of stopping you, where Go would've refused to compile the mismatch entirely.

Go's multiple return values also don't carry over. In Go, error handling is built into how a function returns:

func divide(a, b int) (int, error) {
    if b == 0 {
        return 0, errors.New("cannot divide by zero")
    }
    return a / b, nil
}

JavaScript reaches for try/catch instead, or a rejected Promise for anything asynchronous:

function divide(a, b) {
  if (b === 0) {
    throw new Error("cannot divide by zero");
  }
  return a / b;
}

try {
  const result = divide(10, 0);
} catch (err) {
  console.log("Error:", err.message);
}

Neither approach is wrong, but switching from checking err != nil after every call to wrapping things in try/catch blocks was a genuine shift in how I thought about where failures could happen.

Semicolons, now optional-ish

Go doesn't want you to type semicolons at all, the compiler inserts them for you. JavaScript technically has automatic semicolon insertion too, but most style guides still expect you to type them yourself:

const name = "Amina";
let count = 0;

Leaving them off doesn't break anything most of the time, but it's inconsistent enough that I just kept typing them to be safe.

What I'm taking into week two

The freedom of not declaring types is genuinely convenient for quick scripts, and genuinely risky for anything larger, since nothing catches a type mistake until it actually runs.
undefined and null both existing means I have to think about which one my code might actually produce, something Go's single zero-value concept never required.
try/catch is a different mental model from Go's explicit error returns, not just a different keyword for the same idea.
Async in JavaScript, async/await and Promises, doesn't map onto goroutines and channels at all. That one's going to take longer than a week to feel natural.

Coming from Go, JavaScript's flexibility felt like a relief at first and a little unsettling once I saw how much it lets slide. The syntax differences were the easy part to notice. The harder part was unlearning the assumption that the language would stop me before I made a mistake.

Challenges of working on two languages at the same time,ft Go and JS

OdaloV — Wed, 22 Jul 2026 01:07:13 +0000

Nobody tells you this part: when you're learning two languages at once, the hardest bugs aren't logic bugs. They're the moments where your fingers type the wrong language's syntax faster than your brain can stop them.

If you're picking up Go while still writing JavaScript regularly, maybe a frontend project in one tab and a backend service in another, here's the whiplash you're probably already feeling, and what actually helps.

The variable declaration trap

JavaScript gives you let, const, and var. Go gives you var too, but also := for short variable declarations inside functions. It's an easy swap to fumble:

// JavaScript
const name = "Amina";
let count = 0;

// Go
name := "Amina"
var count int

The muscle memory clash goes both ways, writing const in a .go file , or writing := in JavaScript out of habit. Go's := only works inside function bodies too, which adds another layer: package-level variables need the full var form.

Static typing

This is the bigger mental gear-shift, and it's not really about syntax, it's about what the language expects from you.

In JavaScript, you can do this without thinking twice:

function add(a, b) {
  return a + b;
}
add(2, 3);      // 5
add("2", "3");  // "23"

In Go, the compiler stops you before you even run anything:

func add(a int, b int) int {
    return a + b
}

Try passing a string where an int is expected and Go just won't compile. Coming from JS, where type coercion quietly does something for you , Go's refusal to guess feels strict at first. After a while, it stops feeling strict and starts feeling like the compiler is doing your job for you.

Zero values vs undefined/null

This one causes real confusion, not just typo-level mistakes. In JavaScript, an unassigned variable is undefined, and you can explicitly set something to null. In Go, every type has a zero value, variables are never "empty" the way JS variables can be:

var count int       // 0, not undefined
var name string      // "", not undefined
var active bool       // false
var user *User        // nil (this one's actually similar to JS's null)

The gotcha: if you're used to checking if (value) in JS to catch "nothing was set," that instinct doesn't transfer cleanly. A Go int that's 0 might mean "not set" or it might genuinely mean zero, the language won't tell you which, so you have to design for it .

Functions look similar until they don't

const double = (x) => x * 2;
function double(x) { return x * 2; }

double := func(x int) int { return x * 2 }
func double(x int) int { return x * 2 }

Go doesn't have arrow function shorthand, and every parameter needs an explicit type. Multiple return values are where it really diverges, this is idiomatic Go and has no clean JS equivalent:

func divide(a, b int) (int, error) {
    if b == 0 {
        return 0, errors.New("division by zero")
    }
    return a / b, nil
}

result, err := divide(10, 2)
if err != nil {
    // handle it
}

JS developers reach for try/catch or reject a Promise. Go developers check err != nil after basically every function call that can fail. It feels verbose at first; it becomes automatic fast.

Async is a completely different animal, not just different syntax

This is the one that trips people up longest, because it's not a vocabulary problem, it's a different model entirely.

JavaScript is single-threaded with an event loop. async/await and Promises manage when code runs, not where:

async function fetchUser(id) {
  const res = await fetch(`/users/${id}`);
  return res.json();
}

Go has actual concurrent execution via goroutines, and channels for communication between them:

func fetchUser(id int, resultChan chan<- User) {
    user := someBlockingCall(id)
    resultChan <- user
}

go fetchUser(1, results)
user := <-results

There's no direct JS analog to a goroutine, it's not "async but faster," it's genuinely a different concurrency model (real parallelism across OS threads, managed by Go's scheduler, vs. JS's cooperative single-threaded event loop). Trying to map one onto the other conceptually causes more confusion than just accepting they're different tools for different problems.

Braces, semicolons, and the small stuff

Minor, but it adds up over a day of context-switching:

Go doesn't want semicolons at the end of statements (the compiler inserts them automatically); JS wants them, sort of, depending on who you ask about ASI.
Go is strict about unused variables and unused imports, code that would just sit there unused in JS won't even compile in Go.
Go's if statements don't use parentheses around the condition; JS requires them.

// Go
if count > 0 {
    // ...
}

// JavaScript
if (count > 0) {
  // ...
}

None of these are hard individually. They're just the kind of thing that quietly wrecks your flow when you're bouncing between a frontend tab and a backend tab in the same afternoon.

What actually helps

Separate your terminals/windows by language, not just by project, reduces the "which file am I even in" moment.
Lean into the differences instead of looking for symmetry. Go and JS solve similar problems in genuinely different ways (typing, concurrency, error handling). Trying to make one feel like the other causes more confusion than accepting they're different tools.
Let the compiler be your friend in Go. Every "wait, why won't this compile" moment is usually catching something JS would've let through silently and let you debug at runtime instead.
Write small, throwaway snippets when switching contexts, a 5-line Go file just to remind your hands what := feels like before diving into a bigger task.

The syntax whiplash is real, and it doesn't fully go away, it just gets faster to recover from. The confusion isn't a sign you're doing something wrong; it's just what it feels like to hold two different mental models at once. Give it time, and your fingers eventually learn which language they're in before your brain has to think about it.

Running PostgreSQL with Docker

OdaloV — Wed, 22 Jul 2026 00:54:32 +0000

Installing Postgres directly on your machine works, but it gets messy fast once you're juggling multiple projects that each want different versions, extensions, or seed data. Docker sidesteps all of that you get a clean, disposable Postgres instance per project, and your host machine stays untouched.

This guide covers running Postgres in Docker for local development: quick one-off containers, docker-compose for anything you'll come back to, persistent data, and a few things that trip people up.

1. The quickest way to get a Postgres instance running

docker run --name my-postgres \
  -e POSTGRES_PASSWORD=secret \
  -e POSTGRES_USER=devuser \
  -e POSTGRES_DB=myapp \
  -p 5432:5432 \
  -d postgres:16

Breaking that down:

--name my-postgres — a friendly name so you can reference the container later instead of a random hash
POSTGRES_PASSWORD — required; the container won't start without it
POSTGRES_USER / POSTGRES_DB — optional; default to postgres if omitted
-p 5432:5432 — maps container port 5432 to host port 5432
-d — detached, runs in the background
postgres:16 — pin a version; avoid latest since it can silently jump major versions later

Check it's running:

docker ps

Connect with psql (if installed locally) or from inside the container:

docker exec -it my-postgres psql -U devuser -d myapp

2. Using docker-compose for anything persistent

For a real project, docker-compose.yml is the better default , it's version-controlled, reproducible, and easy to extend with more services later (Redis, pgAdmin, your app itself).

services:
  db:
    image: postgres:16
    container_name: myapp-postgres
    restart: unless-stopped
    environment:
      POSTGRES_USER: devuser
      POSTGRES_PASSWORD: secret
      POSTGRES_DB: myapp
    ports:
      - "5432:5432"
    volumes:
      - pgdata:/var/lib/postgresql/data

volumes:
  pgdata:

Start it:

docker compose up -d

Stop it (keeps data):

docker compose down

Stop and wipe data:

docker compose down -v

3. Why the volume matters

Without a named volume, all data lives inside the container's writable layer , delete the container, lose the database. The pgdata:/var/lib/postgresql/data mapping above stores Postgres's actual data files in a Docker-managed volume that survives container restarts and even docker compose down (without -v).

To see where Docker keeps it on disk:

docker volume inspect myapp_pgdata

If you'd rather control the exact host path :

volumes:
  - ./pgdata:/var/lib/postgresql/data

4. Seeding initial data

Postgres's official image runs any .sql or .sh files placed in /docker-entrypoint-initdb.d/ , but only on first startup, when the data directory is empty.

services:
  db:
    image: postgres:16
    environment:
      POSTGRES_USER: devuser
      POSTGRES_PASSWORD: secret
      POSTGRES_DB: myapp
    volumes:
      - pgdata:/var/lib/postgresql/data
      - ./init:/docker-entrypoint-initdb.d

volumes:
  pgdata:

Drop a file at ./init/001-schema.sql with your CREATE TABLE statements, and it runs automatically the first time the container spins up with a fresh volume. This is a solid pattern for local dev seed data, though it won't run again once the volume already has data , if you need to reseed, docker compose down -v first.

5. Health checks

If you're running your Go/Node/whatever app as another service in the same compose file, a health check stops it from starting before Postgres is actually ready to accept connections:

services:
  db:
    image: postgres:16
    environment:
      POSTGRES_USER: devuser
      POSTGRES_PASSWORD: secret
      POSTGRES_DB: myapp
    ports:
      - "5432:5432"
    volumes:
      - pgdata:/var/lib/postgresql/data
    healthcheck:
      test: ["CMD-SHELL", "pg_isready -U devuser -d myapp"]
      interval: 5s
      timeout: 5s
      retries: 5

  app:
    build: .
    depends_on:
      db:
        condition: service_healthy
    environment:
      DATABASE_URL: postgres://devuser:secret@db:5432/myapp

volumes:
  pgdata:

Note the connection string from app uses db as the host, not localhost , inside Docker's network, services reach each other by container/service name.

6. Common gotchas

"password authentication failed" after changing env vars. Postgres only applies POSTGRES_PASSWORD/POSTGRES_USER on first initialization of an empty data directory. If you change them later, the existing volume still has the old credentials. You'll need to either update the password inside Postgres directly (ALTER USER devuser WITH PASSWORD 'newpass';) or wipe the volume and start fresh.
Port already in use. If Postgres is also installed locally, port 5432 will conflict. Either stop the local service or map to a different host port: -p 5433:5432.
Data "disappearing" between runs. Almost always means no volume was mounted, or a different volume name was used across runs. Double-check docker volume ls.
Connecting from your host app vs. a containerized app. From your host machine , use localhost:5432. From another container in the same compose file, use the service name (db:5432).

7. Quick reference

# Start
docker compose up -d

# View logs
docker compose logs -f db

# Open a psql shell
docker exec -it myapp-postgres psql -U devuser -d myapp

# Stop (keep data)
docker compose down

# Stop and delete data
docker compose down -v

# Back up a database
docker exec myapp-postgres pg_dump -U devuser myapp > backup.sql

# Restore
cat backup.sql | docker exec -i myapp-postgres psql -U devuser -d myapp

For local development, docker-compose with a named volume covers almost everything you need: a clean, disposable Postgres instance, seed data on first run, and health checks so dependent services don't race ahead of the database. It's a small setup cost that saves you from "works on my machine" version mismatches down the line.

GORM: Dev's Guide to Go's Most Popular ORM

OdaloV — Wed, 22 Jul 2026 00:38:39 +0000

If you're working with Go services that talk to a relational database, chances are you've bumped into GORM. It's the most widely used ORM in the Go ecosystem, and for good reason. It wraps a lot of the tedium of database/sql ,manual scanning, hand-written migrations, string-built queries in a much friendlier API.

This article walks through GORM from setup to the patterns you'll actually use day to day: models, migrations, CRUD, associations, transactions, and a few gotchas that trip people up.

Why reach for an ORM in Go ?

Go's standard database/sql package is deliberately low-level. You write SQL strings, manually scan rows into structs, and manage connections yourself. That's fine for small projects, but it gets repetitive fast once you have a dozen tables and endpoints that all need similar create/read/update/delete logic.

GORM sits on top of database/sql and gives you:

Struct-based models mapped to tables
Auto migrations
A chainable query builder
Associations (has-one, has-many, many-to-many, belongs-to)
Hooks (before/after create, update, delete)
Built-in support for transactions, connection pooling, and prepared statements

It supports PostgreSQL, MySQL, SQLite, SQL Server, and more, through swappable drivers.

Installation

go get -u gorm.io/gorm
go get -u gorm.io/driver/postgres

Swap postgres for mysql, sqlite, or sqlserver depending on your database.

Connecting to a database

package main

import (
    "log"

    "gorm.io/driver/postgres"
    "gorm.io/gorm"
    "gorm.io/gorm/logger"
)

func main() {
    dsn := "host=localhost user=postgres password=secret dbname=myapp port=5432 sslmode=disable"

    db, err := gorm.Open(postgres.Open(dsn), &gorm.Config{
        Logger: logger.Default.LogMode(logger.Info), 
    })
    if err != nil {
        log.Fatalf("failed to connect to database: %v", err)
    }

    sqlDB, err := db.DB()
    if err != nil {
        log.Fatalf("failed to get generic db object: %v", err)
    }

    sqlDB.SetMaxOpenConns(25)
    sqlDB.SetMaxIdleConns(10)
}

That db.DB() call gives you the underlying *sql.DB, which is where connection pool settings live. It's easy to forget this step and end up with an ORM that opens far more connections than your database can handle.

Defining models

GORM models are plain structs with tags:

type User struct {
    ID        uint   `gorm:"primaryKey"`
    Name      string `gorm:"size:100;not null"`
    Email     string `gorm:"uniqueIndex;not null"`
    Posts     []Post
    CreatedAt time.Time
    UpdatedAt time.Time
    DeletedAt gorm.DeletedAt `gorm:"index"`
}

type Post struct {
    ID       uint   `gorm:"primaryKey"`
    Title    string `gorm:"size:255;not null"`
    Body     string
    UserID   uint
}

CreatedAt / UpdatedAt are populated automatically by GORM , no extra code needed.
DeletedAt gorm.DeletedAt enables soft deletes. Calling db.Delete(&user) won't actually remove the row; it sets deleted_at and every future query filters those rows out automatically.
Field-level tags (size, not null, uniqueIndex) get translated into actual SQL constraints during migration.

Auto migrations

db.AutoMigrate(&User{}, &Post{})

This creates tables if they don't exist and adds missing columns/indexes. It won't drop columns or change types that could cause data loss , which is a deliberate safety choice, but it also means AutoMigrate isn't a full substitute for a proper migration tool once you're in production. Many teams use it for local dev and rely on something like golang-migrate or atlas for production schema changes.

Basic CRUD

Create:

user := User{Name: "Amina Otieno", Email: "amina@example.com"}
result := db.Create(&user)
if result.Error != nil {
    log.Println(result.Error)
}
log.Println("New user ID:", user.ID)

Read:

var user User
db.First(&user, 1)                   
db.First(&user, "email = ?", "amina@example.com")

var users []User
db.Where("name LIKE ?", "%Otieno%").Find(&users)

Update:

db.Model(&user).Update("name", "Amina O.")

// Update multiple fields
db.Model(&user).Updates(User{Name: "Amina O.", Email: "new@example.com"})

Note: Updates with a struct only updates non-zero fields. If you need to set a field to its zero value (empty string, 0, false), use a map[string]interface{} instead.

Delete:

db.Delete(&user)

Associations and preloading

Given the User/Post relationship above, GORM can eager-load associations to avoid N+1 query problems:

var users []User
db.Preload("Posts").Find(&users)

This runs two queries total (one for users, one for all related posts), rather than one query per user. If you only need a subset of associated records, Preload accepts conditions too:

db.Preload("Posts", "created_at > ?", someDate).Find(&users)

For many-to-many relationships, GORM manages the join table for you:

type Tag struct {
    ID    uint
    Name  string
    Posts []Post `gorm:"many2many:post_tags;"`
}

Transactions

err := db.Transaction(func(tx *gorm.DB) error {
    if err := tx.Create(&user).Error; err != nil {
        return err // rolls back
    }
    if err := tx.Create(&Post{Title: "First post", UserID: user.ID}).Error; err != nil {
        return err 
    }
    return nil 
})
if err != nil {
    log.Println("transaction failed:", err)
}

This is the pattern you want anywhere multiple writes need to succeed or fail together — say, deducting a balance and recording a ledger entry.

Hooks

GORM calls certain methods automatically if your model defines them:

func (u *User) BeforeCreate(tx *gorm.DB) error {
    u.Email = strings.ToLower(u.Email)
    return nil
}

Available hooks include BeforeCreate, AfterCreate, BeforeUpdate, AfterUpdate, BeforeDelete, AfterDelete, and their *Save equivalents. Useful for normalization, validation, or audit logging without cluttering your handler code.

Things worth knowing

Zero values in updates. As mentioned above, Updates() with a struct silently skips zero-valued fields. This bites people when they try to clear a field to "" or 0.
Soft delete surprises. If DeletedAt is present on a model, every Find/First/Where call filters out soft-deleted rows by default. To include them, use .Unscoped().
N+1 queries. Forgetting Preload on associations is the most common performance issue in GORM codebases. Turn on logger.Info mode in development so you can actually see the queries GORM is generating.
Context propagation. Use db.WithContext(ctx) in request-scoped code so query cancellation and timeouts actually work with your HTTP handler's context.
Connection pool tuning. Don't skip SetMaxOpenConns/SetMaxIdleConns , the defaults aren't tuned for production load.

GORM won't eliminate the need to understand SQL , and you shouldn't want it to , but it removes a lot of boilerplate around scanning rows, building migrations, and wiring up associations. For most Go backend services, especially ones backed by PostgreSQL, it hits a solid balance between productivity and control.

Postgres vs SQLite

OdaloV — Thu, 16 Jul 2026 14:17:08 +0000

SQLite is one of the most deployed pieces of software on the planet ,it's everywhere. It's also a genuinely great database for a huge range of apps. So why would anyone reach for Postgres instead?

The honest answer: because SQLite and Postgres aren't really competing for the same job. One is an embedded file format with a SQL interface. The other is a client-server database designed to be shared. Once you understand that distinction, it's obvious when each one wins.

Concurrency

SQLite locks the entire database file when a write happens. Older versions blocked all other writers (and in some modes, readers) until that write finished. Newer WAL mode improves concurrent reads during writes, but SQLite still fundamentally serializes writes there's no getting around that it's one writer at a time.

Postgres uses MVCC (multi-version concurrency control), so readers never block writers and writers don't block readers. Multiple clients can write to different rows simultaneously without stepping on each other.

-- Postgres: two clients can safely update different rows of the same table
-- at the same time, with no manual locking required
BEGIN;
UPDATE accounts SET balance = balance - 100 WHERE id = 1;
UPDATE accounts SET balance = balance + 100 WHERE id = 2;
COMMIT;

If your app has more than one process or more than a handful of concurrent users writing data, this alone usually settles the decision.

It's a server, not a file

SQLite reads and writes a single file on disk from inside your application process. That's its superpower for embedded use — and its ceiling for anything else. There's no network protocol, no remote access, no separate process to manage.

Postgres runs as its own server that any number of applications, services, or machines can connect to over the network:

# Any service on your network can connect to the same database
psql "postgresql://app_user:password@db.internal:5432/production"

This is the difference between "one app owns this data" and "this data is a shared resource for your whole system" , which matters the moment you have more than one service (an API, a background worker, an analytics job) that all need the same data.

A real type system

SQLite is dynamically typed by default ,a column declared INTEGER will still accept text unless you explicitly opt into strict typing (added in SQLite 3.37+). Postgres enforces types strictly by default, and gives you far more of them:

-- Postgres: rich, enforced types out of the box
CREATE TABLE users (
  id UUID PRIMARY KEY DEFAULT gen_random_uuid(),
  email TEXT UNIQUE NOT NULL,
  roles TEXT[] DEFAULT '{}',
  metadata JSONB,
  created_at TIMESTAMPTZ DEFAULT now()
);

Arrays, JSONB, UUIDs, ranges, network address types, enums. These aren't bolted on, they're core to how Postgres models data.

Querying power

SQLite's SQL support is deliberately minimal, which keeps it small and fast to embed. Postgres supports the full range of modern SQL plus extensions:

-- Window functions: rank each order within a customer's history
SELECT
  customer_id,
  order_id,
  total,
  RANK() OVER (PARTITION BY customer_id ORDER BY total DESC) AS spend_rank
FROM orders;

-- Full-text search built into the engine, no extra service required
SELECT title FROM articles
WHERE to_tsvector('english', body) @@ to_tsquery('database & performance');

Things like materialized views, recursive CTEs at scale, PostGIS for geospatial data, and pgvector for embeddings simply aren't in SQLite's scope.

Access control

SQLite has no concept of users or permissions, if a process can read the file, it can read (and write) everything in it. Access control is whatever your filesystem gives you.

Postgres has real roles, grants, and even row level security:

-- Restrict a role to only see rows belonging to their own tenant
CREATE POLICY tenant_isolation ON documents
  USING (tenant_id = current_setting('app.tenant_id')::uuid);

If different users or services need different levels of access to the same data, Postgres can enforce that at the database layer instead of trusting every client to behave.

Where SQLite still wins

None of this makes SQLite a worse database — it makes it a different one:

Zero ops. No server to install, patch, or monitor.
Portability. A whole database is one file you can copy, email, or check into version control.
Speed for local, single-writer workloads. Mobile apps, desktop apps, browser storage, embedded devices, CLI tools, and tests are often faster and simpler with SQLite.
Simplicity. For a prototype or a small app that will only ever run as one process, standing up Postgres is pure overhead.

The actual decision

Ask one question: does more than one process need to write to this data?

If no — one app, one process, local file — SQLite is usually the better call.
If yes — multiple services, multiple users, anything accessed over a network . Postgres is built for exactly that.

Plenty of successful products start on SQLite and migrate to Postgres later, and that's a fine path. The mistake is picking SQLite for a multi-writer, networked system because it seemed simpler at the start, and picking Postgres for a single-user local app because it seemed more "production-grade." Match the tool to the shape of the problem, not its reputation.

Building on the Blockchain: A Developer's Guide to Solidity & Smart Contracts

OdaloV — Mon, 01 Jun 2026 17:48:28 +0000

"Code is law — and on Ethereum, it runs forever."

What Is a Smart Contract?

A smart contract is a self-executing program stored on a blockchain. It runs automatically when predefined conditions are met. No middlemen, no downtime, no censorship.

Immutable (once deployed, the logic doesn't change)
Transparent (anyone can read the code)
Trustless (no central authority needed)
Global (accessible from anywhere on Earth)

Solidity

Solidity is the primary language for writing smart contracts on Ethereum and EVM-compatible chains like Polygon, BNB Chain, Avalanche, Base and others.

It's a statically-typed, contract-oriented language with syntax that feels familiar if you've used JavaScript, C++, or Java.

// SPDX-License-Identifier: MIT
pragma solidity ^0.8.20;

contract HelloBlockchain {
    string public message = "gm, world";

    function setMessage(string calldata _msg) external {
        message = _msg;
    }
}

Core Concepts

1. State Variables & Storage

Everything stored on-chain costs gas. Be deliberate.

contract Bank {
    mapping(address => uint256) public balances; // stored on-chain
    uint256 public totalDeposits;
}

2. Functions & Visibility

Modifier	Who Can Call
`public`	Anyone (internal + external)
`external`	Only from outside the contract
`internal`	Only this contract + children
`private`	Only this contract

3. Payable Functions — Receiving ETH

function deposit() external payable {
    balances[msg.sender] += msg.value;
    totalDeposits += msg.value;
}

msg.sender = the caller's address

msg.value = ETH sent with the call (in wei)

4. Events — Your On-Chain Logs

Events are cheap to emit and essential for off-chain apps to track activity.

event Deposited(address indexed user, uint256 amount);

function deposit() external payable {
    balances[msg.sender] += msg.value;
    emit Deposited(msg.sender, msg.value);
}

5. Modifiers — Reusable Guards

modifier onlyOwner() {
    require(msg.sender == owner, "Not the owner");
    _;
}

function withdraw(uint256 amount) external onlyOwner {
    payable(owner).transfer(amount);
}

A Real Example: Simple Token

// SPDX-License-Identifier: MIT
pragma solidity ^0.8.20;

contract SimpleToken {
    string public name = "DevToken";
    string public symbol = "DEV";
    uint8 public decimals = 18;
    uint256 public totalSupply;

    mapping(address => uint256) public balanceOf;

    event Transfer(address indexed from, address indexed to, uint256 value);

    constructor(uint256 _initialSupply) {
        totalSupply = _initialSupply * 10 ** decimals;
        balanceOf[msg.sender] = totalSupply;
    }

    function transfer(address to, uint256 amount) external returns (bool) {
        require(balanceOf[msg.sender] >= amount, "Insufficient balance");
        balanceOf[msg.sender] -= amount;
        balanceOf[to] += amount;
        emit Transfer(msg.sender, to, amount);
        return true;
    }
}

This is the essence of an ERC-20 token. The real standard adds approve, transferFrom, and allowance but this gives you the foundation.

Security: The Non-Negotiables

Smart contract bugs are permanent and public. The stakes are high.

Reentrancy Attack

The infamous bug behind the $60M DAO hack (2016).

// VULNERABLE 
function withdraw() external {
    uint256 amount = balances[msg.sender];
    (bool success,) = msg.sender.call{value: amount}(""); // external call BEFORE state update
    balances[msg.sender] = 0; // too late
}

// SAFE 
function withdraw() external {
    uint256 amount = balances[msg.sender];
    balances[msg.sender] = 0;           // 1. Update state
    (bool success,) = msg.sender.call{value: amount}(""); // 2. Then interact
    require(success, "Transfer failed");
}

Rule: Always update state before making external calls.

Other Common Pitfalls

Integer overflow/underflow — Solidity 0.8+ handles this automatically with built-in checks
tx.origin vs msg.sender — Never use tx.origin for authorization
Unchecked return values — Always check the return value of call()
Timestamp dependence — block.timestamp can be manipulated slightly by miners

The Developer Toolchain

Tool	Purpose
Hardhat	Local dev environment, testing, deployment
Foundry	Blazing-fast testing in Solidity itself
Remix IDE	Browser-based IDE, great for prototyping
OpenZeppelin	Battle-tested contract libraries
Ethers.js / Viem	JavaScript libraries to interact with contracts
Alchemy / Infura	Node providers for mainnet/testnet access

Quick Start with Hardhat

mkdir my-contract && cd my-contract
npm init -y
npm install --save-dev hardhat
npx hardhat init

Deploy a Contract

// scripts/deploy.js
const { ethers } = require("hardhat");

async function main() {
  const Token = await ethers.getContractFactory("SimpleToken");
  const token = await Token.deploy(1_000_000);
  await token.waitForDeployment();
  console.log("Deployed to:", await token.getAddress());
}

main().catch(console.error);

npx hardhat run scripts/deploy.js --network sepolia

Gas Optimization Tips

Gas efficiency = lower costs for your users = competitive advantage.

//  Expensive: reading from storage in a loop
for (uint i = 0; i < users.length; i++) {
    total += balances[users[i]];
}

//  Cheaper: cache storage reads in memory
uint256 len = users.length;
for (uint i = 0; i < len; i++) {
    total += balances[users[i]];
}

Other wins:

Use uint256 over smaller types ,the EVM works in 32-byte slots.
Mark functions view or pure when they don't modify state
Use calldata instead of memory for external function parameters
Pack struct variables to fit in fewer storage slots
Emit events instead of storing data you only need off-chain

Contract Standards Worth Knowing

Standard	What It Is
ERC-20	Fungible tokens (USDC, DAI, UNI)
ERC-721	Non-fungible tokens / NFTs
ERC-1155	Multi-token standard (games, etc.)
ERC-4626	Tokenized vaults (DeFi yield)
EIP-2612	Gasless approvals via signatures

OpenZeppelin has production-ready implementations of all of these:

import "@openzeppelin/contracts/token/ERC20/ERC20.sol";

contract MyToken is ERC20 {
    constructor() ERC20("MyToken", "MTK") {
        _mint(msg.sender, 1_000_000 * 10 ** decimals());
    }
}

Testing

// test/Token.test.js (Hardhat + Ethers)
const { expect } = require("chai");
const { ethers } = require("hardhat");

describe("SimpleToken", function () {
  it("should assign total supply to deployer", async function () {
    const [owner] = await ethers.getSigners();
    const Token = await ethers.getContractFactory("SimpleToken");
    const token = await Token.deploy(1000);

    const balance = await token.balanceOf(owner.address);
    expect(balance).to.equal(await token.totalSupply());
  });

  it("should transfer tokens correctly", async function () {
    const [owner, recipient] = await ethers.getSigners();
    const Token = await ethers.getContractFactory("SimpleToken");
    const token = await Token.deploy(1000);

    await token.transfer(recipient.address, ethers.parseUnits("100", 18));
    const recipientBalance = await token.balanceOf(recipient.address);
    expect(recipientBalance).to.equal(ethers.parseUnits("100", 18));
  });
});

Final Thoughts

Smart contract development is one of the most high-stakes disciplines in software. A bug that slips through in a web app might annoy users. A bug in a smart contract holding $10M can be catastrophic and irreversible.

The upside? You're building programmable money, unstoppable applications, and trustless infrastructure that can outlive any company or server.

Middleware in Go

OdaloV — Thu, 14 May 2026 16:26:13 +0000

If you've built any web application in Go, you've probably heard about middlewares. But what exactly are they?

A middleware is just a function that sits between your HTTP server and your route handlers. It can inspect, modify, or even stop a request before it reaches your main application logic.

Think of it as a pipeline.Every request passes through each middleware in order before hitting your handler, and the response travels back through them on the way out.

Example

A middleware accepts a handler and returns a new one:

func MyMiddleware(next HandlerFunc) HandlerFunc {
    return func(c Context) error {
        // runs before your handler
        err := c.Next(next)
        // runs after your handler
        return err
    }
}

c.Next()

When you register multiple middlewares, your framework doesn't run them independently. It builds a chain. Each middleware wraps the next one, like nested functions. c.Next() is the call that says ,pass control to whatever comes next in that chain.

Without it, the chain stops dead. Your route handler never runs, and the client gets no response.

This also means you can intentionally skip it to reject a request early:

func RequireAuth(next HandlerFunc) HandlerFunc {
    return func(c Context) error {
        if c.Request().Header.Get("Authorization") == "" {
            return c.String(http.StatusUnauthorized, "unauthorized")
        }
        return c.Next(next) // only reach here if auth passes
    }
}

Registering middleware

Most frameworks let you attach middleware at three levels.

Global middleware runs on every single request your app receives ,logger and panic recovery belong here:

app.Use(Logger)
app.Use(Recover)

Group middleware applies only to a subset of routes. This is the right place for auth ,you probably don't want to guard your /health endpoint the same way you guard /api/users:

api := app.Group("/api")
api.Use(RequireAuth)

Route-level middleware is for one-off logic that doesn't belong anywhere else:

app.GET("/admin", adminHandler, RequireAdmin)

If a middleware needs to run everywhere, make it global. If it only makes sense for a set of routes, scope it to a group. Route-level is a last resort.

Kenya's proposed AI Bill 2026

OdaloV — Mon, 11 May 2026 08:30:49 +0000

Kenya has the highest AI adoption rate globally – 97.5% of internet users engage with AI monthly (Digital 2026). 68% of Kenyan firms aim for full AI adoption by end of 2026 (KPMG).

But the proposed AI Bill, 2026 has issues:
1. Prison time for locals. Violations carry fines up to $38,000 and three years in jail. Directors must prove their innocence, reversing Kenya's constitutional burden of proof.

2. A loophole for Big Tech. OpenAI's clinical AI runs in 16 Nairobi clinics. A Dutch TB screener processes thousands of X-rays. Google is testing maternal ultrasound. None are explicitly covered. A local dev faces prison. OpenAI faces nothing.

3. No evidence of harm. The Bill was drafted without consulting health, agriculture, or finance sectors about what AI harms they actually experience. It defaults to maximum deterrence (prison) by reflex, not data.

The fix: Remove criminal penalties, close the foreign loophole, and follow the EU model of administrative fines.

Kenya's developers deserve precision.

[Boost]

OdaloV — Mon, 11 May 2026 08:23:33 +0000

Digital Hoarding

OdaloV — Sat, 11 Apr 2026 15:52:47 +0000

A personal journey through 4GB of laptop clutter and over 800 phone screenshots I'll never look at again

The discovery

During some late-night reading, I stumbled across a 2025 paper by Liu & Liu in Frontiers in Psychology on something called digital hoarding.
I'd never heard the term before.
But as I kept reading, I felt Called out.

They defined it as: "The compulsive accumulation of digital files to the point of distress and disorganization."
And I thought to myself ,that's not only a research subject. that's my laptop,and probably my phone too.

On my laptop:

~/Downloads – 47 PDFs, 12 driver installers, 3 tutorials I never finished. Oldest: 2019
~/Desktop – Screenshots of error messages I Googled and fixed. Oldest: 2021
~/code/experiments – 23 half-built projects, 18 with broken dependencies. Oldest: 2020
~/Documents/old-work – Repos from two jobs ago. Two jobs ago! Oldest: 2018

On my phone:

Screenshots folder – 1,112 images. Error messages, tweets, "read later" articles, memes.
Photos (duplicates) – The same picture saved 3-4 times.
Old app caches – 2.1 GB from apps I haven't opened in months.
Voice notes – 47 recordings. "Reminder to self" from 2022 to 2026.
WhatsApp images – From groups I left in 2023.

I was a digital hoarder with a terminal and a smartphone addiction.

What Liu & Liu taught me

The paper described digital hoarding as a "double-edged sword."
On one edge: It feels responsible. "I might need this someday." "Better to save it than lose it."
On the other edge: It's actively hurting me — on every device I own.
They listed consequences that hit too close to home:

Cognitive load – Every extra file is a tiny decision I don't make
Decision fatigue – Which of these 14 project folders is the real one?
Anxiety – "What if I delete something important?"
Battery drain – Your phone constantly indexing thousands of unused files

And the part that really got me: "A protective behavior that eventually becomes a burden."

The hidden cost never measured

Before cleanup:

Storage used: 10 GB
Boot time: 48 seconds
Search time: 6-8 seconds
Battery life: ~6 hours
Backup time: 45 minutes

After deleting 500+ old files and 2,000+ screenshots:

Storage used: 8 GB (down 2 GB)
Boot time: 31 seconds (down 35%)
Search time: 1-2 seconds (down 75%)
Battery life: ~8 hours (up 33%)
Backup time: 12 minutes (down 73%)

No hardware upgrade. No factory reset. Just… deleting things.

The developer-specific hoarding patterns

Liu & Liu didn't study developers specifically. But I noticed patterns unique to our craft — and how they spill onto our phones.

1: The tutorial graveyard

We start a tutorial. Clone the repo. Follow along for 30 minutes. Get distracted. Never finish.
But we keep the folder. Just in case.
My count: 23 unfinished tutorial projects. 18 using packages that are now deprecated.

2: The error screenshot museum

Something breaks. We screenshot the error on our laptop. Then we Google it. Fix it. Feel proud.
But we never delete some of the screenshots.
My count: 110 laptop screenshots + 1,110 phone screenshots. I will never look at 99% of them again.

3: I'll refactor this someday

Old projects. Old code. Old mistakes. We keep them like trophies.
My count: 4GB of code I haven't touched in over two years.

4: The screenshot spiral

See something interesting? Screenshot. Want to remember a tweet? Screenshot. Need to save a receipt? Screenshot.
Then never organize them. Never look at them. Never delete them.
My count: 1,112 screenshots. I remember taking maybe 200 of them.

5: The "I'll clean this later" cache (phone)

Apps cache images, videos, and files. We ignore it. It grows. We run out of storage.
My count: 2 GB of "System Data" — a black hole of forgotten files.

Liu & Liu ended their paper with a question:

"How do we design systems that support selective retention rather than indiscriminate accumulation?"
I don't have an answer. But for me,I'll start small. One old file. One screenshot. One deleted folder at a time.

Progressive Web Apps (PWAs): The Best of Both Worlds

OdaloV — Sun, 01 Mar 2026 12:38:02 +0000

What is PWA?

Progressive Web Apps are regular websites built with standard web technologies such as HTML, CSS and JavaScript, that progressively enhance to deliver an app-like experience. They work in any browser but can be installed on your device like a native app. Think of them as websites that put on an app costume.

Core Technologies

HTTPS - Secure connection required for all modern web capabilities.
Web App Manifest - A JSON file defining your app's name, icons, colors, and launch behavior.
Service Workers - Background scripts that enable offline functionality, caching, and push notifications.

Why PWAs Matter

For Users

Install with one click - No app stores, no approvals, no fees.
Works offline - Access content even without internet.
Lightweight
Cross-platform - Same app works on any device with a browser.

For Developers

Single codebase - One app for all platforms instead of separate iOS/Android builds.
Lower costs - PWA development ranges from $15,000-$150,000 versus $50,000+ per native platform.
No app store gatekeepers - Deploy updates instantly without waiting for approval.
SEO-friendly - PWAs are indexable by search engines unlike native apps.

Real-World Example

Microsoft:

Microsoft took a data-driven approach to PWAs, automatically identifying 1.5 million progressive web apps for inclusion in the Windows Store. This discovery opened up a massive ecosystem of applications that could run natively on Windows without any additional development work.

The impact was twofold:

Users gained access to millions of apps without waiting for developers to build Windows-specific versions
Developers saw their apps appear in the Windows Store automatically—no extra effort required

Microsoft's embrace of PWAs validated that the technology wasn't just for small projects—it was a legitimate distribution channel for the world's largest operating system.

When to Choose PWA

PWAs are ideal for :

E-commerce - Higher conversions, better mobile experience.

Content-driven apps - News, blogs, media.

Businesses with limited budget - One app for all platforms.

Emerging markets - Works on slow connections.

The web is evolving, and PWAs are leading the charge toward a future where the line between websites and apps disappears entirely.

Agentic-AI :Simple tools to autonomous partners

OdaloV — Mon, 02 Feb 2026 09:26:32 +0000

If you have been following AI development,then you've seen the shift, from ChatGPT answering questions to Devin writing entire codebases. From simple chatbots to systems that plan, execute, and adapt.

What Makes an AI Agentic?

Agentic AI is about ,agency,the capacity to act independently toward goals. While a traditional AI model generates text based on patterns, an AI agent:

Sets and pursues goals
Breaks problems into steps
Uses tools to interact with the world
Learns from feedback
Adapts its approach when stuck

It's like moving from a calculator;executes commands, to a mathematician;solves problems using tools and reasoning.

The Fundamental Loop: Perception → Reasoning → Action

The simplest theoretical model of an AI agent is the Perception-Reasoning-Action cycle:
In practice with LLMs, this becomes the ReAct pattern (Reason + Act):

    python

    # How an AI agent thinks and acts
    def agent_loop(objective, tools, memory):
    while not objective.achieved():
    # 1. PERCEPTION: Look around
    observation = perceive_environment()

    # 2. REASONING: Think about next step
    thought = llm_reason(objective, observation, memory)

    # 3. ACTION: Do something with tools
    action = choose_action(thought, tools)
    result = execute_action(action)

    # 4. UPDATE: Learn and continue
    memory.update(thought, action, result)

return "Task completed"

Breaking It Down with Fast Food

Let's say you're craving KFC and tell an AI agent: "Get me KFC for dinner"

Old-School AI (Traditional Chatbot)

Would give you instructions:

Go to the KFC website or use Glovo

Agentic AI (Autonomous Assistant)

Actually does it for you. Here's how it thinks:

Agent's Thought Process:

PERCEIVES:

Checks your current location

Remembers you ordered KFC last Tuesday

Notes you usually ask for extra ketchup
REASONS :

They want KFC. Let me check where they are

Found 3 KFCs nearby. Which one has the shortest wait time?

They like the Zinger Burger based on last order.

Should check for any discounts or offers
ACTS :

Searches for nearby KFC locations

Checks opening hours and current wait times

Compares prices and specials

Places the order via API

Tracks the delivery in real-time
UPDATES :

Noted: they want extra ketchup. Remember for next time.

The bottom line: The agent doesn't just talk about KFC ,it gets you the actual chicken.

Why This Matters
Agentic AI represents a fundamental shift:

You give goals, not step-by-step instructions

AI handles complex multi-step processes

Systems improve through experience

One agent replaces what used to take multiple tools