Why Gofinity runs your code instead of grading your answer
Multiple choice teaches you to recognise Go. Running the real test suite against the code you wrote teaches you to write it. Here is what happens between pressing Run and seeing a green tick.
Most places that teach a language ask you to pick the right answer. Gofinity asks
you to write code that compiles, and then runs the same go test a maintainer
would run. The difference matters more than it sounds: recognising correct Go and
producing correct Go are separate skills, and only one of them survives contact
with a real codebase.
What a challenge actually is
A challenge is a small Go module. Some of its files are yours to edit, some are there for context, and some you never see — the tests. The brief on the left tells you what the package has to do; the editor in the middle is the module; the panel on the right is the test output.
When you press Run, we take the files you marked as changed and take every other file straight from the database. The browser never gets to say what the rest of the module contains, which is why a passing run means what it says.
Then it goes in a box
Your code is compiled and executed inside a container that has:
- no network at all,
- a read-only root filesystem with a small writable scratch directory,
- a hard memory and process cap,
- and a wall-clock timeout that kills the run whether it is looping or waiting.
The container gets the module, runs the tests, prints a structured result, and is thrown away. Nothing survives between runs, and nothing you write can reach anything of ours or of anyone else's.
Reading the result
The results panel is per-test, not pass/fail. A failing test shows its name, what it expected and what it got, and the compiler output if it never got as far as running. That is deliberately the same information the Go toolchain gives you on your own machine, because the point is to make you fluent in that output rather than in ours.
func TestGreet(t *testing.T) {
got := Greet("Gofinity")
want := "Hello, Gofinity!"
if got != want {
t.Fatalf("Greet() = %q, want %q", got, want)
}
}
If you have ever wondered why a challenge insists on an exact string, this is why:
somewhere there is a test with a want in it, and it is not negotiable.
And then you read someone else's
Once you have solved a challenge you can publish your solution, and you can read everyone else's. This is the part that is hard to get from a book. There are usually three or four idiomatic ways to write the same twenty lines of Go, and seeing them next to each other — with the votes telling you which one other readers found clearest — is how the idioms stop feeling arbitrary.
Start with the first track, solve one challenge, and see how far off the consensus you were.