Go for JavaScript/TypeScript Developers: Building a Library Management System

I've been hearing about Go since I first started diving deeper into backend development, but I'll admit I took one look at it and thought, "Why would I need this when I already know JavaScript/TypeScript?" I saw what looked like a verbose, statically-typed language and thought, isn't this just making things more complicated?

The turning point came when I learned that the TypeScript team at Microsoft is exploring rewriting parts of the TypeScript compiler in Go for performance reasons. If the team behind TypeScript sees value in Go's approach to types and performance, maybe there's something worth exploring here! ✨

Instead of just focusing on Node.js and TypeScript, I decided to dive deep into Go. After working through the initial learning curve, I finally started to get it, and I began to see why I might want to use Go instead of JavaScript for certain types of applications - and why the TypeScript team might be making this transition.

I tried to condense everything I've learned into a nice introduction specifically for fellow JS/TS developers, so here it is.

🎯 Prerequisites

There are a few fundamental programming concepts you should know in advance before you start playing around with Go. While this tutorial is aimed at JavaScript/TypeScript developers, the core requirements are universal programming basics.

Here are what I consider to be Go prerequisites:

• Basic familiarity with TypeScript (helpful for understanding static typing)
• Understanding of basic programming concepts (variables, functions, loops, etc.)
• Experience with command-line tools
• Compilation concepts: Understanding the difference between compiled and interpreted languages
• Go installed on your system (we'll cover this)

🏆 Goals

• Learn about essential Go concepts and how they compare to JavaScript/TypeScript
• Understand Go's approach to types, error handling, and concurrency
• Build a progressively complex library management CLI tool
• See why Go might be a great addition to your developer toolkit

Here's the source code and what we'll build by the end:

• A full-featured library management system
• Command-line interface with multiple operations
• File persistence and error handling
• Concurrent operations for bulk tasks

🤔 What is Go?

Go is a statically typed, compiled programming language developed at Google.

• Go is an open-source project created by Google in 2009
• Go is used to build high-performance backend services, CLI tools, and system software
• Go compiles to a single binary with no runtime dependencies (unlike Node.js)

One of the most important aspects of Go is that it's designed for simplicity and performance. Coming from JavaScript, you might initially find Go verbose, but you'll quickly appreciate its explicitness and reliability.

Go excels at:

• Performance: Much faster than Node.js for CPU-intensive tasks
• Concurrency: Built-in goroutines make concurrent programming simple
• Deployment: Single binary, no dependency management nightmares
• Error handling: Explicit error handling prevents runtime surprises

🔥 Go vs TypeScript: Type Systems Compared

Before we start building, it's crucial to understand how Go's type system differs from TypeScript. This comparison will save you mental friction throughout the tutorial.

Static Typing Philosophy

TypeScript: TypeScript adds types on top of JavaScript's dynamic nature. It's a gradual typing system - you can mix typed and untyped code, and types are erased at runtime.

// TypeScript - optional typing, gradual adoption
let name = "Alice";  // inferred as string
let age: number = 25; // explicit typing
let data: any = getSomeData(); // escape hatch

Go: Go is statically typed from the ground up. Every value has a type at compile time, and there's no runtime type erasure because types are part of the language design.

// Go - types are always present, even when inferred
var name string = "Alice"  // explicit
age := 25                  // inferred as int, but still strongly typed
var data interface{} = getSomeData() // closest to 'any', but not recommended

💡 For TypeScript Developers: Go's interface{} might look like TypeScript's any, but it's fundamentally different. While any disables type checking, interface{} still maintains type safety - you just need type assertions to access the underlying value.

Interface Design: Structural vs Nominal

This is where Go's approach really shines and differs dramatically from TypeScript.

TypeScript - Structural Typing:

interface Writer {
  write(data: string): void;
}

interface Logger {
  write(message: string): void;
}

// These are the same type to TypeScript
const fileWriter: Writer = {
  write: (data: string) => console.log(data)
};

const logger: Logger = fileWriter; // Works! Structural compatibility

Go - Implicit Interface Satisfaction:

// Define interface
type Writer interface {
    Write(data []byte) (int, error)
}

// Any type with matching methods automatically satisfies the interface
type FileWriter struct{}

func (fw FileWriter) Write(data []byte) (int, error) {
    // implementation
    return len(data), nil
}

// No explicit "implements" - it just works!
var writer Writer = FileWriter{}

💡 For TypeScript Developers: Go's interfaces are satisfied implicitly. You don't declare that a type implements an interface - if it has the right methods, it automatically does. This is more flexible than TypeScript's structural typing because it works across package boundaries without coordination.

Error Handling: Exceptions vs Values

TypeScript:

function parseJSON(data: string): object {
  try {
    return JSON.parse(data);
  } catch (error) {
    throw new Error(`Invalid JSON: ${error.message}`);
  }
}

// Caller must remember to handle exceptions
try {
  const result = parseJSON(invalidData);
} catch (error) {
  console.log("Parsing failed:", error.message);
}

Go:

func parseJSON(data string) (map[string]interface{}, error) {
    var result map[string]interface{}
    err := json.Unmarshal([]byte(data), &result)
    if err != nil {
        return nil, fmt.Errorf("invalid JSON: %w", err)
    }
    return result, nil
}

// Errors are values, handling is explicit and visible
result, err := parseJSON(invalidData)
if err != nil {
    fmt.Printf("Parsing failed: %v\n", err)
    return
}

💡 For TypeScript Developers: Go doesn't have exceptions. Errors are returned as values, making error handling explicit and visible in the code. This might feel verbose at first, but it prevents the "forgotten error handling" bugs common in JavaScript/TypeScript.

Memory Management and Performance

TypeScript/JavaScript:

// Garbage collected, dynamic allocation
const users: User[] = [];
for (let i = 0; i < 1000000; i++) {
  users.push({ name: `User${i}`, age: i % 100 });
}
// GC pressure, potential pause times

Go:

// More predictable memory layout, efficient GC
users := make([]User, 0, 1000000) // pre-allocate capacity
for i := 0; i < 1000000; i++ {
    users = append(users, User{
        Name: fmt.Sprintf("User%d", i),
        Age:  i % 100,
    })
}
// Better memory locality, faster execution

💡 For TypeScript Developers: Go gives you more control over memory allocation. The make() function with capacity hints helps avoid repeated reallocations, leading to better performance than JavaScript's dynamic arrays.

Key Mental Model Shifts

1. Types are real: In TypeScript, types are compile-time helpers. In Go, types affect runtime behavior and performance.

2. Explicit is better: Where TypeScript tries to infer and be flexible, Go prefers explicit declarations and clear contracts.

3. Composition over inheritance: Go doesn't have classes. You compose behavior through interfaces and struct embedding.

4. Error handling is part of the type system: Functions that can fail return (result, error) pairs, not exceptions.

Now that we understand these fundamental differences, let's see them in action as we build our library management system.

💡 For TypeScript Developers: Go doesn't have exceptions. Errors are returned as values, making error handling explicit and visible in the code. This might feel verbose at first, but it prevents the "forgotten error handling" bugs common in JavaScript/TypeScript.

⚙️ Setup and Installation

Installing Go

First, you need to install Go on your system. Visit golang.org/dl and download the installer for your operating system.

After installation, verify it works:

go version

Simple Go File Approach

Let's start with the simplest possible approach - a single Go file. This isn't how you'd structure a real Go project, but it's familiar if you're used to running Node.js scripts.

Create a new directory and file:

mkdir go-library
cd go-library
touch main.go

Add this to main.go:

package main

import "fmt"

func main() {
    fmt.Println("Welcome to Go Library Manager!")
}

Run it directly:

go run main.go

You'll see: Welcome to Go Library Manager!

This is similar to running node script.js, but Go is compiling your code behind the scenes.

Proper Go Module Setup

Now let's do it the proper way. Go uses modules (similar to npm packages) to manage dependencies and project structure.

Initialize a new Go module:

go mod init library-manager

This creates a go.mod file (similar to package.json). Now we can build and run our project properly:

go build
./library-manager  # On Windows: library-manager.exe

Or run directly:

go run .

Go Basics

Before we build our library manager, let's explore the fundamental differences you'll encounter. Think of this as your translation guide from TypeScript concepts to Go equivalents.

Variables and Type Declarations

In TypeScript, you might write:

let name = "Alice";           // inferred string
let age: number = 25;         // explicit number
let isActive: boolean = true; // explicit boolean
const PI = 3.14159;          // constant

In Go:

var name string = "Alice"     // explicit type
var age int = 25             // explicit type
var isActive bool = true     // explicit type
const PI = 3.14159          // constant (type inferred)

// Or the short form (Go infers types):
name := "Alice"             // := means "declare and assign"
age := 25                   // inferred as int
isActive := true            // inferred as bool

💡 For TypeScript Developers: The := operator is Go's way of saying "I want to declare a new variable and assign to it in one step." It's like TypeScript's let with automatic type inference, but the variable is still strongly typed.

Key Difference: Go has zero values for all types. If you declare a variable without initializing it, Go gives it a sensible default:

var name string    // "" (empty string)
var age int       // 0
var isActive bool // false
var ptr *int      // nil

This eliminates TypeScript's undefined vs null confusion - Go variables always have a value.

Functions: Explicit Contracts

TypeScript approach:

function greet(name: string): string {
    return `Hello, ${name}!`;
}

// Optional parameters and overloads
function greet(name: string, age?: number): string {
    if (age) {
        return `Hello, ${name}! You're ${age} years old.`;
    }
    return `Hello, ${name}!`;
}

Go's approach:

// Go functions are explicit about inputs and outputs
func greet(name string) string {
    return "Hello, " + name + "!"
}

// Multiple return values (very common pattern)
func greetWithAge(name string, age int) (string, bool) {
    if age < 0 {
        return "", false // return empty string and "invalid" flag
    }
    return fmt.Sprintf("Hello, %s! You're %d years old.", name, age), true
}

// Named return values (optional but helpful for documentation)
// a and b has the same type
func divide(a, b int) (result int, err error) { 
    if b == 0 {
        err = fmt.Errorf("cannot divide by zero")
        return // returns zero value of int and the error
    }
    result = a / b
    return // returns the named values
}

💡 For TypeScript Developers: Go doesn't have function overloading or optional parameters. Instead, you either create separate functions with different names, or use the multiple return values pattern. This might feel limiting at first, but it makes function contracts very clear and predictable.

Error Handling Philosophy

This is probably the biggest mental shift you'll make:

TypeScript's exception-based approach:

function riskyOperation(data: string): User {
    if (!data) {
        throw new Error("Data cannot be empty");
    }
    
    try {
        const parsed = JSON.parse(data);
        return new User(parsed.name, parsed.age);
    } catch (error) {
        throw new Error(`Failed to parse user data: ${error.message}`);
    }
}

// Usage requires try-catch (often forgotten!)
try {
    const user = riskyOperation(userData);
    console.log(user.name);
} catch (error) {
    console.error("Operation failed:", error.message);
}

Go's explicit error handling:

func riskyOperation(data string) (User, error) {
    if data == "" {
        return User{}, fmt.Errorf("data cannot be empty")
    }
    
    var parsed map[string]interface{}
    err := json.Unmarshal([]byte(data), &parsed)
    if err != nil {
        return User{}, fmt.Errorf("failed to parse user data: %w", err)
    }
    
    name, ok := parsed["name"].(string)
    if !ok {
        return User{}, fmt.Errorf("name field missing or invalid")
    }
    
    age, ok := parsed["age"].(float64) // JSON numbers are float64
    if !ok {
        return User{}, fmt.Errorf("age field missing or invalid")
    }
    
    return User{Name: name, Age: int(age)}, nil
}

// Usage - error handling is explicit and visible
user, err := riskyOperation(userData)
if err != nil {
    fmt.Printf("Operation failed: %v\n", err)
    return
}
fmt.Println(user.Name)

💡 For TypeScript Developers: Go's error handling might feel verbose, but it has huge advantages:

1. Errors are visible in function signatures - you can't ignore them accidentally
2. No hidden control flow - no exceptions jumping around your code
3. Better debugging - error paths are explicit and traceable
4. Performance - no expensive exception unwinding

Type Safety and Interface

One area where Go might surprise you:

TypeScript's any type:

let data: any = getSomeData();
data.foo.bar.baz; // Compiles, but might crash at runtime

Go's interface{}:

var data interface{} = getSomeData()
// data.foo  // This won't compile!

// You must assert the type first
if user, ok := data.(User); ok {
    fmt.Println(user.Name) // Now it's safe
}

// Or use type switch for multiple possibilities
switch v := data.(type) {
case string:
    fmt.Println("Got string:", v)
case User:
    fmt.Println("Got user:", v.Name)
case int:
    fmt.Println("Got number:", v)
default:
    fmt.Println("Unknown type")
}

💡 For TypeScript Developers: Go's interface{} is not an escape hatch like any. It's a way to hold any type, but you must explicitly check and convert before using. This maintains type safety even with dynamic data.

Now let's see these concepts in action as we build our library management system step by step.

Part 1: Hello Library (Basic Syntax) 👋

Let's start building our library management system. This first part will feel familiar if you're coming from Node.js, but notice the subtle yet important differences.

Replace your main.go with:

package main

import (
    "bufio"
    "fmt"
    "os"
    "strings"
)

func main() {
    fmt.Println("=== Welcome to Go Library Manager ===")
    
    reader := bufio.NewReader(os.Stdin)
    fmt.Print("Enter your name: ")
    
    name, _ := reader.ReadString('\n')
    name = strings.TrimSpace(name)
    
    fmt.Printf("Hello, %s! Ready to manage some books?\n", name)
}

Let's break down what's happening here and why it's different from TypeScript/Node.js:

Package and Imports

package main

import (
    "bufio"
    "fmt"
    "os"
    "strings"
)

💡 For TypeScript Developers: Unlike Node.js modules or ES6 imports, Go's import system is more explicit and structured:

• package main declares this as an executable program (like having a main() in C++)
• All imports must be used (unused imports cause compilation errors)
• No default imports - you import specific packages by name
• Standard library packages don't need installation (unlike npm install)

Input Handling

reader := bufio.NewReader(os.Stdin)
fmt.Print("Enter your name: ")
name, _ := reader.ReadString('\n')
name = strings.TrimSpace(name)

Compare this to Node.js:

// Node.js/TypeScript approach
import readline from 'readline';

const rl = readline.createInterface({
  input: process.stdin,
  output: process.stdout
});

rl.question('Enter your name: ', (name) => {
  console.log(`Hello, ${name.trim()}! Ready to manage some books?`);
  rl.close();
});

💡 For TypeScript Developers: Notice several key differences:

1. Synchronous by default: Go's ReadString blocks until input is received, no callbacks needed
2. Multiple return values: name, _ := reader.ReadString('\n') returns both the string and an error
3. Explicit error ignoring: The _ means "I'm intentionally ignoring this error" (we'll fix this later)
4. No automatic string methods: We need strings.TrimSpace() instead of name.trim()

Why This Approach?

In TypeScript/Node.js, you might think: "Why is this so verbose? Why not just use a simple input method?"

Go's philosophy: Be explicit about what can fail. Even simple input operations can error (what if stdin is closed?), so Go makes you acknowledge this possibility, even if you choose to ignore it.

Try running this version:

go run main.go

What you'll notice:

• Faster startup than Node.js (no JavaScript engine initialization)
• Clear error messages if something goes wrong (compilation catches issues early)
• Predictable behavior - no hidden asynchronous operations

Quick Exercise: Before moving to the next part, try breaking this code intentionally:

1. Remove one of the imports - what happens?
2. Add an unused import - what happens?
3. Comment out the strings.TrimSpace() line and see how input behaves

This first part establishes the foundation, but already shows Go's core principles: explicitness, predictability, and compile-time safety.

Part 2: Single Book Tracker (Data Types & Conditionals) 📚

Now let's track a single book and introduce Go's approach to data and control flow. Before you read the code, think about how you'd structure this in TypeScript - what would your data model look like?

package main

import (
    "bufio"
    "fmt"
    "os"
    "strings"
)

func main() {
    // Book data - like a simple JS object, but with explicit types
    var bookTitle string = "The Go Programming Language"
    var bookAuthor string = "Donovan & Kernighan"
    var isAvailable bool = true
    
    reader := bufio.NewReader(os.Stdin)
    
    for {
        fmt.Println("\n=== Library Manager ===")
        fmt.Println("1. View book")
        fmt.Println("2. Check out book")
        fmt.Println("3. Return book")
        fmt.Println("4. Exit")
        fmt.Print("Choose option: ")
        
        input, _ := reader.ReadString('\n')
        choice := strings.TrimSpace(input)
        
        switch choice {
        case "1":
            fmt.Printf("\nTitle: %s\n", bookTitle)
            fmt.Printf("Author: %s\n", bookAuthor)
            if isAvailable {
                fmt.Println("Status: Available")
            } else {
                fmt.Println("Status: Checked Out")
            }
            
        case "2":
            if isAvailable {
                isAvailable = false
                fmt.Println("Book checked out successfully!")
            } else {
                fmt.Println("Sorry, book is already checked out.")
            }
            
        case "3":
            if !isAvailable {
                isAvailable = true
                fmt.Println("Book returned successfully!")
            } else {
                fmt.Println("Book is already available.")
            }
            
        case "4":
            fmt.Println("Goodbye!")
            return
            
        default:
            fmt.Println("Invalid option. Please try again.")
        }
    }
}

Let's explore what's happening here and how it compares to TypeScript:

Data Management Comparison

How you might structure this in TypeScript:

interface Book {
  title: string;
  author: string;
  isAvailable: boolean;
}

const book: Book = {
  title: "The Go Programming Language",
  author: "Donovan & Kernighan",
  isAvailable: true
};

Go's current approach:

var bookTitle string = "The Go Programming Language"
var bookAuthor string = "Donovan & Kernighan"  
var isAvailable bool = true

💡 For TypeScript Developers: Right now we're using separate variables because we haven't introduced structs yet. This is intentionally showing you the "primitive" approach first. Notice how Go requires explicit type declarations - there's no implicit object creation like in JavaScript.

Control Flow: Switch vs If-Else Chains

TypeScript developers often write:

if (choice === "1") {
    // view book
} else if (choice === "2") {
    // check out
} else if (choice === "3") {
    // return
} else if (choice === "4") {
    // exit
} else {
    // invalid
}

Go's switch is cleaner:

switch choice {
case "1":
    // view book
case "2":
    // check out
case "3":
    // return 
case "4":
    return
default:
    // invalid
}

💡 For TypeScript Developers: Go's switch has important differences:

1. No fall-through by default - each case automatically breaks (no need for break statements)
2. Any type can be switched on - not just numbers like in C
3. No parentheses needed around the switch expression
4. More readable for multiple conditions than if-else chains

The Infinite Loop Pattern

for {
    // menu logic
}

Compare to TypeScript:

while (true) {
    // menu logic
}

💡 For TypeScript Developers: Go's for is more versatile than most languages. It can be:

• for { } - infinite loop (like while(true))
• for condition { } - conditional loop (like while(condition))
• for i := 0; i < 10; i++ { } - traditional for loop
• for index, value := range items { } - iteration (like for...of)

Try This: Run the program and test all the menu options. Notice:

• How responsive it feels compared to Node.js applications
• Clear error messages if you make mistakes
• Predictable state changes - no hidden mutations or side effects

Thinking Exercise: Before we move to Part 3, consider:

• What would happen if we wanted to track 10 books this way?
• How would you modify this code to track multiple books?
• What TypeScript data structures would you use?

Keep these questions in mind as we tackle multiple books in the next part using Go's slice system.

Part 3: Book Collection (Arrays/Slices & Loops) 📖

Now we tackle the limitation of our single-book system. Before diving into the code, consider this: How would you represent multiple books in TypeScript? An array of objects, right? Go has a similar concept called slices, but they work quite differently under the hood.

Let's manage multiple books using Go's slices:

package main

import (
    "bufio"
    "fmt"
    "os"
    "strings"
)

func main() {
    // Slice of books - similar to JS array, but with important differences
    books := []map[string]interface{}{
        {"title": "The Go Programming Language", "author": "Donovan & Kernighan", "available": true},
        {"title": "Clean Code", "author": "Robert Martin", "available": true},
        {"title": "The Pragmatic Programmer", "author": "Hunt & Thomas", "available": false},
    }
    
    reader := bufio.NewReader(os.Stdin)
    
    for {
        fmt.Println("\n=== Library Manager ===")
        fmt.Println("1. List all books")
        fmt.Println("2. Search books")
        fmt.Println("3. Check out book")
        fmt.Println("4. Return book")
        fmt.Println("5. Exit")
        fmt.Print("Choose option: ")
        
        input, _ := reader.ReadString('\n')
        choice := strings.TrimSpace(input)
        
        switch choice {
        case "1":
            listBooks(books)
        case "2":
            searchBooks(books, reader)
        case "3":
            checkOutBook(books, reader)
        case "4":
            returnBook(books, reader)
        case "5":
            fmt.Println("Goodbye!")
            return
        default:
            fmt.Println("Invalid option. Please try again.")
        }
    }
}

func listBooks(books []map[string]interface{}) {
    fmt.Println("\n=== All Books ===")
    for i, book := range books {
        status := "Available"
        if !book["available"].(bool) {
            status = "Checked Out"
        }
        fmt.Printf("%d. %s by %s - %s\n", 
            i+1, book["title"], book["author"], status)
    }
}

func searchBooks(books []map[string]interface{}, reader *bufio.Reader) {
    fmt.Print("Enter search term: ")
    searchTerm, _ := reader.ReadString('\n')
    searchTerm = strings.ToLower(strings.TrimSpace(searchTerm))
    
    fmt.Println("\n=== Search Results ===")
    found := false
    
    for i, book := range books {
        title := strings.ToLower(book["title"].(string))
        author := strings.ToLower(book["author"].(string))
        
        if strings.Contains(title, searchTerm) || strings.Contains(author, searchTerm) {
            status := "Available"
            if !book["available"].(bool) {
                status = "Checked Out"
            }
            fmt.Printf("%d. %s by %s - %s\n", 
                i+1, book["title"], book["author"], status)
            found = true
        }
    }
    
    if !found {
        fmt.Println("No books found matching your search.")
    }
}

func checkOutBook(books []map[string]interface{}, reader *bufio.Reader) {
    listBooks(books)
    fmt.Print("Enter book number to check out: ")
    
    input, _ := reader.ReadString('\n')
    var bookNum int
    fmt.Sscanf(strings.TrimSpace(input), "%d", &bookNum)
    
    if bookNum < 1 || bookNum > len(books) {
        fmt.Println("Invalid book number.")
        return
    }
    
    book := books[bookNum-1]
    if book["available"].(bool) {
        book["available"] = false
        fmt.Printf("'%s' checked out successfully!\n", book["title"])
    } else {
        fmt.Printf("'%s' is already checked out.\n", book["title"])
    }
}

func returnBook(books []map[string]interface{}, reader *bufio.Reader) {
    fmt.Println("\n=== Checked Out Books ===")
    hasCheckedOut := false
    
    for i, book := range books {
        if !book["available"].(bool) {
            fmt.Printf("%d. %s by %s\n", 
                i+1, book["title"], book["author"])
            hasCheckedOut = true
        }
    }
    
    if !hasCheckedOut {
        fmt.Println("No books are currently checked out.")
        return
    }
    
    fmt.Print("Enter book number to return: ")
    input, _ := reader.ReadString('\n')
    var bookNum int
    fmt.Sscanf(strings.TrimSpace(input), "%d", &bookNum)
    
    if bookNum < 1 || bookNum > len(books) {
        fmt.Println("Invalid book number.")
        return
    }
    
    book := books[bookNum-1]
    if !book["available"].(bool) {
        book["available"] = true
        fmt.Printf("'%s' returned successfully!\n", book["title"])
    } else {
        fmt.Printf("'%s' is already available.\n", book["title"])
    }
}

Breaking Down the Key Concepts

Let's compare this data structure approach:

TypeScript approach you might use:

interface Book {
  title: string;
  author: string;
  available: boolean;
}

const books: Book[] = [
  { title: "The Go Programming Language", author: "Donovan & Kernighan", available: true },
  { title: "Clean Code", author: "Robert Martin", available: true },
  { title: "The Pragmatic Programmer", author: "Hunt & Thomas", available: false }
];

Go's current approach:

books := []map[string]interface{}{
    {"title": "The Go Programming Language", "author": "Donovan & Kernighan", "available": true},
    {"title": "Clean Code", "author": "Robert Martin", "available": true}, 
    {"title": "The Pragmatic Programmer", "author": "Hunt & Thomas", "available": false},
}

💡 For TypeScript Developers: This looks similar but works very differently:

• []map[string]interface{} is Go's way of saying "slice of maps from string keys to any value type"
• interface{} is like TypeScript's unknown type - you need explicit type assertions to use values
• This approach is actually awkward in Go (we'll fix it with structs in part 4)

The Power of Range Loops

TypeScript iteration:

books.forEach((book, index) => {
  console.log(`${index + 1}. ${book.title} by ${book.author}`);
});

// Or with for...of
for (const [index, book] of books.entries()) {
  console.log(`${index + 1}. ${book.title} by ${book.author}`);
}

Go's range pattern:

for i, book := range books {
    fmt.Printf("%d. %s by %s\n", 
        i+1, book["title"], book["author"])
}

💡 For TypeScript Developers: Go's range gives you both index and value automatically. You can also:

• for i := range books - just get indices (like Object.keys())
• for _, book := range books - just get values (like Object.values())
• The _ means "I don't need this value"

Type Assertions: The Price of Dynamic Data

Notice this pattern throughout the code:

book["available"].(bool)  // Type assertion
book["title"].(string)    // Type assertion

Compare to TypeScript:

book.available  // TypeScript knows this is boolean
book.title     // TypeScript knows this is string

💡 For TypeScript Developers: Go's type assertions are necessary because interface{} could hold any type. The syntax value.(Type) means "I believe this value is of Type, please convert it." If you're wrong, the program panics!

Function Organization and Parameters

Notice our function signatures:

func listBooks(books []map[string]interface{}) {
    // ...
}

func searchBooks(books []map[string]interface{}, reader *bufio.Reader) {
    // ...
}

Compare to TypeScript:

function listBooks(books: Book[]): void {
    // ...
}

function searchBooks(books: Book[], reader: NodeJS.ReadStream): void {
    // ...
}

💡 For TypeScript Developers:

• Go functions are explicit about all parameters - no global variables or implicit dependencies
• *bufio.Reader is a pointer - we'll dive into pointers later, but think of it as "pass by reference"
• Functions that don't return values don't need explicit void return type

The Growing Complexity Problem

By now, you might notice this approach is getting unwieldy:

[]map[string]interface{}  // This type signature is everywhere
book["title"].(string)    // Type assertions everywhere

Take a moment to think:

• How would you solve this growing complexity in TypeScript?
• What would make this code cleaner and more maintainable?
• Where do you see the most repetition that could be eliminated?

This is exactly why we need structs! Part 4 will transform this verbose, error-prone approach into something clean and type-safe.

Try this part and notice:

• The awkwardness of type assertions everywhere
• How easy it is to make mistakes with string keys
• The verbose function signatures

Keep these pain points in mind - they'll make you appreciate Go's struct system even more in the next part.

Part 4: Proper Books (Structs) 🏗️

If you felt frustrated with all those type assertions in Part 3, you're thinking like a Go developer! This part introduces structs - Go's solution to the type safety and organization problems we've been encountering.

Before you see the code, pause and think: How would you design a better Book type in TypeScript? What would it look like? Keep that mental model as we explore Go's approach.

Structs are Go's way of creating custom types - similar to TypeScript interfaces, but with more capabilities:

package main

import (
    "bufio"
    "fmt"
    "os"
    "strings"
)

// Book struct - Go's version of a TypeScript interface with methods
type Book struct {
    Title     string
    Author    string
    Available bool
}

// Methods on Book struct - like class methods, but attached to the type
func (b *Book) CheckOut() bool {
    if b.Available {
        b.Available = false
        return true
    }
    return false
}

func (b *Book) Return() bool {
    if !b.Available {
        b.Available = true
        return true
    }
    return false
}

func (b Book) Status() string {
    if b.Available {
        return "Available"
    }
    return "Checked Out"
}

func main() {
    // Initialize books with struct literals - much cleaner!
    books := []Book{
        {Title: "The Go Programming Language", Author: "Donovan & Kernighan", Available: true},
        {Title: "Clean Code", Author: "Robert Martin", Available: true},
        {Title: "The Pragmatic Programmer", Author: "Hunt & Thomas", Available: false},
    }
    
    reader := bufio.NewReader(os.Stdin)
    
    for {
        fmt.Println("\n=== Library Manager ===")
        fmt.Println("1. List all books")
        fmt.Println("2. Search books")
        fmt.Println("3. Check out book")
        fmt.Println("4. Return book")
        fmt.Println("5. Add new book")
        fmt.Println("6. Exit")
        fmt.Print("Choose option: ")
        
        input, _ := reader.ReadString('\n')
        choice := strings.TrimSpace(input)
        
        switch choice {
        case "1":
            listBooks(books)
        case "2":
            searchBooks(books, reader)
        case "3":
            checkOutBook(books, reader)
        case "4":
            returnBook(books, reader)
        case "5":
            books = addBook(books, reader)
        case "6":
            fmt.Println("Goodbye!")
            return
        default:
            fmt.Println("Invalid option. Please try again.")
        }
    }
}

func listBooks(books []Book) {
    fmt.Println("\n=== All Books ===")
    for i, book := range books {
        fmt.Printf("%d. %s by %s - %s\n", 
            i+1, book.Title, book.Author, book.Status())
    }
}

func searchBooks(books []Book, reader *bufio.Reader) {
    fmt.Print("Enter search term: ")
    searchTerm, _ := reader.ReadString('\n')
    searchTerm = strings.ToLower(strings.TrimSpace(searchTerm))
    
    fmt.Println("\n=== Search Results ===")
    found := false
    
    for i, book := range books {
        title := strings.ToLower(book.Title)
        author := strings.ToLower(book.Author)
        
        if strings.Contains(title, searchTerm) || strings.Contains(author, searchTerm) {
            fmt.Printf("%d. %s by %s - %s\n", 
                i+1, book.Title, book.Author, book.Status())
            found = true
        }
    }
    
    if !found {
        fmt.Println("No books found matching your search.")
    }
}

func checkOutBook(books []Book, reader *bufio.Reader) {
    listBooks(books)
    fmt.Print("Enter book number to check out: ")
    
    input, _ := reader.ReadString('\n')
    var bookNum int
    fmt.Sscanf(strings.TrimSpace(input), "%d", &bookNum)
    
    if bookNum < 1 || bookNum > len(books) {
        fmt.Println("Invalid book number.")
        return
    }
    
    book := &books[bookNum-1]  // Get pointer to modify original
    if book.CheckOut() {
        fmt.Printf("'%s' checked out successfully!\n", book.Title)
    } else {
        fmt.Printf("'%s' is already checked out.\n", book.Title)
    }
}

func returnBook(books []Book, reader *bufio.Reader) {
    fmt.Println("\n=== Checked Out Books ===")
    hasCheckedOut := false
    
    for i, book := range books {
        if !book.Available {
            fmt.Printf("%d. %s by %s\n", 
                i+1, book.Title, book.Author)
            hasCheckedOut = true
        }
    }
    
    if !hasCheckedOut {
        fmt.Println("No books are currently checked out.")
        return
    }
    
    fmt.Print("Enter book number to return: ")
    input, _ := reader.ReadString('\n')
    var bookNum int
    fmt.Sscanf(strings.TrimSpace(input), "%d", &bookNum)
    
    if bookNum < 1 || bookNum > len(books) {
        fmt.Println("Invalid book number.")
        return
    }
    
    book := &books[bookNum-1]
    if book.Return() {
        fmt.Printf("'%s' returned successfully!\n", book.Title)
    } else {
        fmt.Printf("'%s' is already available.\n", book.Title)
    }
}

func addBook(books []Book, reader *bufio.Reader) []Book {
    fmt.Print("Enter book title: ")
    title, _ := reader.ReadString('\n')
    title = strings.TrimSpace(title)
    
    fmt.Print("Enter book author: ")
    author, _ := reader.ReadString('\n')
    author = strings.TrimSpace(author)
    
    newBook := Book{
        Title:     title,
        Author:    author,
        Available: true,
    }
    
    books = append(books, newBook)
    fmt.Printf("Added '%s' by %s to the library!\n", title, author)
    
    return books
}