A searchable reference that lists twelve source-checked Hello World programs in JavaScript, Python, Java, C, C++, C#, Go, Rust, Ruby, PHP, Swift, and Kotlin — filterable by language, runtime, filename, or a short code fragment — is the cleanest Hello World in different programming languages alternative for developers who would rather not hop between blog posts, Stack Overflow answers, and per-language documentation tabs. The reference page holds the twelve snippets side by side, a typical source filename for each, and the broad runtime family so the row maps onto the official compiler or interpreter you have installed locally. Nothing is executed, uploaded, or stored on the page; it is read-only, client-side, and dependency-free, which makes it suitable as a static cheat sheet you can copy from without worrying about telemetry, advertising scripts, or pasted-code escaping issues. Because every row shows the conventional command-line entry point — interpreter invocation, compile-and-run, or .NET project build — the same reference works as a first-run sanity check after installing a new toolchain and as a teaching prop when comparing how a dozen ecosystems express the same one-line message. The reference also names a deliberate scope: Hello World is a narrow path that proves a toolchain works, and the page does not pretend to teach package management, input handling, errors, tests, project layout, or deployment.
Why Hello World Examples End Up Scattered Across the Web
The problem with a typical Hello World search is that the top results contradict each other. One tutorial assumes a graphical application template in Visual Studio; another assumes a Jupyter cell; a third assumes an interactive shell with no file at all; a fourth has not been refreshed since the language changed its standard build command. A snippet written for the previous major version of a compiler can still build today, throw an unused-variable warning, or fail outright because the standard library has moved. When a learner copies the first reasonable-looking example, the inevitable first diagnostic reads like noise — "expected ';'", "unresolved reference", "module not found" — and the connection between the error message and the syntax rule the example was meant to demonstrate is lost.
That scattered experience is the reason a consolidated Hello World in different programming languages reference earns its keep. One row per language, one conventional filename, one current command-line entry point, and one snippet that does not borrow templates from unrelated build systems. The reference reduces the surface area for mixing examples across toolchains and lets the reader pick the row that matches the compiler or interpreter actually installed, instead of reverse-engineering which build system an old blog post was using.
The Twelve Languages and Their Entry Points
The reference presents twelve compact programs that write the same conventional message using each language's standard entry point. Each row names a typical source filename and broad runtime so the snippet can be lifted straight into a file the toolchain will recognise, without mixing examples from unrelated build systems or graphical application templates.
| Language | Typical filename | Runtime family | Conventional entry point |
|---|---|---|---|
| JavaScript | hello.js | Node.js or browser | Top-level script; browser output goes to the developer console |
| Python | hello.py | CPython interpreter | Top-level script with print(); no entry function required |
| Java | HelloWorld.java | JDK / JVM | Public class with public static void main(String[] args) |
| C | hello.c | Native executable | int main(void) returning int |
| C++ | hello.cpp | Native executable | int main() returning int |
| C# | Program.cs | .NET project | Static class with static Main inside a .NET project file |
| Go | hello.go | Native executable | package main with func main() |
| Rust | main.rs | Native executable | fn main() |
| Ruby | hello.rb | CRuby interpreter | Top-level script with puts |
| PHP | hello.php | PHP interpreter | Top-level script wrapped in <?php … ?> |
| Swift | main.swift | Swift toolchain / native | Top-level code in a Swift script, or @main on a type |
| Kotlin | Main.kt | JVM or Kotlin/Native | Top-level fun main() or class with fun main |
The differences between the rows are not stylistic. Quotation marks, semicolons, braces, indentation, include or import statements, and newline escapes are language syntax, and the reference preserves them as such. Python uses indentation for blocks; the C-family examples can fail when pasted into a rich-text editor that replaces straight quotes with curly ones. Some languages permit omitted semicolons while others require them, which is why each snippet must be copied as a complete block rather than assembled line by line.
The reference also flags the conventional command-line entry point per language so a reader does not confuse, for example, a Node.js script and a browser script. JavaScript can run in a browser console or Node.js, but the surrounding globals and module rules differ; the same console.log call writes to the developer console in one environment and to standard output in the other. Standard output may be buffered or redirected on top of that, so the channel the reference documents is the conventional one, not a guarantee about your local terminal.
Find and Copy a Hello World Snippet
The reference is designed around four short steps.
- Open the Hello World in Different Programming Languages reference page in your browser.
- Type a language name, a runtime keyword, the typical filename, or a short code fragment into the search field; the table filters down to matching rows in place.
- Copy the complete snippet from the matching row, including any leading directive line, the imports or includes, and the closing brace or tag.
- Paste the block into a new file named exactly as shown in the filename column, saving with a text encoding the toolchain accepts — UTF-8 for most modern languages, ASCII for older C compilers.
Once the file is saved, the next move is the official toolchain. The reference deliberately stops at the file boundary: a copied snippet cannot resolve PATH, compiler, SDK, or version conflicts on its own, and a one-line example can be valid in an interactive shell while a saved application requires an entry function, class, package declaration, compiler invocation, or project file.
Run the Snippet with the Official Toolchain
After the snippet is on disk in the conventional filename, the path from source to output splits into four practical buckets. Pick the bucket that matches the runtime family column above, and always cross-check against the current official instructions for the language, since toolchains evolve.
Interpreted languages
For Python, Ruby, PHP, and Node.js, there is no separate compile step. Pass the file to the interpreter explicitly so the right version runs — python hello.py, ruby hello.rb, php hello.php, or node hello.js. Interpreter-oriented examples still depend on an installed runtime and a command that selects the intended version, so verify with python --version or node --version before assuming the snippet that ran in an interactive shell will behave the same when launched from a file.
Native compiled languages
For C, C++, Go, Rust, and Swift, an additional step produces an executable before the program runs. Use the current official compiler driver for the language (gcc or clang for C and C++, go build for Go, rustc for Rust, swiftc for Swift), then invoke the resulting binary. Each compiler prints a different first diagnostic when something goes wrong; the contract is to read the first line of the diagnostic and compare it against the filename and version before changing the source.
JVM languages
Java and Kotlin compile to JVM bytecode and then run on the Java Virtual Machine. The conventional flow is javac followed by java for Java, and the Kotlin compiler (or a build tool wrapper) followed by the JVM for Kotlin. Both languages require the class name in the source file to match the public class declared inside, and the Java example specifically needs the surrounding class even though Python does not — that is a difference in entry-point model, not a difference in what the message means.
.NET and browser JavaScript
C# normally builds inside a .NET project, where Program.cs is one file inside a larger csproj structure; running dotnet run inside the project directory builds and executes the program. Browser JavaScript is a separate path: the snippet writes to the developer console rather than the visible page, so the expected output appears in DevTools, not on the rendered DOM.
What the Reference Deliberately Does Not Cover
The reference is narrow on purpose. It demonstrates only the path where source text reaches standard output (or, for browser JavaScript, the developer console). It does not teach package management, input handling, errors, tests, project layout, deployment, or idiomatic architecture. The next table makes that scope explicit so the reader does not blame the reference for gaps that belong to the language's official ecosystem.
| Aspect | Covered by the reference | Handled by the official toolchain, not the reference |
|---|---|---|
| First-run "does it work?" check | Yes — copy, save, run, observe output | — |
| Conventional filename and entry point | Yes — one row per language | — |
| Compiler or interpreter invocation | Signposted, not executed | Run locally with the installed toolchain |
| Standard output and developer console output | Yes — the only output channels | — |
| Input, errors, logging, observability | No | Language standard library and ecosystem tooling |
| Tests | No | Language test runner (pytest, go test, cargo test, etc.) |
| Package management and dependencies | No | pip, npm, cargo, go mod, Maven, NuGet, etc. |
| Project layout, configuration, build files | No | Official build tool (Make, CMake, Gradle, MSBuild, etc.) |
| Deployment | No | Language and platform deployment guides |
| Idiomatic architecture and design patterns | No | Style guides, language tour, real projects |
Production applications should use proper logging rather than leaving tutorial prints scattered through performance-sensitive or privacy-sensitive code. Never log passwords, tokens, cookies, personal data, or confidential business inputs merely to prove that a code path executed; that habit starts with Hello World and persists into production if it is not replaced early.
Verifying a Snippet Against Official Documentation
Because toolchains evolve, the recommended check after copying any snippet is a short comparison against the current official documentation. Two references are worth keeping open while you work, and both are cited below.
- The Python built-in print reference at docs.python.org confirms the signature, the default end separator, and the file argument that the Python snippet in the reference relies on.
- The Rust Book chapter on Hello World at doc.rust-lang.org confirms the fn main() entry point and the println! macro that the Rust snippet uses.
If compilation fails, the contract is straightforward: read the first diagnostic line, confirm the filename and version match the table above, then compare the snippet character-by-character with the official documentation. Eight of the twelve examples in the reference are fixed against the relevant official language documentation, and a cross-language comparison source is used for the remainder, but the official source is always the tie-breaker when commands or filenames have moved.
Quotation marks, semicolons, braces, indentation, and import or include statements are part of the syntax, not decorative differences, so copy the entire block, preserve ASCII punctuation, and save with an encoding the toolchain supports. The reference also protects the twelve records through table-size and uniqueness tests, but the user remains responsible for the local toolchain that actually compiles or interprets the snippet.
After Hello World — Next Steps
A working Hello World is the entry ticket, not the destination. Once the message prints, the reference recommends three small moves:
- Add a tiny test that exercises the entry point — a single assertion that the program's output contains the expected string, run through the language's native test runner.
- Put the source file under version control with an empty initial commit, so future iterations are diffable and reversible.
- Learn the language's official build and dependency workflow — pip and a virtual environment for Python, npm or pnpm for Node.js, cargo for Rust, go mod for Go, the dotnet CLI for .NET, Maven or Gradle for the JVM languages, and the equivalent for any other language on the list.
Keep the first experiment deliberately small and reproducible. Once it builds and tests pass in one shell, the rest of the language — its standard library, ecosystem, idioms, and tooling — is open to explore.