1. Getting to know the compiler
A computer does not understand human language. A computer does not even understand programming languages. It only understands programs written in machine code—made up of zeros and ones. People, on the other hand, think in words and ideas, and of course it is hard for them to compose entire programs using only 0 and 1.
00100100 translates to the decimal number
36 or the
$ character
That is why programming languages like Kotlin appeared. They became a kind of “translator”: now a programmer can write commands like “Do this and that” in a language they understand, rather than as a long chain of commands for the CPU.
But there is a catch. The computer still does not understand Kotlin! If you just feed it a file with code, it will shrug and do nothing. That is exactly why a compiler exists.
So what is a compiler?
A compiler is a special program that compiles code: it translates Kotlin code into code the computer can understand. It takes text written in Kotlin, parses it, checks it for errors, and turns it into bytecode for the JVM virtual machine.
flowchart TD
A[📝 Kotlin code] --> B[Compiler]
B --> C{Any errors?}
C -->|Yes ❌| H[Error message Return to code]
H --> A
C -->|No ✅| I[⚙️ Bytecode generation]
I --> J[JVM bytecode]
J --> K[JVM virtual machine]
K --> L[Program execution]
style A fill:#7B68EE,color:#fff
style B fill:#FF8C00,color:#fff
style J fill:#20B2AA,color:#fff
style K fill:#3CB371,color:#fff
style L fill:#3CB371,color:#fff
style H fill:#DC143C,color:#fff
You can think of the compiler as a strict teacher who:
- carefully checks each phrase (did you make a mistake?),
- forces you to follow the rules (for example, correct variable names, parentheses, types...),
- and only after that allows you to “talk” to the computer!
Without a compiler, writing a program would be like composing “War and Peace” in Morse code.
The compiler is even smarter
The Kotlin compiler has become even smarter—it can not only translate, but also optimize code, point out errors, and even suggest how to write better. And a whole lot more.
If we are talking about Kotlin on the JVM (that is, regular console apps/backend on the JVM), it usually looks like this:
- At the first stage, your Kotlin code is transformed into a special intermediate JVM bytecode.
- And then, during execution, the JVM (virtual machine) translates that bytecode into real CPU machine instructions (and can do so taking the specifics of the particular machine into account).
- A program in the Kotlin language
-
Kotlin compiler
- A program consisting of special codes (bytecode)
-
Java VM
- A program consisting of machine code
If you have a powerful CPU that supports a larger set of machine instructions, then during such translation/optimization the JVM can generate machine code that takes advantage of your CPU and OS. That is why programs in JVM languages (including Kotlin) can be very fast for certain tasks.
Not only the JVM
Originally, Kotlin was created primarily as a language for the JVM (that is, “like Java, but more convenient”). So for a long time, the main scenario was: Kotlin code → JVM bytecode → execution on the JVM.
But later Kotlin gained other “compilation modes” (other launch scenarios):
- Kotlin/JVM—the classic option: console, server, Android (partially), everything in the JVM world.
- Kotlin/JS—compilation to JavaScript for the browser or Node.js.
- Kotlin/Native—compilation to native machine code (for example, for iOS, macOS, Windows, Linux).
- Kotlin Multiplatform—an approach where part of the code is shared and part is platform-specific, and the project can be built for several targets at once.
The idea remains the same: the compiler takes Kotlin code and turns it into a format the target platform “understands”—the JVM, a browser (JS), or a native OS.
2. Common compilation errors
Speed and code optimization are not very important to us yet, but what is important is that the compiler checks your program for errors. It validates the code and will not let it go any further if it finds even a small mistake.
Error example:
You try to assign a number to a variable that can store only text.
val userName: String = 42 // Oops! You can’t do that.
The compiler will immediately report an error that the types do not match (something like): Type mismatch: inferred type is Int but String was expected.
Another example is a typo in the println call:
printline("Hello!") // Error in the function name
The compiler will say something like: “No such function—check your syntax!” (for example, Unresolved reference: printline).
How do you read errors?
Most compilers point out where the error is in the code, and sometimes even suggest fixes. Don’t be afraid of errors: each one is a step toward enlightenment and beating your inner “boss.”
3. Comments
Now imagine this: you write a complex program. Everything works, you’re a genius! But a month later you open that same code and... understand nothing. A couple lines of code here, a weird variable there. In your head: “Clearly, anyone could have written this—but not me!” That’s where comments save the day.
Comments are like notes in the margins of a textbook or labels on the fridge (“Beer. Do not drink. For the morning!”). The compiler ignores them, but people do not. Comments let you explain the meaning of the code, mark important details, and even “disable” pieces of a program without deleting them.
Important: the compiler does not read your comments; they are completely ignored!
Single-line comments
In Kotlin (as in Java), there are two types of comments—single-line and multi-line. Single-line comments start with a double slash // and go to the end of the line. Everything after // is considered a comment and is absolutely ignored by the compiler.
Example:
println("Hello, world!") // This prints a greeting to the screen
Here // This prints a greeting to the screen is a comment. If something in the code seems unclear—why a line is needed—write it like this!
Another example:
val x = 42 // The programmer’s age value
You can also write single-line comments on separate lines:
// Initialize a variable with the user name
val userName = "Alice"
Almost like lines in a script: the comment explains what and why.
Multi-line comments
What if you have a lot to say? A whole story? That is what multi-line comments are for: they start with /* and end with */. Everything between these symbols is ignored by the compiler, even if it spans multiple lines.
Example:
/*
Here we output the user name to the screen.
If the name is missing, we print "Guest".
*/
println("Enter your name:")
Or like this:
var age = 18 /* Initial age value
for a new user */
Attention: you cannot nest multi-line comments inside other multi-line comments. Don’t try to outsmart the compiler—it won’t work.
Illustration:
| Type | Syntax | Example |
|---|---|---|
| Single-line | |
|
| Multi-line | |
|
4. Real-life examples
“Disabling” a line of code:
Sometimes you temporarily want not to execute some piece of code. Comments are perfect for that:
// println("Text that is temporarily not needed")
The line remains, but the compiler does not “see” it.
TODO and FIXME notes
Programmers are people too, and sometimes you need to remind yourself that the code is not finished yet, or that there is a bug here. For that, people often write:
// TODO: add validation for empty input
// FIXME: this function calculates the sum incorrectly
Many editors and IDEs even highlight these words!
Programmers joke
// I am not responsible for this code. I was forced to write it against my will.
// Dear me-from-the-future! Please forgive me for this code.
// If I ever see this again, I will have to start bringing a weapon to work.
// If this condition ever becomes true, please call me at xxx-xxx-xxx for a reward.
// Dear programmer:
//
// When you finish “optimizing” this subroutine
// and realize what a huge mistake it was,
// please increment the counter below as a warning
// for the next guy:
//
// hours_wasted_here = 42
// When I started writing this, only God and I understood what I was doing.
// Now only God does
// Sometimes it seems to me that the compiler ignores all my comments
// I dedicate all my code, all my work to my wife Darlene, who
// will have to support me, our three kids, and the dog when
// this goes into production.
Yes, comments can be very funny. After all, they are written by real people.
GO TO FULL VERSION