Day 1

This free, 30-day series is meant to get you acquainted with the Goblin programming language. We'll cover most of the fundamental stuff you'll need to know in any foundational course, but we'll do it in a fun way that builds on itself as we go through the course. By the end of this, you should be able to take what you learned and improve upon the little project we've built.

Are you ready?

Before you write a single line

A computer cannot think. It cannot guess what you meant, and it cannot fill in a gap in your instructions with common sense. It can only do exactly, precisely, and stupidly what it is told — one instruction, then the next, then the next, in the order you gave them.

That's it. That's the whole secret of programming. Everything else — every language, every framework, every clever trick you'll learn over the next thirty days — is just different ways of writing instructions for something that will do exactly what you say and nothing more.

A program is a list of those instructions, written down. Running a program means handing that list to the computer and watching it execute each line, top to bottom, in order.

Goblin is one particular way of writing that list. It's not the only way — Python, JavaScript, Rust, and a hundred other languages all do the same job with different words and different rules. But Goblin was built with one idea driving almost every decision in it: the language should never make you guess, and it should never guess about you. If something is ambiguous, Goblin stops and tells you, instead of quietly doing something you didn't ask for. You'll see this philosophy again and again over the next thirty days. It starts today, in the smallest possible way, and by Day 30 you'll understand it as the thing that makes Goblin Goblin.

You don't need to know anything else yet. You don't need to have programmed before. If you have — good, some of this will feel familiar. If you haven't — also good. Goblin isn't taught here as "Python, but different." It's taught as itself, from zero.

What Goblin actually is

Goblin is a scripting language built for simulations, automation, tooling, games, and rapid application development — the kind of software where you want to build something real quickly, without wading through boilerplate to get there. Its two guiding principles are readability and discoverability: you should be able to read a piece of Goblin code and understand roughly what it does even before you've been taught the specific feature, and the language should use a small, consistent set of concepts everywhere instead of forcing you to memorize a hundred unrelated ones.

Here's a complete, real Goblin program — not a simplified teaching example, an actual line pulled from the language's own documentation:

name | "Goblin"

:say("Welcome to the Horde, {name}.")

name | "Goblin"

:say("Welcome to the Horde, {name}.")

Run it, and it prints:

Welcome to the Horde, Goblin.

You're not expected to understand every symbol in that yet — the | and the {name} inside the string are both things you'll learn properly over the next two days. Read it anyway. In two lines, that program creates something, gives it a name, and speaks. By the end of today, you'll have written and run something like it yourself. By the end of this course, you'll understand exactly why every character in it is there.

Installing Goblin

Goblin ships as a single standalone program — no package manager, no dependency chain to untangle before you can write your first line.

1. Go to the Goblin releases page and download the build that matches your machine — Windows x64 or Linux x64.
2. Once it's downloaded, open a terminal (Command Prompt or PowerShell on Windows, any terminal on Linux) and confirm it's working:

   goblin --version

   You should see a version number print back at you.

Once goblin --version works, you have a working Goblin installation. That's the entire setup process. No configuration files, no environment to build — you're ready.

Two ways to run Goblin

Every language gives you at least one way to run code. Goblin gives you two, and they exist for genuinely different reasons — this isn't a Goblin-specific quirk, it's a distinction worth understanding on its own terms, because you'll rely on it for the rest of your programming life, in any language.

Running a file means writing a complete set of instructions into a document, saving it, and then handing the whole thing to the computer at once. The computer reads it top to bottom and executes it start to finish. This is how real software runs — nobody ships a program by typing it live into a terminal while the user watches. If you have a file called hello.gob, you run the whole thing with:

goblin run hello.gob

The REPL — short for Read-Evaluate-Print-Loop — is the opposite. Instead of writing a whole program and running it all at once, you type one instruction, hit Enter, and the computer executes just that line and shows you the result immediately, before you type the next one. Start it with:

goblin

You're now inside a live conversation with the interpreter. Nothing is saved anywhere — when you close it, everything you typed is gone. That sounds like a weakness, but it's actually the REPL's entire purpose. It's not for building things. It's for finding out. When you're not sure how something behaves, you don't want to write a whole file, save it, run it, and dig through the output to check one small fact — you want to ask the question directly and get the answer in half a second. That's what the REPL is for.

Your first program

Now we are going to walk you through using the REPL in what you just installed. If you want to try Goblin first before installing, you can use the built-in REPL here (but you will need to install Goblin once we get into making files and running your programs).

Open the REPL:

goblin

Type this and press Enter:

:say("Hello, Goblin.")

:say("Hello, Goblin.")

It prints immediately:

Hello, Goblin.

Look closely at :say(). The leading colon is not decoration — it's a signal built into the language itself. Every action that starts with : is a core function: something built into Goblin, guaranteed to exist, guaranteed to behave the same way in every Goblin program ever written, and never something you or anyone else can accidentally overwrite. When you see a colon in front of a function name anywhere in Goblin, you immediately know: this one is included by Goblin. You'll meet more of them as the course goes on.

"Hello, Goblin." is a string — text, wrapped in quotation marks, exactly as it will be printed. Anything inside the quotes is data; anything outside them is an instruction to Goblin.

Now try a second line, still in the REPL:

:say("The Horde grows by one.")

:say("The Horde grows by one.")

Two separate calls to the same core function, two separate lines of output. Notice that nothing you did in the first line affected the second — each call to :say() is its own complete instruction.

Comments — notes to the next reader

Add one more line to your REPL session:

/// this line does nothing

/// this line does nothing

Nothing happened. No output, no error. That's correct — anything after /// isn't an instruction at all. It's a comment, and comments are invisible to the interpreter entirely. They exist for one reason only: to leave a note for the next human who reads this code, and that next human is very often you, six months from now, having completely forgotten why you wrote something a particular way.

You won't feel the value of comments today, with two lines of code you can hold entirely in your head. You'll feel it starting around Day 15, when your vault has grown past the point where you can remember every decision you made. Get in the habit now, while it costs nothing.

Now, if you try it in this REPL, you'll notice it actually echoes your comment back.

A peek ahead

Go back to the example from the start of this lesson:

name | "Goblin"

:say("Welcome to the Horde, {name}.")

name | "Goblin"

:say("Welcome to the Horde, {name}.")

You now understand every part of this except one line. :say() you know. The string you know. The only mystery left is name | "Goblin" — creating something called name and giving it a value. That's a variable, and it's tomorrow's entire lesson: what a variable actually is, why Goblin uses | instead of the = you may have seen in other languages, and what that choice protects you from. For today, just notice that you can already read most of a real Goblin program on your first day. That's the point of a language built for readability — the gap between "knows nothing" and "can read real code" is supposed to be small.

REPL Lab

Work through these one at a time, in the REPL. Don't just read them — type each one, watch what happens, then move to the next.

:say("The Horde grows by one.")

:say("The Horde grows by one.")

:say("Line one.")
:say("Line two.")
:say("Line three.")

:say("Line one.")
:say("Line two.")
:say("Line three.")

/// this is a comment, and does nothing
:say("But this still runs.")

/// this is a comment, and does nothing
:say("But this still runs.")

Now, before you type this next one, predict what will happen:

:say(hello)

:say(hello)

No quotation marks around hello this time. Guess first — will it print the word hello? Will it do nothing? Will it error?

(Now run it.) It errors. Without quotes, Goblin doesn't treat hello as text — it looks for a variable named hello, doesn't find one, and stops rather than guessing what you meant. This is the same philosophy from the very first section of this lesson, showing up in your first five minutes of real code: Goblin would rather refuse to run than silently do the wrong thing.

Where to write your code

So far everything has happened in the REPL, where you type one line at a time and the interpreter forgets it all the moment you close the window. But the Challenge below asks you to create a file — a program saved to disk that stays there. That raises a question almost no tutorial bothers to answer for a true beginner: what do you actually write that file in?

Not Microsoft Word. Not WordPad. Not Google Docs. Not any word processor — for a reason that ties directly to what you just learned.

The tool for writing plain text — exactly the characters you type, nothing added — is called a code editor. (You'll also hear the term "IDE," short for Integrated Development Environment — that's just a code editor with extra features bolted on; for this course the difference doesn't matter.) A code editor gives you things a word processor never will: line numbers, colored text that makes code easier to read at a glance, and automatic matching of brackets and quotes.

Any of the following will do the job. If you have no opinion and just want to start, install the first one.

• VS Code — code.visualstudio.com — Free, runs on both Windows and Linux, and by far the most widely used code editor in the world. If you're not sure what to pick, pick this. Nearly every tutorial you find later will assume you have it.
• VSCodium — vscodium.com — The same editor as VS Code, rebuilt fully open-source with the tracking stripped out. If you care about open source and privacy, this is the identical experience without the telemetry.
• Sublime Text — sublimetext.com — Extremely fast and lightweight, free to evaluate with an occasional reminder to buy a license. A good pick if VS Code feels heavy on an older machine.
• Notepad++ — notepad-plus-plus.org — Windows only, tiny, and dead simple. If you want the bare minimum — a plain-text editor with line numbers and colors and nothing else to learn — start here.

Creating the file. Once your editor is installed, make a new file and save it as vault.gob.

Challenge — print your banner

Everything you build from here through Day 30 lives in one growing file. Today, you create it.

Step 1. In your code editor, create a new file named vault.gob, in a folder you'll remember. (If you skipped the section above: it has to be a real code editor saving plain text — not Word — and the name has to end in .gob, not .gob.txt.)

Step 2. Add one line:

:say("Vault online.")

:say("Vault online.")

goblin run vault.gob

Step 3. Add a comment above that line describing what the file is, using ///. It doesn't need to be clever. It needs to be true.

Step 4. Now build an actual banner — at least three :say() lines, forming something that looks like the opening screen of an application, not just a scattered sentence. Add one line, run the file, look at the output, then add the next. Don't write all three at once and run it only at the end — get in the habit of checking your work after every change, starting today, while the file is still small enough that if something breaks, you know exactly which line did it.

By the end of this step, running goblin run vault.gob should produce a banner — a real, if small, opening screen for a project that will still exist, and be considerably larger, on Day 30.

Recap

• A program is a list of instructions; running it means executing them in order, top to bottom.
• Goblin gives you two ways to run code: files (goblin run file.gob), for building things that last, and the REPL (goblin), for testing ideas that don't need to.
• :say() prints text to the terminal. The leading colon marks it as a core function — guaranteed, built-in, never overwritten.
• Strings are text wrapped in quotation marks. Without quotes, Goblin looks for a variable instead — and errors if it doesn't find one, rather than guessing.
• /// starts a comment. The interpreter ignores it completely; it exists for human readers.
• Code is written in a code editor (VS Code, VSCodium, Sublime Text, Notepad++), never a word processor — code must be plain text, exactly as typed.
• Goblin files end in .gob (or .gbln — same thing); this course uses .gob.
• You now have vault.gob — a real, running program, one line longer every day for the next 29 days.