DEV Community: Saleh Rahimzadeh

typed and untyped variables (or constants) in Go (Golang)

Saleh Rahimzadeh — Thu, 13 Mar 2025 08:10:55 +0000

In Go (Golang), the distinction between typed and untyped variables (or constants) is important for understanding how values are treated by the compiler.

1. Typed Variables

A typed variable has an explicitly defined type at compile time.
Once a type is assigned to a variable, it cannot hold values of a different type without explicit conversion.
Typed variables are checked for type safety at compile time.

Example:

var x int = 42      // x is explicitly typed as `int`
var y float64 = 3.14 // y is explicitly typed as `float64`

In this case, x can only hold integer values, and y can only hold floating-point values.

2. Untyped Variables (or Constants)

An untyped variable (or constant) does not have a specific type assigned to it at compile time.
Instead, it has a default type that is inferred based on the context in which it is used.
Untyped values are flexible and can be used in contexts where different types are expected, as long as they are compatible.

Example:

const z = 42 // z is an untyped constant

Here, z is an untyped constant. Its type is not explicitly defined, so it can be used in various contexts where an int, float64, or other compatible types are expected.

Key Differences

Aspect	Typed Variables	Untyped Variables/Constants
Type Definition	Explicitly defined (e.g., `int`, `float64`)	No explicit type; inferred from context
Flexibility	Restricted to the declared type	Can be used in multiple type contexts
Type Safety	Enforced at compile time	Flexible, but may lead to implicit conversions
Example	`var x int = 42`	`const z = 42`

Example of Untyped Constants in Action

package main

import "fmt"

func main() {
    const untypedConst = 42 // untyped constant

    var a int = untypedConst      // works: untypedConst is treated as int
    var b float64 = untypedConst // works: untypedConst is treated as float64

    fmt.Println(a, b) // Output: 42 42
}

In this example, untypedConst is an untyped constant. It can be assigned to both int and float64 variables without explicit conversion because its type is inferred based on the context.

Default Types for Untyped Constants

When an untyped constant is used in a context where a type is required, the compiler assigns it a default type based on its value:

Integer literals: int
Floating-point literals: float64
Complex literals: complex128
Rune literals: rune (alias for int32)
String literals: string

Example:

const c = 42      // default type: int
const d = 3.14    // default type: float64
const e = "hello" // default type: string

reflexive and non-reflexive keys in Go (Golang)

Saleh Rahimzadeh — Thu, 13 Mar 2025 07:13:00 +0000

The terms "reflexive" and "non-reflexive" keys are not standard terminology.
However, based on the context, it seems you might be referring to how keys are used in maps or how they are compared for equality.

Reflexive Key

A reflexive key refers to a key that is equal to itself.
In Go, this is a fundamental property of equality.
For example, if you have a key k, the expression k == k should always evaluate to true.
This is a basic requirement for any key used in a map or for comparison operations.

type MyKey struct {
    ID int
}

k := MyKey{ID: 1}
fmt.Println(k == k) // true (reflexive)

Non-Reflexive Key

A non-reflexive key would imply a key that is not equal to itself, which would violate the basic rules of equality in Go.
Such keys cannot be used in maps or for comparisons because Go requires keys to be reflexive, symmetric, and transitive for correct behavior.

Example of an invalid key (hypothetical, as this would break Go's rules):

// This is not valid Go code, as it violates the reflexive property.
type InvalidKey struct {
    ID int
}

func (k InvalidKey) Equal(other InvalidKey) bool {
    return k.ID != other.ID // Non-reflexive by design
}

k := InvalidKey{ID: 1}
fmt.Println(k.Equal(k)) // false (non-reflexive, invalid in Go)

Key Requirements in Go Maps

In Go, keys used in maps must be comparable. This means:

The key type must support the == and != operators.
The equality comparison must be reflexive (k == k is always true), symmetric (k1 == k2 implies k2 == k1), and transitive (k1 == k2 and k2 == k3 implies k1 == k3).

Common types that can be used as keys in maps include:

Basic types (int, string, float64, etc.)
Structs (if all their fields are comparable)
Arrays (if their element types are comparable)

Types that cannot be used as keys include:

Slices
Maps
Functions
Structs with non-comparable fields (e.g., slices or maps)

PostgreSQL Performance Checklist

Saleh Rahimzadeh — Thu, 20 Feb 2025 08:21:27 +0000

Query Optimization:
- Analyze Query with analyze: Collect statistics on tables and columns.
- Using explain: Shows the execution plan of SQL statement.
- Using vacuum: Garbage collection to reclaim unused hard disk space.
Locking System (table, row)
Indexes (btree, hash, GIN, GIST, BRW)
Normalization & De-normalization
Clustering
Replication
Table inheritance
Constraint execution
SQL constructs:
- Common Table Expression
- Window Functions
- Recursive Queries
Unlogged Tables
Temporary Tables
Materialized Views
Using distinct with consideration
Using joins with consideration
Vertical Scale
Database Caching
Sharding
Partitioning + Trigram Extension + GIN

Difference between calling "panic" and calling "os.Exit(1)" in Go (Golang)

Saleh Rahimzadeh — Thu, 20 Feb 2025 06:01:13 +0000

In Go (Golang), both panic and os.Exit(1) are used to terminate a program, but they do so in different ways and have different implications.

Here's a breakdown of the differences:

1. `panic`

Purpose: panic is used to indicate that something unexpected or unrecoverable has happened in the program. It is typically used for errors that should not occur during normal execution.
Behavior:
- When panic is called, the normal execution of the program is halted.
- The runtime starts unwinding the stack, running any deferred functions (using defer) along the way.
- If no recovery is attempted (using recover), the program will terminate and print a stack trace, which includes the point where the panic was called and the call stack.
Use Case: panic is generally used for programmer errors or unexpected conditions (e.g., accessing a nil pointer, out-of-bounds array access, etc.).
Example:

  func main() {
      defer fmt.Println("This will be printed before the program exits.")
      panic("Something went wrong!")
  }

Output:

  This will be printed before the program exits.
  panic: Something went wrong!
  goroutine 1 [running]:
  main.main()
      /tmp/sandbox123456/main.go:7 +0x95

2. `os.Exit(1)`

Purpose: os.Exit is used to immediately terminate the program with a specified exit code. It is typically used to indicate that the program has failed or completed its task.
Behavior:
- When os.Exit is called, the program terminates immediately without running any deferred functions or cleaning up resources.
- The exit code passed to os.Exit is returned to the operating system. A non-zero exit code (like 1) typically indicates an error or failure.
Use Case: os.Exit is used when you want to terminate the program immediately, without any further processing (e.g., in command-line tools when an error condition is detected).
Example:

  func main() {
      defer fmt.Println("This will NOT be printed.")
      os.Exit(1)
  }

Output:

  (No output, program exits immediately with exit code 1)

Key Differences:

Deferred Functions: panic runs deferred functions before terminating, while os.Exit does not.
Stack Trace: panic generates a stack trace, which can be useful for debugging. os.Exit does not generate a stack trace.
Exit Code: panic does not allow you to specify an exit code directly (it defaults to 2). os.Exit allows you to specify an exit code.
Use Case: panic is for unexpected errors, while os.Exit is for controlled program termination.

When to Use Which:

Use panic when you encounter a situation that should never happen during normal execution (e.g., a bug).
Use os.Exit when you want to terminate the program immediately, typically in response to a known error condition (e.g., invalid command-line arguments).

Recovering from `panic`:

You can recover from a panic using the recover function, which allows you to handle the panic gracefully and continue execution. This is not possible with os.Exit.

Example of recovering from a panic:

func main() {
    defer func() {
        if r := recover(); r != nil {
            fmt.Println("Recovered from panic:", r)
        }
    }()
    panic("Something went wrong!")
}

Output:

Recovered from panic: Something went wrong!

Data Processing Pipeline in Go (Golang)

Saleh Rahimzadeh — Mon, 17 Feb 2025 16:05:07 +0000

Data Processing Pipeline in Go (Golang)

A data processing pipeline is a series of stages or steps where data is processed sequentially.
Each stage performs a specific operation on the data, and the output of one stage becomes the input of the next.
This pattern is commonly used in scenarios like ETL (Extract, Transform, Load), stream processing, or batch processing.

In Go (Golang), pipelines are often implemented using channels and goroutines, which are core features of the language for concurrent programming.
Channels allow you to pass data between stages, and goroutines enable concurrent execution of each stage.

Key Concepts of a Data Processing Pipeline in Go

Stages:
- Each stage is a function that takes input data, processes it, and produces output data.
- Stages are connected via channels.
Channels:
- Channels are used to pass data between stages.
- They ensure safe communication between goroutines.
Goroutines:
- Each stage can run concurrently as a goroutine.
- This allows for efficient utilization of CPU and I/O resources.
Fan-Out and Fan-In:
- Fan-Out: Distributing work across multiple goroutines (parallelism).
- Fan-In: Combining results from multiple goroutines into a single channel.

Simple Data Processing Pipeline

Let’s build a simple pipeline that:

Generates numbers.
Squares the numbers.
Prints the squared numbers.

package main

import "fmt"

// Stage 1: Generate numbers
func generate(count int) <-chan int {
    out := make(chan int)
    go func() {
        defer close(out)
        for n := range count {
            out <- n
        }
    }()
    return out
}

// Stage 2: Square numbers
func square(in <-chan int) <-chan int {
    out := make(chan int)
    go func() {
        defer close(out)
        for n := range in {
            out <- n * n
        }
    }()
    return out
}

// Stage 3: Print numbers
func print(in <-chan int) {
    for n := range in {
        fmt.Println(n)
    }
}

func main() {
    // Set up the pipeline
    numbers := generate(5)
    squaredNumbers := square(numbers)
    print(squaredNumbers)
}

Explanation of the Code

generate function:
- Takes a counter integer, range over it and sends them into a channel.
- Runs in a goroutine to avoid blocking the main program.
square function:
- Reads numbers from the input channel, squares them, and sends the result to the output channel.
- Also runs in a goroutine.
print function:
- Reads squared numbers from the input channel and prints them.
Pipeline Setup:
- The generate function produces numbers.
- The square function processes them.
- The print function consumes the final output.

Adding Concurrency with Fan-Out and Fan-In

To make the pipeline more efficient, you can introduce fan-out (multiple goroutines processing data in parallel) and fan-in (combining results back into a single channel) patterns.

Example: Fan-Out and Fan-In

package main

import (
    "fmt"
    "sync"
)

// Stage 1: Generate numbers
func generate(count int) <-chan int {
    out := make(chan int)
    go func() {
        defer close(out)
        for n := range count {
            out <- n
        }
    }()
    return out
}

// Stage 2: Square numbers (with fan-out)
func square(in <-chan int) <-chan int {
    out := make(chan int)
    var wg sync.WaitGroup

    // Fan-out: Start multiple workers
    worker := func() {
        defer wg.Done()
        for n := range in {
            out <- n * n
        }
    }

    // Start 3 workers
    wg.Add(3)
    go worker()
    go worker()
    go worker()

    // Close the output channel when all workers are done
    go func() {
        wg.Wait()
        close(out)
    }()

    return out
}

// Stage 3: Print numbers
func print(in <-chan int) {
    for n := range in {
        fmt.Println(n)
    }
}

func main() {
    // Set up the pipeline
    numbers := generate(5)
    squaredNumbers := square(numbers)
    print(squaredNumbers)
}

Key Points in the Fan-Out/Fan-In Example

Fan-Out:
- Multiple goroutines (worker) are started to process data concurrently.
- This is useful when the processing stage is CPU-intensive or involves I/O operations.
Fan-In:
- The sync.WaitGroup ensures that the output channel is closed only after all workers are done.
- This combines the results from multiple goroutines into a single channel.
Scalability:
- You can adjust the number of workers based on the available resources (e.g., CPU cores).

Best Practices for Data Processing Pipelines in Go

Use Buffered Channels:
If one stage is slower than others, use buffered channels to avoid blocking.
Graceful Shutdown:
Use context.Context to handle cancellation and timeouts gracefully.
Error Handling:
Propagate errors through channels or use a separate error channel.
Resource Management:
Ensure channels are properly closed to avoid goroutine leaks.
Testing:
Test each stage independently to ensure correctness.

Example with Error Handling and Context:

package main

import (
    "context"
    "fmt"
    "time"
)

// Stage 1: Generate numbers
func generate(ctx context.Context, count int) (<-chan int, <-chan error) {
    out := make(chan int)
    errCh := make(chan error, 1)
    go func() {
        defer close(out)
        defer close(errCh)
        for n := range count {
            select {
            case out <- n:
            case <-ctx.Done():
                errCh <- ctx.Err()
                return
            }
        }
    }()
    return out, errCh
}

// Stage 2: Square numbers
func square(ctx context.Context, in <-chan int) (<-chan int, <-chan error) {
    out := make(chan int)
    errCh := make(chan error, 1)
    go func() {
        defer close(out)
        defer close(errCh)
        for n := range in {
            select {
            case out <- n * n:
            case <-ctx.Done():
                errCh <- ctx.Err()
                return
            }
        }
    }()
    return out, errCh
}

// Stage 3: Print numbers
func print(ctx context.Context, in <-chan int) <-chan error {
    errCh := make(chan error, 1)
    go func() {
        defer close(errCh)
        for n := range in {
            select {
            case <-ctx.Done():
                errCh <- ctx.Err()
                return
            default:
                fmt.Println(n)
            }
        }
    }()
    return errCh
}

func main() {
    const timeout = 2 * time.Second

    ctx, cancel := context.WithTimeout(context.Background(), timeout)
    defer cancel()

    // Set up the pipeline
    numbers, genErr := generate(ctx, 5)
    squaredNumbers, squareErr := square(ctx, numbers)
    printErr := print(ctx, squaredNumbers)

    // Handle errors
    select {
    case err := <-genErr:
        fmt.Println("Error in generate:", err)
    case err := <-squareErr:
        fmt.Println("Error in square:", err)
    case err := <-printErr:
        fmt.Println("Error in print:", err)
    }
}

This example adds error handling and context cancellation to ensure the pipeline can handle errors and timeouts gracefully.

Mathematics for Software Developers

Saleh Rahimzadeh — Fri, 31 Jan 2025 17:31:05 +0000

This article explores essential mathematical books that every software developer should be familiar with.
Whether you're a beginner or an experienced developer looking to refine your skills, these resources will help.

Arithmetic for College Students

Published by Monterey Institute for Technology and Education (MITE) and remixed by David Lippman of Pierce College.

https://www.opentextbookstore.com/arithmetic/book.pdf

Beginning and Intermediate Algebra

by Tyler Wallace

http://www.wallace.ccfaculty.org/book/Beginning_and_Intermediate_Algebra.pdf

Discrete Mathematics An Open Introduction

by Oscar Levin

https://discrete.openmathbooks.org/pdfs/dmoi4.pdf

Zero-Allocation in Go (Golang)

Saleh Rahimzadeh — Wed, 29 Jan 2025 13:56:53 +0000

Go’s Garbage Collector and Zero-Allocation Programming

Go’s garbage collector (GC) is a key feature that simplifies memory management, prevents memory leaks, and eliminates the need for manual deallocation. However, GC comes at a cost. In high-performance applications, even brief GC pauses can introduce latency and jitter, which may become bottlenecks. For real-time systems, prioritizing performance over GC simplicity is often necessary.

To address this, developers can use zero-allocation programming—a technique that minimizes or completely avoids heap allocations, thereby reducing GC overhead. This approach involves optimizing memory usage through efficient allocation strategies, leading to faster and more predictable Go applications.

In this article, we will explore practical methods for reducing heap allocations, optimizing memory efficiency, and writing high-performance Go code.

Why Minimize Allocations?

Although Go’s garbage collector is designed for efficiency, excessive heap allocations can introduce performance challenges:

Increased Latency: Each garbage collection cycle adds processing time, which can be problematic for applications that require consistent response times.
Higher CPU Usage: The GC consumes valuable CPU cycles that could otherwise be used for critical computations.
Unpredictable Pauses: Despite improvements in Go’s GC, occasional pauses still occur, making performance less predictable.

By adopting zero-allocation techniques, developers can significantly reduce the garbage collector’s workload, leading to smoother and more reliable application performance.

Challenges of Zero-Allocation Programming

While zero-allocation programming can enhance performance, it comes with certain trade-offs and risks:

Readability vs. Performance: Optimizing for zero allocations can make code more complex and harder to read. It’s essential to balance performance improvements with maintainability.
Manual Memory Management Risks: Go developers typically rely on the garbage collector, so manually managing memory (e.g., using object pools or pre-allocated buffers) can introduce logical errors, such as accessing data after it has been released.
The Need for Profiling: Always profile your application before and after applying optimizations. Tools like pprof help ensure that zero-allocation techniques actually improve performance without making the code unnecessarily difficult to maintain.

Key Strategies for Zero Allocation Programming

1. Efficient string concatenation

Strings in Go are immutable, meaning each modification creates a new string. To avoid frequent string allocations use strings.Builder and bytes.Buffer for string concatenation and avoid using + for concatenating multiple strings in a loop.

Bad:

s := "Hello"
s += " "
s += "World"

Good:

import (
   "bytes"
   "strings"
)

func main() {
    // Using `bytes.Buffer`
    var buffer bytes.Buffer
    buffer.WriteString("Hello")
    buffer.WriteString(" ")
    buffer.WriteString("World")
    fmt.Println(buffer.String()) // Output: Hello World

    // Using `strings.Builder`:
    var builder strings.Builder
    builder.Grow(100) // Optionally pre-allocate space, pre-growing the builder helps avoid unnecessary reallocations.
    builder.WriteString("Hello")
    builder.WriteString(" ")
    builder.WriteString("World")
    fmt.Println(builder.String()) // Output: Hello World
}

2. Preallocating slices to prevent resizing

Instead of appending to a slice dynamically (which may cause reallocation), preallocate it.
Uncontrolled growth of a slice often results in heap allocations. By carefully managing slice capacities or avoiding unnecessary resizes, you can keep slices on the stack rather than the heap.

func main() {
    // Instead of dynamic appends
    var data []int
    for i := 0; i < 1000; i++ {
        data = append(data, i) // May cause reallocations
    }

    // Preallocate the slice
    dataOptimized := make([]int, 0, 1000) // Capacity set to 1000
    for i := 0; i < 1000; i++ {
        dataOptimized = append(dataOptimized, i) // No reallocations
    }

    fmt.Println(len(dataOptimized), cap(dataOptimized)) // Output: 1000 1000
}

3. Using `copy()` Instead of `append()` for Slices

Appending slices dynamically may cause reallocation. Using copy() is more efficient.

func main() {
    src := []int{1, 2, 3, 4, 5}
    dst := make([]int, len(src))

    copy(dst, src) // No allocations; just copies data

    fmt.Println(dst) // Output: [1 2 3 4 5]
}

4. Pre-Allocating Buffers

Allocating memory dynamically at runtime often leads to heap allocations, which the GC must eventually reclaim. Instead of creating new slices or buffers on the fly, pre-allocating reusable buffers helps minimize allocations.

func processInput(inputs [][]byte) {
    buffer := make([]byte, 1024) // Pre-allocate a fixed-size buffer

    for _, input := range inputs {
        n := copy(buffer, input)
        // Process 'buffer' without creating new slices
        // The buffer can be reused across multiple iterations
        fmt.Printf("Processed %d bytes\n", n)
    }
}

5. Using Stack Instead of Heap (Avoiding Escape Analysis Issues)

If a variable is used only within a function, Go's escape analysis may allow it to stay on the stack instead of allocating on the heap.

escape analysis — a compiler technique that determines whether a variable can be safely allocated on the stack or must escape to the heap.

Avoid returning pointers to local variables unless absolutely necessary.
Prefer values over pointers when the object size is small.

func processData() int {
    i := 93
    return i // The compiler can allocate 'i' on the stack
}

func processPointer() *int {
    i := 93
    return &i // 'i' escapes to the heap, leading to allocation
}

6. Minimize Allocations in Hot Paths

Hot paths are parts of your code that are frequently executed (e.g., request handlers, loop iterations). Eliminating allocations in these critical sections can lead to major performance gains.

func calculate(inputs []int) int {
    sum := 0
    for _, val := range inputs {
        sum += val // No allocation occurs here
    }
    return sum
}

7. Using Structs Instead of Maps for Fixed Keys

Maps allocate memory dynamically. If keys are known beforehand, use structs. So structs have a fixed memory layout, reducing dynamic allocations.

// Instead of a map
type Person struct {
    Name string
    Age  int
}

func main() {
    p := Person{Name: "Alice", Age: 30}
    fmt.Println(p.Name, p.Age) // Output: Alice 30
}

8. Using `sync.Pool` for Object Reuse

Instead of frequently allocating and deallocating objects, use sync.Pool to reuse them.
The sync.Pool is a powerful tool for managing temporary objects that are frequently used and discarded. It helps mitigate the cost of allocation and garbage collection by keeping reusable objects available for use.

import (
    "fmt"
    "sync"
)

var bufferPool = sync.Pool{
    New: func() any {
        return make([]byte, 1024) // Preallocate a 1KB buffer
    },
}

func main() {
    // Get a buffer from the pool
    buf := bufferPool.Get().([]byte)

    // Use the buffer
    copy(buf, "Hello, Zero Allocation!")

    // Put the buffer back into the pool
    bufferPool.Put(buf)

    fmt.Println(string(buf[:21])) // Output: Hello, Zero Allocation!
}

Compile-Time Assertions in Go (Golang)

Saleh Rahimzadeh — Mon, 13 Jan 2025 17:21:23 +0000

A compile-time assertion is a mechanism used to enforce certain conditions or constraints at compile time rather than at runtime. If the condition is not met, the compilation process fails, and an error is generated. This is particularly useful for catching errors early in the development process, ensuring that certain invariants or assumptions hold true before the program is even executed.

Compile-time assertions are often used to:

Ensure the size of a data structure is as expected.
Verify that certain constants or expressions evaluate to specific values.
Enforce type constraints or other compile-time checks.

Compile-Time Assertions in Go

Go does not have built-in support for compile-time assertions like some other languages. However, you can achieve similar functionality using creative techniques. Below are some common approaches.

Assert a constant boolean expression is true (or false) at compile time:

We could make use of the fact introduced in the following:

Go specification clearly specifies that the constant keys in a map/slice/array composite literal must not be duplicate.

For example, the following code assures that the constant boolean expression aBoolConst must be true.
If it is not true, then the code fails to compile.

const aBoolConst = true
var _ = map[bool]int{false: 0, aBoolConst: 1}

Assert the length of a constant string is 15:

const STR = "abcdefghij12345"
var _ = map[bool]int{false: 0, len(STR) == 15: 1}

Assert a constant integer is 15:

var _ = [1]int{len(STR)-15: 0}
//OR
var _ = [1]int{}[len(STR)-15]

Assert a constant `X` is not smaller than another constant `Y` at compile time:

const _ uint = X-Y
//OR
type _ [X-Y]int

Assert a constant string is not blank:

var _ = aStringConst[0]
//OR
const _ = 1/len(aStringConst)

Using array size checks:

import "unsafe"

type MyStruct struct {
    A int64
    B int64
}

// Ensure the size of a struct is 16 bytes
var _ = [1]int{unsafe.Sizeof(MyStruct{}) - 16: 0}

Assert enum length:

type enumType int

const (
    EnumA enumType = iota
    EnumB
    EnumC
    end
)

var enumDescriptions = [...]string {
    EnumA: "first",
    EnumB: "second",
    EnumC: "third",
}

func (e enumType) String() string {
    if e < 0 || e >= end {
        panic("invalid value")
    }
    return enumDescriptions[e]
}

var _ = [1]int{}[len(enumDescriptions) - int(end)]

func _() {
    var x [1]struct{}
    _ = x[EnumA - 0]
    _ = x[EnumB - 1]
    _ = x[EnumC - 2]
}

Using `init` function with `panic`:

While not strictly a compile-time assertion, you can use the init function to perform checks that will fail at program startup (effectively acting as a runtime assertion during initialization):

const ExpectedSize = 8

var myInt int64

func init() {
    if unsafe.Sizeof(myInt) != ExpectedSize {
        panic("int size is not 8 bytes")
    }
}

Best start for JavaScript

Saleh Rahimzadeh — Fri, 18 Oct 2019 05:11:32 +0000

JavaScript (JS) is a lightweight interpreted or JIT-compiled programming language.

It was invented by Brendan Eich in 1995
It became an ECMA standard in 1997.
ECMA-262 is the official name of the standard.
ECMAScript is the official name of the language

If you want to learn JavaScript there are a lot of books and resources from novice to expert that can guide you.
I’ve been learning JavaScript since last year and I had opportunity to study some of them.
I’ve found expert resources are even better than novice resources to start, because there are some unfriendly features on JavaScript that novice resources don’t cover them and so can waste you time in first step and then confuse you finally.

To start JS:

http://speakingjs.com/es5/ To learn last update of JS:
https://leanpub.com/understandinges6/read/ To learn how to use JS in client-side web development:
O`Reilly — JavaScript. The Definitive Guide, 6th

To learn Object-Oriented concepts of JS deeply:

No Starch The Principles Of Object Oriented JavaScript To learn some internal aspects of JS:
http://dmitrysoshnikov.com/ecmascript/javascript-the-core-2nd-edition/

And finally, full-featured reference for JS:

In my opinion, don’t heavily rely on novice resource like w3school.com, use it only for a quick and rapid introduction on first step.

DEV Community: Saleh Rahimzadeh

typed and untyped variables (or constants) in Go (Golang)

1. Typed Variables

2. Untyped Variables (or Constants)

Key Differences

Example of Untyped Constants in Action

Default Types for Untyped Constants

reflexive and non-reflexive keys in Go (Golang)

Reflexive Key

Non-Reflexive Key

Key Requirements in Go Maps

PostgreSQL Performance Checklist

Difference between calling "panic" and calling "os.Exit(1)" in Go (Golang)

1. panic

2. os.Exit(1)

Key Differences:

When to Use Which:

Recovering from panic:

Data Processing Pipeline in Go (Golang)

Data Processing Pipeline in Go (Golang)

Key Concepts of a Data Processing Pipeline in Go

Simple Data Processing Pipeline

Explanation of the Code

Adding Concurrency with Fan-Out and Fan-In

Key Points in the Fan-Out/Fan-In Example

Best Practices for Data Processing Pipelines in Go

Mathematics for Software Developers

Arithmetic for College Students

Beginning and Intermediate Algebra

Discrete Mathematics An Open Introduction

Zero-Allocation in Go (Golang)

Go’s Garbage Collector and Zero-Allocation Programming

Why Minimize Allocations?

Challenges of Zero-Allocation Programming

Key Strategies for Zero Allocation Programming

1. Efficient string concatenation

2. Preallocating slices to prevent resizing

3. Using copy() Instead of append() for Slices

4. Pre-Allocating Buffers

5. Using Stack Instead of Heap (Avoiding Escape Analysis Issues)

6. Minimize Allocations in Hot Paths

7. Using Structs Instead of Maps for Fixed Keys

8. Using sync.Pool for Object Reuse

Compile-Time Assertions in Go (Golang)

Compile-Time Assertions in Go

Assert a constant boolean expression is true (or false) at compile time:

Assert the length of a constant string is 15:

Assert a constant integer is 15:

Assert a constant X is not smaller than another constant Y at compile time:

Assert a constant string is not blank:

Using array size checks:

Assert enum length:

Using init function with panic:

Best start for JavaScript

1. `panic`

2. `os.Exit(1)`

Recovering from `panic`:

3. Using `copy()` Instead of `append()` for Slices

8. Using `sync.Pool` for Object Reuse

Assert a constant `X` is not smaller than another constant `Y` at compile time:

Using `init` function with `panic`: