zalopay-oss/go-advanced

A small Vietnamese Go book compiled by ZaloPay teams.

go-advanced's Issues

Sai link "Phần tiếp theo" đến chap 5

Đã fix ở #7

Bổ sung nội dung về lập trình an toàn

Tôi nghĩ là nên bổ sung thêm phần lập trình an toàn với GO.

Cần làm rõ Atomic và Mutex

Trong mục 1.6.2. Tác vụ Atomic nên làm rõ 2 khái niệm Atomic và Mutex.

1. Atomic bắt nguồn từ thời CPU đơn nhân và giả lập đa luồng bằng phần mềm ở tầng hệ điều hành bằng cách chuyển qua lại giữa các tiến trình. Từ đó phát sinh ra vấn đề khi một lệnh được thực hiện bởi nhiều hơn 1 chu kỳ CPU nó có thể dẫn đến dị bội dữ liệu VD: lệnh tăng giá trị của biến a++ có thể tách thành 3 lệnh: đọc giá trị của a từ bộ nhớ vào thành ghi, tăng giá trị thanh ghi, lưu giá trị từ thành ghi xuống bộ nhớ. Khi giả lập đa luồng bằng phần mềm 3 lệnh trên có thể được thực hiện sen kẽ bởi các bởi các luồng khác nhau.

a => đọc và thanh ghi // luồng tiến trình 1.
// Chuyển qua tiến trình 2
a => đọc vào thành ghi // luồng tiến trình 2.
tăng giá trị thành ghi // luồng tiến trình 2.
// Chuyển qua tiến trình 1
tăng giá trị thanh ghi // luồng tiến trình 1.
ghi thanh ghi xuống => a // luồng tiến trình 1.
// Chuyển qua tiến trình 2
ghi thanh ghi xuông => a // luồng tiến trình 2.

Theo thiết kế giá trị của a phải được tăng thêm 2 nhưng do việc chuyển qua lại giữa các luồng nên giá trị chỉ được tăng thêm 1. Để tránh việc này hệ điều hành cung cấp API cho phép thực hiện lệnh tăng giá trị một biến trong 1 chu kỳ duy nhất để tránh dị bội dữ liệu.

2. Mutex - lock là cơ chế dựa trên giải thuật Semaphore nhằm ánh xạ trạng thái sử dụng của tải nguyên dựa trên lệnh test-and-set được các thư viện atomic của hệ điều hành cung cấp.

Điểm khác biệt cơ bản là với Atomic các luồng không bị khóa mà vẫn chạy liên tục, với mutex - lock các luồng xếp hàng chờ lấy khóa và được chuyển trạng thái ( context-switching)

Bổ sung nội dung mới cho sách

Mô tả

Sau khi hoàn tất phần release hoàn chỉnh, với mục đích có thêm nhiều kiến thức mới, chúng ta cần bổ sung thêm các nội dung hay, có tính ứng dụng cao trong thực tế. Đây sẽ là issue tập hợp những nội dung cần thêm cho bộ tài liệu này.

Yêu cầu

Làm theo các Step:

1. Đọc và tìm hiểu các nội dung ở phần Nội dung mới bên dưới.
2. Đánh giá nội dung.
3. Thảo luận và bình chọn xem có nên đưa vào sách không.
4. Thực hiện:
   • Nội dung cần đảm bảo các tiêu chí:
     • Kiến thức mới.
     • Có tính ứng dụng.
   • Khi trình bày đảm bảo các phần:
     1. Giới thiệu (nêu động lực tại sao cần làm)
     2. Trình bày chi tiết các vấn đề (chia nhỏ để nói).
     3. Code Example.
     4. Kết luận và đánh giá.
   • Đảm bảo đúng format như làm ở các chapter.

Nội dung mới

• Bổ sung chapter 6.
• Web socket: websocket
• Benchmark trong Golang: (https://github.com/myzhan/boomer), go-functions-with-benchmarks
• Test: go-test-your-code
• Giới thiệu các framwork thường dùng trong golang: go-kit
• Cheat sheet trong golang: go-lang-cheat-sheet
• Giới thiệu về QUIC: QUIC
• Giới thiệu các best pratices: Twelve Go Best Practices - Golang talks,project-layout, ...

Thành viên tham gia

• Tất cả các bạn có cùng đam mê Golang.

Re-organize "Array, strings và slices" section

Describe the bug

The "Array, strings và slices" section has some wrong concepts/definitions, and also somewhat not clearly, since when it introduces strings before slices. The official Go blog has an introduction post about "Arrays, slices (and strings)".

To Reproduce

At revision e19da2e:

1. Wrong definition of uintptr

type StringHeader struct {
    // con trỏ địa chỉ vùng nhớ string
    Data uintptr
    // chiều dài của string
    Len  int
}

This is wrong, Data is an uintptr (Numeric types), not a pointer type, even though its value is the pointer address in memory. This is important concept, otherwise, it can lead to wrong assumption and cause memory corruption. The official Go documentation has a warning for this.

The same problem applies to the slices section:

Data: là con trỏ chứa địa chỉ của một array.

2. Wrong description about len builtin

Tương tự như array, String cũng có một hàm built-in là len dùng để trả về chiều dài của string

len is not a function of String, it's a builtin function, which can take various types of argument, including string type.

3. Wrong word about ranging over slice

Duyệt qua slice thì tương tự như duyệt qua một arrays.

This is not true. Ranging over an array requires copying the array elements, while ranging over slice is not (the same as ranging over pointer to array).

4. The description of slice growing capacity is not quite right

Trong trường hợp slice ban đầu không đủ sức chứa khi thêm vào phần tử, hàm append sẽ hiện thực cấp phát lại vùng nhớ có kích thước gấp đôi vùng nhớ cũ và sao chép dữ liệu sang.

This is only right for slice with < 1024 element, for slice with >= 1024 element, the grow factor is only 1.25 (and the factor can be smoother in go1.18, see https://go-review.googlesource.com/c/go/+/347917)

Expected behavior

Re-organizing the section to follow official Go blog, and also correct all the wrong definition.

Phiên bản Java21 cho phép hàm main không thuộc lớp nào.

Cập nhật nội dung cho mục 1.4.2 "Kế đến là Java, ngôn ngữ
được gọi là hướng đối tượng thuần túy vì các hàm của nó không thể tồn tại độc lập mà phải thuộc về một class nhất
định." phiên bản java21 đã cho phép hàm main không cần thiết thuộc lớp nào.
https://openjdk.org/jeps/445

Examples in ch1-05 are wrong

Describe the bug

Examples in https://zalopay-oss.github.io/go-advanced/ch1-basic/ch1-05-concurrency-parallelism.html#154-v%C3%AD-d%E1%BB%A5-goroutine uses time.Sleep for synchronization. This is wrong, because when a goroutine is scheduled to run depends on the runtime scheduler, there's no guarantee that it was run after time.Sleep was executed.

func main() {
    // sử dụng từ khoá go để tạo goroutine
    go fmt.Println("Hello from another goroutine")
    fmt.Println("Hello from main goroutine")

    // chờ 1 giây để có thể chạy được goroutine              <--- wrong
    //của hàm fmt.Println trước khi hàm main kết thúc
    time.Sleep(time.Second)
}

To Reproduce

Expected behavior

Use other primitive for goroutine synchronization like channel or sync.WaitGroup.

Screenshots

Desktop (please complete the following information):

Smartphone (please complete the following information):

Additional context