Introduction

In this lesson, you'll learn about introduction in Go. Coming from C#, you already have a foundation for understanding this concept. We'll build on that knowledge while highlighting the key differences.

Mirror Card

From C#:

In C#, you're familiar with introduction.

In Go:

Go has its own approach to introduction, which we'll explore step by step.

The Go Way

Let's see how Go handles this concept. Here's a typical example:

Go Example

package main

import "fmt"

func main() {
    fmt.Println("Hello, Go!")
}

Comparing to C#

Here's how you might have written similar code in C#:

C# (What you know)

using System;

class Hello {
    static void Main() {
        Console.WriteLine("Hello, Go!");
    }
}

Mirror Card

From C#:

You may be used to different syntax or behavior.

In Go:

Go uses 'package main' and 'func main()' as the entry point — no class needed

Mirror Card

From C#:

You may be used to different syntax or behavior.

In Go:

import uses string paths ("fmt") instead of C# namespace identifiers

Mirror Card

From C#:

You may be used to different syntax or behavior.

In Go:

Go compiles to a single native binary — no runtime required on deployment

Mirror Card

From C#:

You may be used to different syntax or behavior.

In Go:

Both C# and Go have a garbage collector

Mirror Card

From C#:

You may be used to different syntax or behavior.

In Go:

Go is intentionally minimal — fewer features than C# by design

Step-by-Step Breakdown

1. Package and Entry Point

Every Go file belongs to a package. Executable programs must be in 'package main'. The entry function is func main() — no class, no static modifier.

using System;
class Program {
    static void Main(string[] args) {
        Console.WriteLine("Hello");
    }
}

package main

import "fmt"

func main() {
    fmt.Println("Hello")
}

2. Imports

Go imports are string-based package paths. 'fmt' is the formatting/printing package. Unused imports are a compile error in Go.

using System;
using System.Collections.Generic;

import "fmt"
import "strings"

// Or grouped:
import (
    "fmt"
    "strings"
    "net/http"
)

Common Pitfall

Importing a package you do not use is a compile error in Go. This enforces clean code at the language level.

3. Native Binary vs Managed Runtime

C# compiles to IL and needs the .NET runtime. Go compiles to a self-contained native binary — no installer, no runtime dependency.

// C# output: MyApp.dll + .NET runtime required
// dotnet run  OR  dotnet MyApp.dll

// Go output: single native binary
// go build -o myapp
// ./myapp        <-- runs anywhere, no runtime needed

// Or run directly (compile + run):
// go run main.go

Rule of Thumb

Go binaries are perfect for Docker containers and cloud functions — the image can be FROM scratch with just the binary.

4. Go's Intentional Minimalism

Go deliberately omits many C# features: no classes, no exceptions, no generics until Go 1.18, no method overloading. This forces consistent, readable code across teams.

// Things Go does NOT have (vs C#):
// - classes (use structs + methods)
// - exceptions (use error return values)
// - method overloading
// - operator overloading
// - implicit type conversions
// - ternary operator (a ? b : c)
// - while loop (use for)

// Things Go DOES have:
// - goroutines (lightweight threads)
// - channels (typed message passing)
// - interfaces (structural/implicit)
// - garbage collector

Common Mistakes

When coming from C#, developers often make these mistakes:

Go uses 'package main' and 'func main()' as the entry point — no class needed
import uses string paths ("fmt") instead of C# namespace identifiers
Go compiles to a single native binary — no runtime required on deployment

Common Pitfall

Don't assume Go works exactly like C#. While the concepts may be similar, the syntax and behavior can differ significantly.

Key Takeaways

'package main' + 'func main()' is the entry point — no class needed
Go imports are string paths; unused imports are compile errors
Go compiles to a self-contained native binary — no runtime required
Go is intentionally minimal — fewer features enforce consistent code

Rule of Thumb

The best way to learn is by doing. Try rewriting some of your C# code in Go to practice these concepts.

Introduction

Mirror Card

From C#:

In C#, you're familiar with introduction.

In Go:

Go has its own approach to introduction, which we'll explore step by step.

The Go Way

Let's see how Go handles this concept. Here's a typical example:

Go Example

package main

import "fmt"

func main() {
    fmt.Println("Hello, Go!")
}

Comparing to C#

Here's how you might have written similar code in C#:

C# (What you know)

using System;

class Hello {
    static void Main() {
        Console.WriteLine("Hello, Go!");
    }
}

Mirror Card

From C#:

You may be used to different syntax or behavior.

In Go:

Go uses 'package main' and 'func main()' as the entry point — no class needed

Mirror Card

From C#:

You may be used to different syntax or behavior.

In Go:

import uses string paths ("fmt") instead of C# namespace identifiers

Mirror Card

From C#:

You may be used to different syntax or behavior.

In Go:

Go compiles to a single native binary — no runtime required on deployment

Mirror Card

From C#:

You may be used to different syntax or behavior.

In Go:

Both C# and Go have a garbage collector

Mirror Card

From C#:

You may be used to different syntax or behavior.

In Go:

Go is intentionally minimal — fewer features than C# by design

Step-by-Step Breakdown

1. Package and Entry Point

Every Go file belongs to a package. Executable programs must be in 'package main'. The entry function is func main() — no class, no static modifier.

using System;
class Program {
    static void Main(string[] args) {
        Console.WriteLine("Hello");
    }
}

package main

import "fmt"

func main() {
    fmt.Println("Hello")
}

2. Imports

Go imports are string-based package paths. 'fmt' is the formatting/printing package. Unused imports are a compile error in Go.

using System;
using System.Collections.Generic;

import "fmt"
import "strings"

// Or grouped:
import (
    "fmt"
    "strings"
    "net/http"
)

Common Pitfall

Importing a package you do not use is a compile error in Go. This enforces clean code at the language level.

3. Native Binary vs Managed Runtime

C# compiles to IL and needs the .NET runtime. Go compiles to a self-contained native binary — no installer, no runtime dependency.

// C# output: MyApp.dll + .NET runtime required
// dotnet run  OR  dotnet MyApp.dll

// Go output: single native binary
// go build -o myapp
// ./myapp        <-- runs anywhere, no runtime needed

// Or run directly (compile + run):
// go run main.go

Rule of Thumb

Go binaries are perfect for Docker containers and cloud functions — the image can be FROM scratch with just the binary.

4. Go's Intentional Minimalism

Go deliberately omits many C# features: no classes, no exceptions, no generics until Go 1.18, no method overloading. This forces consistent, readable code across teams.

// Things Go does NOT have (vs C#):
// - classes (use structs + methods)
// - exceptions (use error return values)
// - method overloading
// - operator overloading
// - implicit type conversions
// - ternary operator (a ? b : c)
// - while loop (use for)

// Things Go DOES have:
// - goroutines (lightweight threads)
// - channels (typed message passing)
// - interfaces (structural/implicit)
// - garbage collector

Common Mistakes

When coming from C#, developers often make these mistakes:

Go uses 'package main' and 'func main()' as the entry point — no class needed
import uses string paths ("fmt") instead of C# namespace identifiers
Go compiles to a single native binary — no runtime required on deployment

Common Pitfall

Don't assume Go works exactly like C#. While the concepts may be similar, the syntax and behavior can differ significantly.

Key Takeaways

'package main' + 'func main()' is the entry point — no class needed
Go imports are string paths; unused imports are compile errors
Go compiles to a self-contained native binary — no runtime required
Go is intentionally minimal — fewer features enforce consistent code

Rule of Thumb

The best way to learn is by doing. Try rewriting some of your C# code in Go to practice these concepts.