Learning Odin - Installation and Hello World! Program

Srinivas Mekala — Wed, 15 Jul 2026 04:16:19 +0000

Learning Challenge - Day 1/50

This is a 50 Days challenge to learn something new everyday for 45Mins without relying much on AI.

Started Odin Programming Language and I'm promising my future self that I'll build something exciting with Odin by the end of this Challenge

Installation

I'm working on my HomeServer (Ubuntu Server) by connecting remotely to my VSCode on my Windows Machine. So, everything will be same as I'm using a linux machine.

Essentials

Install clang, llvm and llvm-devel
Why? Check the note after the commands

sudo apt-get update
sudo apt-get upgrade
sudo apt-get install clang llvm llvm-devel build-essential
sudo apt-get update

Close the terminal and open a new one
Verify the installations

clang --version
llvm-config --version

Installing Odin now

Clone the official Odin from GitHub by

git clone https://github.com/odin-lang/Odin

cd to the directory and make the install

cd Odin
make release-native

To made odin available from anywhere to run it as an executable. Export the path to your bashrc or zshrc

echo 'export PATH="/full/path/to/Odin/folder:$PATH"' >> ~/.bashrc (or) ~/.zshrc

Refer and follow Official Documentation if you're confused or see any errors

Hello World!

👏🏻🎉 Yay! If you reached here without any issues. You've successfully installed Odin language and we're ready to go.

Create a Project Folder mkdir learn-odin && cd learn-odin
create a file named .odin and add the following code

package main
import "core:fmt"

main :: proc(){
    fmt.println("Hello World!")
}

Run the program odin run ./

Odin by default thinks in terms of directory-based packages and it expects a .odin file for that directory. So, when we run, it compiles all the files in that directory into a package and then tunrs that into an executable.
Alternatively, if we want to create a single odin and run it as a file. Rename or create a new file say hello-world.odin and with the same code inside the file, run odin run hello-world.odin -file

Voila! We just wrote our first Odin file and executed it. Yay!

PS: Hey That's a good start. We still don't know what's a package. Why we're import core:fmt and what those two colons (::) are and what actually the code means.
Let's worry about in the next one.

Cookies or Bearer Tokens? The Day my Auth Design Decision Broke.

Srinivas Mekala — Sat, 11 Jul 2026 16:20:13 +0000

It's been 3 months since I was actively building StashD -- a link-organizing app. NextJs on the frontend, Flask + MongoDB on the backend. Auth was one of the first things I had to get right, so I did what felt like the "correct" thing at the time: httpOnly cookies. Secure, invisible to JavaScript, browser handles everything for me. I shipped it, moved on, felt good about the decision.

Today, I thought, why don't I build a mobile app so my users can access their saved links from their phones on demand.

The Moment It Fell Apart

I sat down to think through how the mobile app would authenticate, researched a lil bit, and it hit me in the face: there's no browser cookie jar on a native app🤦🏻‍♂️. My entire auth flow assumed a browser sitting between the user and my API — one that would store a cookie and automatically reattach it on every request without me writing a line of code for it. That assumption had been invisible to me the whole time I was building for web only, because it was just... always true. Every request from the browser already carried the cookie. I never had to think about the mechanism, so I never noticed I'd built a dependency on it.

A mobile app doesn't get that for free. There's no automatic anything. If I wanted the Android app to authenticate against the same Flask API, I'd need to manually attach a token to every request myself. Which meant my whole "cookie is the auth mechanism" design was actually "cookie is a auth mechanism, coupled to exactly one client — the browser."

That was the first real lesson:

An auth design that only works because of an environment-specific behavior isn't a design, it's an accident that happens to work in one place.

It's Time to Rewind the Reel

I had to stop and actually understand why I picked cookies in the first place, instead of just knowing that I had. Here's what I worked out.

A cookie and a bearer token carry the same thing — a JWT. The difference is entirely about who attaches it to a request:

Cookie: the browser attaches it automatically, for every request matching the cookie's domain. I don't have to write the attachment logic.
Bearer token: my code does it, manually, via an Authorization: Bearer <token> header. Nothing happens unless I write that line.

That's it. That's the whole difference. But that one difference cascades into everything else.

Did I pick Cookies blindly? No!: _httpOnly _cookies can't be read by page JavaScript. If someone ever manages to inject a malicious script into my site (XSS), that script cannot steal the token — it's invisible to document.cookie. If I had instead put my JWT in localStorage, any XSS bug becomes a full account takeover, and the stolen token is portable — usable from the attacker's own machine, forever, until it expires.

That's a real, good reason to prefer cookies. I took it as "best practice" without connecting it to the actual mobile-shaped hole in the design.

But cookies aren't free. Because the browser attaches them automatically, a malicious site can trick a victim's browser into firing a request at my API with the cookie riding along — that's CSRF. Next.js comes to the rescue here: it defaults cookies to SameSite=Lax, which blocks that for state-changing requests.

Bearer tokens flip both properties. Immune to CSRF by construction — there's no ambient credential for a third-party site to hijack, since nothing is attached automatically. But if the token sits in localStorage or a JS variable, XSS can read it directly, and now it's stolen, not just abused-in-session.

Neither one is "more secure" in the abstract. They're secure against different things, and the win depends entirely on the shape of your client.

My Second Lesson: What do I change to support both mobile and web requests?

My first plan was: keep cookies for web, add a second code path in Flask that also accepts a bearer header for mobile. Check cookie first, fall back to header. Felt like the minimal change.

It would have worked. But sitting with it a bit longer, I realized I was about to bake "what kind of client is calling me" into my backend's auth logic, permanently, for every route, forever. Two paths to test, two paths to audit for security holes, and the set only grows if I ever add a third client.

The better shape, once I saw it: the backend shouldn't know or care what kind of client is calling it. Make the API bearer-only, full stop. It returns a token in the response body on login, and validates one thing — the Authorization header — on every protected route. No branching.

Then the cookie isn't a backend concern at all anymore. It becomes something the web app does to itself — my Next.js server receives that bearer token same as any other client would, and wraps it in its own httpOnly cookie before it ever reaches the browser. When the web server needs to call the API on the user's behalf, it just reads its own cookie back out and forwards it as a bearer header. The Flask API never even knows a cookie existed anywhere in the chain.

The mobile app does the same thing, minus the cookie step — takes the token from the response body, drops it straight into secure device storage (Keystore-backed on Android), attaches it as a bearer header on every call. No intermediary needed, because a native app doesn't have the XSS threat model a browser has in the first place.

Two clients, two completely different ideas of "how do I protect this token" — and the backend doesn't have to know either one exists. That's the part I actually feel good about: not "I added mobile support," but "I found the layer where the client-specific decision actually belongs, and moved it there."

PS: Try out my WebApp : StashD.
Hope you like it and wait for the mobile version too.🫡✌🏻

DEV Community: Srinivas Mekala