
In the database solution design, there is the bad practices is called circular references.

## What's circular in the database?

Imagining one type of circular reference in SQL is made when a first table references a second and that second table references the first table. Simple example of how this would look in a model: students and professors in which students has a reference to professor as advisor and professor has a reference to student as advising student.

![](assets/circular_student.png)

The principal problem on circular references is that when we start inserting data into the tables we won’t be able to since none of the references can accept nulls and we can’t insert one record without having another on the other table.
A more complex example of circular reference is simple task management system. There are 4 entities in the solution: users, tasks, projects, project_assignments, project_teams:

- A project has many tasks
- A project has many users via project_teams entity
- A project_assignments combine by 2 connection tasks and project_teams

![](assets/circular_project.png)

So, a project has 2 ways to get the project_assignments. The problem occurs when we query the data. If we start at projects, tasks and then project_assignments, there the link ends, since project_assignments does not serve as the primary key for any other table. Then we do the same process with the other link, start at projects, go to project_teams, end up in project_assignments.

An easy way to identify a circular reference is to start on a table which is serving as the primary table for two or more foreign keys. Some database designs look like a circular references, but not true. An example is the purchasing system. There are some entities: products, purchases, commissions, customers, retailers. The products has many customers by 2 connections: purchases or commissions.

![](assets/circular_purchasing.png)

The concept of a circular reference can sometimes be confused with a diagram model that forms a circle, but as we saw in the example before, the model forms a circle, but there is no circular reference.

## Types of circular

There are 3 types of circular references: self-reference, a circle, multi-table circular-references.

- Self-references: using to describe the parent-child relationship. If parent is null marks as a root.
- Circle: as a endless loop. Start from A, then B, or C, and end up in A
- Multi-table circular-references: Several chains of Primary Key - Foreign Key relations between those 2 tables

## Challenges of circular references

While circular references can be necessary, they come with significant challenges, including:

- Data Integrity Issues: circular references can lead to integrity problems, especially if updates, inserts, or deletes are not properly managed.
- Complex Querying: queries can become complex and inefficient, as the database needs to traverse multiple tables back and forth to resolve the relationships.
- Infinite Loops: recursive queries, tree traversal, or certain types of cascades (like deletions) can enter into infinite loops when circular references are present.
- Difficult Maintenance: as systems grow more complex, managing circular references can become harder to maintain, debug, and update.

## Circular in the real world

Circular references in database design are generally avoided due to complexity but can be useful in certain scenarios to model real-world relationships:

- Bidirectional Relationships: Entities may depend on each other and need mutual references. In a company, an employee may have a manager, and the manager is also an employee. Both must reference each other to capture the relationship.
- Self-Referencing Hierarchies: Useful for navigating both up and down a hierarchy. A family tree may need both parent-child and child-parent relationships for easy ancestor/descendant retrieval.
- Cross-Referencing Entities: Ensures contextual integrity and bidirectional flow of business logic. A customer and supplier both reference a contract, allowing updates to be reflected on both sides.
- Graph-Like Data Structures: In structures like social networks, circular references may be required to accurately reflect mutual connections. Friendships between users in a social network, where each user references the other.

## Solution and migrate from the existing database design

Solution for the database practice:

- Keep number of circular references as low as possible
- Circular reference be detected and prevented as early as the implementation phase
- Be sure that there is no more than one route for data to traffic from one entity to another
  When circular references are necessary, consider these strategies to reduce their impact.
- Deferred Constraint Checking: In databases that support it (e.g., PostgreSQL), you can use deferred constraint checking, where foreign key constraints are validated at the end of a transaction, not at the time of each insert or update. This allows for temporary invalid states that resolve by the end of the transaction.
- Soft Circular References: Use application logic or soft references (e.g., storing IDs without strict foreign keys) to model relationships that look circular but avoid strict database-level circular dependencies.
- Intermediate Tables: Where possible, break direct circular dependencies by introducing intermediate tables or junction tables to mediate relationships between entities.
- Application-Level Logic: Implement logic in your application layer to manage circular relationships and ensure data consistency without relying solely on database constraints.
- Normalization and Denormalization: Use normalization to ensure the schema is designed efficiently. In some cases, denormalization may be appropriate to simplify complex circular relationships and improve performance.

## Conclusion

Circular references can be useful or even necessary in certain scenarios where relationships are bidirectional or complex, such as social networks, graph-like data structures, or cross-referencing entities. However, they should be used with caution due to the potential performance, integrity, and maintenance challenges they introduce. Where possible, other approaches (like intermediate tables or soft references) should be considered to avoid the pitfalls associated with circular references.

## References

- https://medium.com/akurey/dont-be-circular-b59c5609d472
- https://www.codeproject.com/Articles/38655/Prevent-Circular-References-in-Database-Design
- https://github.com/Wuodan/SQL-Find-Circular-References


A comprehensive guide to understanding circular references in database design, including types, challenges, real-world applications, and solutions for managing them effectively. Covers self-references, circular dependencies, and strategies for maintaining data integrity while working with circular relationships.

Database design circular


Finite State Machines (FSMs) are a crucial concept in computer science and software development, providing a robust method for modeling the behavior of systems. Erlang, a language designed for concurrency, fault tolerance, and distributed computing, offers unique advantages when implementing FSMs. In this note, we'll explore how Erlang excels in handling FSMs, using the Catch Chicken Machine as a practical example.

## Why Erlang?

1. **Concurrency**: Erlang's lightweight processes and efficient message-passing make it ideal for concurrent systems.
2. **Fault tolerance**: Built-in mechanisms for error detection and recovery enhance system reliability.
3. **Distributed computing**: Native support for distributed systems allows easy scaling and resilience.

## The catch chicken machine: a practical example

The Catch Chicken Machine is a simple yet illustrative example of a finite state machine implemented in Erlang. It models a system where a chicken-catching robot moves between states based on external inputs and internal logic.

## States and transitions

- **Idle**: The initial state, waiting for a command to start.
- **Searching**: Actively looking for a chicken.
- **Catching**: Attempting to catch a detected chicken.
- **Resting**: Taking a break after a catch or a failed attempt.

## Implementation practices

1. **Define states and events**: Clearly define each state and the events that trigger transitions.

   ```erlang
   -define(STATES, [idle, searching, catching, resting]).
   -define(EVENTS, [start, chicken_spotted, chicken_caught, chicken_escaped, rest]).
   ```

2. **State transition logic**: Use Erlang's pattern matching to implement transition logic.

   ```erlang
   handle_event(start, idle) ->
       {next_state, searching};
   handle_event(chicken_spotted, searching) ->
       {next_state, catching};
   handle_event(chicken_caught, catching) ->
       {next_state, resting};
   handle_event(chicken_escaped, catching) ->
       {next_state, searching};
   handle_event(rest, resting) ->
       {next_state, idle}.
   ```

3. **Concurrency and messaging**: Leverage Erlang's messaging capabilities to handle state transitions.

   ```erlang
   loop(State) ->
       receive
           Event ->
               {next_state, NewState} = handle_event(Event, State),
               loop(NewState)
       end.
   ```

4. **Fault tolerance**: Implement error handling to ensure the FSM can recover from unexpected states or failures.
   ```erlang
   handle_event(_, _) ->
       {next_state, idle}.
   ```

## Benefits of using Erlang for FSMs

- **Scalability**: Erlang's ability to handle numerous concurrent processes allows the FSM to scale efficiently.
- **Reliability**: The language's emphasis on fault tolerance ensures that the FSM can recover gracefully from errors.
- **Clarity**: Pattern matching and clear state definitions make the FSM logic easy to understand and maintain.

## Conclusion

Erlang's unique features make it an excellent choice for implementing finite state machines. By following best practices and leveraging the language's strengths, developers can create robust, scalable, and reliable FSMs. The Catch Chicken Machine example demonstrates how Erlang's concurrency, fault tolerance, and clear syntax contribute to effective FSM implementation. Embrace Erlang for your FSM needs and experience the benefits firsthand.


Erlang finite state machine


Go is a type-safe, cloud-native language designed for simplicity with first-class support for concurrency.

The software community has been hungering for a small, simple, easy-to-learn and pragmatic programming language. Go fits the bill with:

## Simplicity

Go's beauty lies in its powerful simplicity. A list of NO's in Go design contains generics, ternary operation, pointer arithmetic,…. These features are missing because it doesn't fit, and it affects compilation speed, and end up making the language too complicated.

It's not what it included that makes it great; it's what is left out. Even at the expense of writing more code, simplicity acts as a key feature.

### First-class support for concurrency

Go is not the first language that comes up with concurrency. We had Erlang for that a while ago. But Go is one of the few mainstream languages get it right.

Relying on CSP & "sharing by communicating" model plus the light-weight go-routine implementation makes concurrent programming perform at the best experience. If concurrency plays a vital part in your application, Go should be the first thing in your mind.

### Interface-driven OOP

This guy enables duck typing and dependency injection, two forms that extremely fruitful while avoiding the complexities of inheritance, which proves a notable downside in practice.

## Why Go

Let's be frank, Go is not a language for everything.

- It can't compare with Elixir in term of development speed.
- Rust beats it hard when it comes to performance.
- Simplicity alone? Try Python

Go has its place and shines the brightest with the following application types:

- Cloud application: Go's native feature set made it a naturally fit for the cloud, with concurrency built-in feature, Go is the best choice in the market for the two most common architecture in the cloud: micro-services and distributed system.
- Utilities and stand-alone tools: Go was born to beat the compilation time. It's a savior that the program can be compiled in shorter time and minimal size compare to most of other languages, allow it to be packed and distributed quickly.

## Go in software engineering

> Software engineering is what happens to programming when you add time and other programmers.-Russ Cox

Programming is hard. You have a problem, you write a program to solve it. Your program turns out great and works thing out - that's programming. But keeping your program work over time is struggling in many levels. More people coming, your business logic changes or some of your 3rd party library is no more working.

Software Engineering is about keeping your program resilient over time. And Go was born to live by that code, with a firm promise that the program we wrote in day 1 will compile and run perfectly in the future. All of the language technical design and toolset that were made by the concern of Software Engineering aims to simpler the program, make it easier to maintain, coordinate and evolve.


An overview of Go's key features, including simplicity, concurrency support, and interface-driven OOP. Explores Go's strengths in cloud applications and utility development, and its role in software engineering practices for maintaining resilient programs over time.

Go in software engineering


## Golang concurrency

When we talk about Golang, its most basic and popular characteristic is concurrency-support. Unlike other languages what is quite complex to build an concurrency system, Go concurrency primitives via Goroutines and channels make concurrent programming easy. So i am going to talk about Goroutines and similar things in other programming languages.

Firstly, we need to know Go is a concurrent language and not a parallel one. So what is the difference from concurrency and parallelism?

### Concurrency vs parallelism

Concurrency means “out of order” execution. Another concept talk about concurrency as the capability to deal with lots of things at once. It's best explained with an example in real life: During playing Dota 2, let’s say, my mom asked me to buy something. Now i stop playing, go to the grocery and then starts playing again with rebuke of my team. This is a basic example of concurrency. In computing, concurrency is represented by the state when two or more tasks can start, run, and complete in overlapping time periods. It doesn't necessarily mean they'll ever both be running at the same time. Multitasking on a single-core machine is an example.

Parallelism is doing lots of things at the same time like other running tasks on a multicore processor. Let’s come back with the example above. Instead of taking order my mother, I play the game and listen to music at once freely. In this case, playing game and listening to music is "lots of things".

![](assets/go-concurrency_9cb01cacb1edc3373acd7570cc280cd7_md5.webp)

After understanding the way to compare concurrency with parallelism, we can research about Goroutines/channel and other well.

### Goroutines

Goroutines can be understood like a light weight thread. Instead of OS, Goroutines exists only in the virtual space of Go runtime. A Goroutines is started up with initial 2KB of stack size (This is the location where store answer of the question "what is this Go routine's current state?". It is contains local variables as well as pointers to heap allocated variables). Because Go’s stacks are dynamically sized, growing and shrinking with the amount of data stored. So we need only 4KB memory for Goroutines.

![](assets/go-concurrency_d82335b0ffffc63ae92aa7339a5867e8_md5.webp)

Goroutines are cheaper than others thing like it (thread) in other programming language because of ability growing and shrinking depend on programmer's desire. e.g a Java thread initially have 4MB while go-routine is somewhere around 2KB.

While some languages take an "concurrency at OS level" approach. Go implemented its own scheduler in order to keep concurrency concept at language level.

### Channel

Channel is a communication tool for Goroutines. Channel can be understand like pipes. So similar to water flows from one end to another in pipes, a Goroutines write data in one end and we can get it in another by using Channel.

Each channel has a type associated. This type decide data type that channel is allowed to transport and no other types can access into it.

When a data is sent to a channel, the control is blocked in the send statement until some other Go-routine reads from that channel. Similarly when data is read from a channel, the read is blocked until some Go-routine writes data to that channel. It also mean these are **unbuffered**.

In other words, by default Go channel are **unbuffered**.

So how to break this limit?

Like the way God made Eve from a part of Adam, Go provide another channel type that can buffered.

For buffered channel, providing the buffer length as the second argument to make to initialize a buffered channel:

```plain_text
 messages := make(chan string, capacity)
```

Capacity should be greater than 0 for a channel to have a buffer and we can send data to our channel until this is full, similar receives will not block when we read data until empty.

![](assets/go-concurrency_eb379f648c223af56819605adfeb118d_md5.webp)

## Under the hood

### Channel implementation

When we implement a Go channel, a struct will be created, then it looks like following.

To have a comprehensive view, we have a few descriptions about the fields encountered in the channel structure.

![](assets/go-concurrency_23c2cb6d27ce23dcdc500decd9a59398_md5.webp)

- **buf** is the location where our data is actually stored. It is a circular queue.
- **dataqsize** is size of the circular queue. It represent capability of channel. When we declare make(chan int, N), **dataqsize** is N. It also let us know how many Goroutines can write data into this channel until blocked

![](assets/go-concurrency_966768c61d35099632b9e31f581807c6_md5.webp)

- **qcount** represents the number of slots in the buf currently filled up.
- **elemsize** Is the size of a channel corresponding to a single element.
- **elemtype** used when messages are copied over from one Go-routine to the other. It has a bunch of fields which provide type and size information for the type of values the channel can hold.
- **closed** Indicates whether the current channel is in the closed state. After a channel is created, this field is set to 0, that is, the channel is open; by calling close to set it to 1, the channel is closed.

![](assets/go-concurrency_80543471c1dd9c44e63c7fa281d4b6c0_md5.webp)

- **sendx** and **recvx** indicates the current index of buffer — backing array from where it can send data and receive data.
- **recvq** and **sendq** waiting queues, which are used to store the blocked Goroutines while trying to read data on the channel or while trying to send data from the channel.
- **lock** protects all fields in **hchan**, as well as fields in sudogs blocked on this channel.
- **sudog** struct is described in Golang source as a Go Routine in a wait list, such as for sending/receiving on a channel.
-

We mentioned about sudog struct above. What is sudog? See the following image:

![](assets/go-concurrency_2ec27e55f9c531e5aab4f885f5915f30_md5.webp)

We have a full description for sudog struct in source. If something confuse, ignore it by looking at the original concept. Then we have a good description about sudog: sudog represents a Goroutine. recvq and sendq hold the information on the Goroutines which are currently blocking on the channel while receiving and sending respectively. They are pointers to sudog.

An example to know what happen when we declare Goroutines and channel.

![](assets/go-concurrency_026784030ef13c5d006328ea47cfc657_md5.webp)

What will be the structure of the channel before line **No 22?**

![](assets/go-concurrency_28bee5f5381e186532a5ceda7746c017_md5.webp)

In Our Example Code before line 22 there are two Goroutines (goroutineA and goroutineB ) trying to read data from the channel ch.

Since before line 22 on a channel, there is no data we have put on the channel so both the Goroutines blocked for receive operation have been wrapped inside the **sudog** struct and is present on the recvq of the channel. **recvq** and **sendq** are basically linked list, which looks basically as below

![](assets/go-concurrency_2da8e4e08c9af6c09a70149ce0bee0c1_md5.webp)

### Go scheduler

To understand Go scheduler quickly, we will review a few concepts in OS and OS scheduler that support a program is runnable. If you knew about OS thread and OS scheduler, you should skip following section and jump to next part.

Computer Program is just a series of machine instructions that need to be executed one after other sequentially. So thread was born in other to account and sequentially execute the set of instructions it was assigned.

When we run a program, a process is initiated with a thread. A thread have the ability to create more threads. A thread can run parallel or concurrently and keep their own state is safe, local and independent execution of their instructions.

The OS scheduler is an operating system module that is responsible for making sure cores are not idle if there are threads that can be executing. It must also create the illusion that all the threads that can execute are executing at the same time.

If you are running on Linux, Mac or Windows, you are running on an OS that has a preemptive scheduler. This means a few important things. First, it means the scheduler is unpredictable when it comes to what Threads will be chosen to run at any given time. Thread priorities together with events, (like receiving data on the network) make it impossible to determine what the scheduler will choose to do and when.

Existing a piece called Program Counter in a Thread that allows the thread keep track of the next instruction to execute.

![](assets/go-concurrency_bf66c5b925d9c162acc9d0fb055c353e_md5.webp)

There are 3 states in thread

- **Waiting**: This means the Thread is stopped and waiting for something in order to continue. “Something” is waiting for the hardware (disk, network), system calls, synchronization calls (atomic, mutexes).
- **Runnable**: This means the Thread wants time on a core so it can execute its assigned machine instructions.
- **Executing**: This means the Thread has been placed on a core and is executing its machine instructions.

And 2 types of works

- **CPU-Bound**: This is work that never creates a situation where the Thread may be placed in Waiting states.
- **IO-Bound**: This is work that causes Threads to enter into Waiting states. This is work that consists in requesting access to a resource over the network or making system calls into the operating system. **Context switches** is the duration that we swap a thread on and of a core. It take between ~1000 and ~1500 nanoseconds to do its work while the hardware should be able to reasonably execute averagely 12 instructions per nanosecond per core. So a context switch can cost we ~12k to ~18k instructions of latency. In essence, a context switch make lower performance by losing ability to execute a lot of machine instructions. It look like suitable with IO-Bound work but not with CPU-Bound work that requires work constantly.

After surfing over above all things, we have ability to understand following part quickly. It is the section that describe about GO scheduler and how it make Goroutines faster than threads.

### Getting started

When our program start up, it’s given a Logical Processor (P) for every virtual core identified on the host machine. So how many virtual core exist in your computer? Suppose that we have a Macbook with following system report:

![](assets/go-concurrency_8c56d98dd1917a5c479f487977ccfb9f_md5.webp)

We have 1 processor with total 4 cores. As you see the report don’t let us know directly how many virtual core here. But the Intel Core i7 processor has Hyper-Threading, which means there are 2 hardware threads per physical core. This will report to the Go program that 8 virtual cores are available for executing OS Threads in parallel. In another word, a hardware thread serve for a virtual cores.

Every P is assigned an OS Thread (M) that stands for machine. This means when I run a Go program on my machine, I have 8 available threads to execute my work, each individually attached to a P.

Every Go program is also given an initial Go-routine (G). Just as OS Threads are context-switched on and off a core, Goroutines are context-switched on and off an M.

Each P is given a Local Run Queue LRQ that manages the Goroutines assigned to be executed within the context of a P. These Goroutines take turns being context-switched on and off the M assigned to that P. The Global Run Queue(GRQ) is for Goroutines that have not been assigned to a P yet. There is a process to move Goroutines from the GRQ to a LRQ that we will discuss later.

Following figure provides an image of all these components together

![](assets/go-concurrency_ad2ef462e022466f3eab445763ef2bda_md5.webp)

The Go scheduler is part of the Go runtime, which is built into our application. This means the Go scheduler runs in user space. The current implementation of the Go schedule is a cooperating scheduler that needs well-defined user space events.

We can’t predict what the Go scheduler is going to do. This is because decision making for this cooperating scheduler doesn’t rest in the hands of developers, but in the Go runtime. It’s important to think of the Go scheduler as a preemptive scheduler and since the scheduler is non-deterministic, this is not much of a stretch.

There are four classes of events that occur in your Go programs that allow the scheduler to make scheduling decisions. This doesn’t mean it will always happen on one of these events. It means the scheduler gets the opportunity.

- The use of the keyword go
- Garbage collection
- System calls


A comprehensive guide to concurrency in Go, covering goroutines, channels, and the Go scheduler. This article explains the differences between concurrency and parallelism, dives into the implementation details of channels, and explores the inner workings of the Go scheduler. It provides insights into how Go's concurrency model compares to other languages and offers a deep understanding of Go's efficient approach to managing concurrent tasks.

Go concurrency


### Array

**TL;DR:** The differences between array in Go and C:

- Arrays are values. Assigning one array to another copies all the elements.
- In particular, if you pass an array to a function, it will receive a copy of the array, not a pointer to it.
- The size of an array is part of its type. The types [4]int and [5]int are distinct.

In Go language, the terminology `Array` has a bit different from another language like C, JS, ... In Go, the `array has a fixed length and type `Take a look of array implementation in Go.

![](assets/slice-and-array-in-golang_a650b13e6028a391f8acdc858b08c372_md5.webp)

Its length is part of its type ([4]int and [5]int are distinct, incompatible types). For example, you can compare two arrays have the same type [4]int.

```go
a := [4]int{1,1,1,1}
b := [4]int{0,0,0,0}
c := [4]int{}

fmt.Println(a == b) // false
fmt.Println(b == c) // true
fmt.Println(c == a) // false
```

As you can see, the array does not need to be initialized explicitly, the `array c` in the example above is initial with zero value of an array type (zero value of an integer is 0).

But two array [4]int and [5]int is incompatible with each other

```go
a := [4]int{}
b := [5]int{}

fmt.Println(a == b) // mismatched types [4]int and [5]int
```

You also can let Go's compiler count the array size for you at compile time.

```go
a := [...]int{1,1,1}
b := [3]int{1,1,1}

// in this example, both a and b have a [3]int type and can compare with
// each other

fmt.Println(a == b) // true
```

For representation for an array of [4]int in memory is for integer value laid out `sequentially`

![](assets/slice-and-array-in-golang_8327bf995dd32badeef1e1d0eb4eeda5_md5.webp)

So, in Go, the array is values. An array variable holds the entire array (not a pointer to the first element). Let's say the array is a struct ( but using index instead of named field). Because an array is not a pointer to the first element, so when we assign, pass an array to a function, it will make a copy of its content

### Slice

In Go code, we don't often see array because of its inflexible, slice - on the other hand - is everywhere. Slice is an abstraction built on top the array. Unlike the Array, Slice type has no specified length; you can declare a slice like an array but `without the count element`.

```go
a := []int{1,2,3,4}
```

A slice has three components (will be talking more detail in next section):

- `pointer` : point to underlying array
- `length ` : the number of elements referred to by the slice
- `capacity` : the number of elements in the underlying array

Because slices hold references to an underlying array, so if you assign one slice to another, both refer to the same array.

```go
a := []int{1,2,3,4}
b := a
b[0] = 10

fmt.Println(a) // [10 2 3 4]
```

We can make a slice by using built-in `make` function. When called, `make` allocates an array and returns a slice that refers to that array. Note that the zero value of a slice is `nil.`

```go
// make(type, length[, capacity])
a := make([]int,4,8)

// if we omit capacity, it defaults to the specified length
b := make([]int,4)

// len b = 4
// capacity b = 4
```

or `slicing` an array or another slice using these format

```go
a := []int{1,2,3,4,5,6,7,8,9,10}

b := a[0:5]
fmt.Println(b) // [1 2 3 4 5]

c := a[5:]
fmt.Println(c) // [6 7 8 9 10]

d := a[:5]
fmt.Println(d) // [1 2 3 4 5]

e := a[:]
fmt.Println(e) // [1 2 3 4 5 6 7 8 9 10]
```

The length and capacity of a slice can be inspected using the built-in `len` and `cap` functions.

```go
a := make([]int,4, 8)

fmt.Println(len(a)) // 4
fmt.Println(cap(a)) // 8
```

### Slice internal

Let's take a look at `slice` implementation in Go.

```go
type slice struct{
	array unsafe.Pointer
	len int
	cap int
}
```

For example, if we create a slice by using make([]byte,5), the slice will be structured like this:

![](assets/slice-and-array-in-golang_f18621d9bf057f8c2ea818ca438379c3_md5.webp)

A slice cannot be grown beyond its capacity. Attempting to do so will cause a runtime panic, just as when indexing outside the bounds of a slice or array. Similarly, slices cannot be re-sliced below zero to access earlier elements in the array.

**So the question is, What if we `*append*` an element to a slice which has reached its capacity?**

### Append

Let's dig into a source code (go/src/reflect/value)

![](assets/slice-and-array-in-golang_1f1383e462f5fa432205e471759c4051_md5.webp)

so the `append` built in function do a few things here:

First, it will check an input value, if it's not a `Slice` the program will throw a panic, then the interesting things here is `grow` function , it will take an old slice and length of the new slice we want to append. Let take a look at `grow` function:

![](assets/slice-and-array-in-golang_de7599e21a9ed4cf0e4a9d31169129e2_md5.webp)

So now we understand the mechanism behind the `append` function, it will allocate a `new Slice` which have more capacity than the old one

The interesting thing is how Go decide how much capacity the new slice is. As you can see if the old slice capacity is lesser than 1024, it will double the old slice's capacity, but when it grows bigger than 1024 Go adds `old slice's capacity / 4` to the old capacity

### Appendix

- [https://golang.org/doc/effective_go.html#slices](https://golang.org/doc/effective_go.html#slices)
- [https://blog.golang.org/slices](https://blog.golang.org/slices)


An in-depth exploration of arrays and slices in Go, covering their differences, internal implementations, and key operations like append. Learn about fixed-length arrays, flexible slices, and how Go manages memory allocation for growing slices.