Phát hành Go 1.24

 (go.dev)
1 điểm bởi GN⁺ 2025-02-15 | 1 bình luận | Chia sẻ qua WhatsApp
  • Go 1.24 là bản cập nhật chính thức sau Go 1.23, bao gồm nhiều thay đổi mà lập trình viên có thể cảm nhận ngay, từ tính năng ngôn ngữ đến runtime, thư viện chuẩn và WebAssembly
  • Ở cấp độ ngôn ngữ, phiên bản này hỗ trợ đầy đủ generic type aliases, cho phép type alias cũng có thể được tham số hóa như defined type
  • Runtime có map mới dựa trên Swiss Tables, cải thiện cấp phát cho đối tượng nhỏ và thay đổi mutex nội bộ, giúp giảm trung bình 2–3% CPU overhead trong các benchmark tiêu biểu
  • Lệnh go bổ sung luồng theo dõi và thực thi tool dependencies của module, còn go vet phát hiện tốt hơn các lỗi khai báo liên quan đến test
  • Hỗ trợ thư viện chuẩn và nền tảng cũng được mở rộng, cần chú ý đến FIPS 140-3, testing.B.Loop, os.Root, runtime.AddCleanup, go:wasmexport, cũng như build WASI reactor/library

Phạm vi thay đổi của Go 1.24

  • Go 1.24 là bản phát hành chứa nhiều cải tiến so với Go 1.23; có thể xem danh sách thay đổi đầy đủ tại Go 1.24 release notes
  • Có thể tải phiên bản mới từ trang tải xuống của Go

Thay đổi ngôn ngữ: generic type aliases

  • Go 1.24 hỗ trợ đầy đủ generic type aliases
  • Type alias cũng có thể được tham số hóa như defined type, mở rộng phạm vi biểu đạt trong mã generic
  • Cú pháp chi tiết có trong language spec

Cải thiện hiệu năng runtime

  • Các cải tiến trong runtime giúp giảm trung bình 2–3% CPU overhead trên nhóm benchmark tiêu biểu
  • Có ba trục thay đổi hiệu năng chính
    • Triển khai map tích hợp mới dựa trên Swiss Tables
    • Cấp phát bộ nhớ hiệu quả hơn cho các đối tượng nhỏ
    • Triển khai mutex nội bộ mới của runtime

Cải thiện công cụ Go

  • Lệnh go cung cấp cơ chế theo dõi tool dependencies của module
    • go get -tool thêm chỉ thị tool vào module hiện tại
    • go tool [tool name] chạy công cụ được khai báo trong chỉ thị tool
    • Xem thêm trong mục go command của release notes
  • Lệnh con go vet có thêm bộ phân tích test mới
    • Báo các lỗi phổ biến trong khai báo test, fuzzer, benchmark và example của gói kiểm thử
    • Xem thêm trong mục vet của release notes

Bổ sung thư viện chuẩn và API runtime

  • Thư viện chuẩn bao gồm một nhóm cơ chế mới hỗ trợ tuân thủ FIPS 140-3
    • Không cần thay đổi mã nguồn ứng dụng để dùng cơ chế mới cho các thuật toán được phê duyệt
    • Xem thêm trong mục FIPS 140-3 compliance của release notes
  • Ngoài FIPS 140, một số package trước đây nằm trong module x/crypto nay cũng có sẵn trong thư viện chuẩn
  • Mã benchmark có thể dùng phương thức testing.B.Loop
    • Thực hiện lặp benchmark theo dạng for b.Loop() { ... }
    • Có thể thay thế cấu trúc lặp phổ biến dùng b.N như for range b.N
    • Cách này nhanh hơn và ít khả năng gây lỗi hơn
  • Kiểu mới os.Root cho phép thực hiện thao tác hệ thống tệp bị cô lập trong một thư mục cụ thể
  • Runtime bổ sung cơ chế dọn dẹp mới runtime.AddCleanup
    • Linh hoạt hơn, hiệu quả hơn và ít khả năng gây lỗi hơn so với runtime.SetFinalizer

Cải thiện hỗ trợ WebAssembly

  • Go 1.24 bổ sung chỉ thị go:wasmexport mới để chương trình Go có thể export hàm cho WebAssembly host
  • Có thể build chương trình Go thành WASI reactor/library
  • Xem thêm trong mục WebAssembly của release notes

Hướng dẫn tiếp theo và phản hồi

  • Toàn bộ thông tin chi tiết có trong Go 1.24 release notes
  • Một số chủ đề sẽ được đào sâu thêm trong các bài blog tiếp theo
  • Nếu phát hiện vấn đề, có thể gửi issue

Bài viết liên quan

1 bình luận

 
GN⁺ 2025-02-15
Ý kiến trên Hacker News

  • Đặc biệt vui vì triển khai map nhanh hơn, và cũng tốt khi text/template giờ đã hỗ trợ range-over-func
    Go 1.23 đã đưa range cho kiểu hàm vào, nhưng trong template của Go thì đến giờ vẫn chưa hoạt động

  • Tôi thích vì nó ổn định đến mức nhàm chán

  • Tò mò không biết os.Root sẽ được dùng vào việc gì
    Theo tôi hiểu thì nó liên quan đến bảo mật như https://github.com/golang/go/issues/67002, nhưng vì bên trong không dùng Chroot, cuối cùng có lẽ ai đó vẫn có thể tìm ra cách thoát ra ngoài Root

    • chroot chỉ có ý nghĩa khi có thể khẳng định rằng ứng dụng từ nay về sau sẽ chỉ hoạt động trong một thư mục duy nhất
      Hơn nữa, tiến trình cần quyền superuser, nên không thể dùng cho các ứng dụng chạy với quyền người dùng thông thường
      os.Root() giống như việc thắt dây an toàn cho các thao tác hệ thống tệp hơn. Ví dụ, giới hạn các thao tác liên quan đến cache của ứng dụng trong thư mục cache, hoặc để file server chỉ phục vụ các tệp trong thư mục chia sẻ phù hợp. Nó không bảo đảm kín kẽ như chroot, nhưng chặn được các cuộc tấn công duyệt thư mục đơn giản
    • Không hiểu vì sao phải dùng chroot
      Nếu đi cùng tính năng sandbox như Capsicum, có thể mở sẵn thư mục trước khi vào capability mode, rồi sau đó dùng os.Root để mở các tệp trong cây hệ thống tệp bên dưới thư mục đã mở đó

  • Tò mò liệu có thể chỉ định tag dùng khi cài đặt công cụ được chỉ định bằng chỉ thị tools hay không
    Tôi đã thử như bên dưới, nhưng có vẻ nó được cài mà không có tag
    go install -tags 'postgres' github.com/golang-migrate/migrate/v4/cmd/migrate@latest

  • Có nói rằng nếu dùng GODEBUG=fips140=only thì các thuật toán mật mã không tuân thủ FIPS 140-3 sẽ trả về lỗi hoặc panic, nhưng tôi không thích lắm cách thư viện chuẩn cố ý panic
    Tôi chưa xem code, nhưng tò mò không biết có phải vì tương thích ngược nên chỉ làm vậy ở các hàm hiện không trả về lỗi hay không

    • Đây là tính năng cần thiết trong môi trường chính phủ
      Nếu không kiểm tra lúc runtime xem FIPS có được bật hay không, sẽ có nguy cơ phá vỡ compliance, và cuối cùng dẫn đến kiểm toán cùng những cuộc họp bất tận. Tôi nghĩ một sự cố 30 phút do panic vẫn tốt hơn nhiều so với việc vất vả nhiều ngày để dựng các biện pháp kiểm soát và quy trình xác minh mới
    • Vậy thì đừng đặt flag đó là được
      Hành vi như vậy hữu ích trong các tình huống chỉ có thể phát hiện ở runtime. Chỉ cần có mức test coverage cơ bản là sẽ lộ ra ngay
    • Phương án thực tế duy nhất là trả về lỗi, nhưng lỗi có thể bị bắt rồi bỏ qua
      Tôi nghi ngờ liệu điều đó có đáng mong muốn trong tình huống có mã hóa hay không. Tôi nghĩ nên tránh mức log cảnh báo. Nếu quan trọng và có thể hành động thì nên là lỗi hoặc log fatal; nếu không thì log thông tin là đủ
    • Tôi đọc được rằng phần này có vẻ sẽ được dọn dẹp trong Go 1.25
      https://devblogs.microsoft.com/go/go-1-24-fips-update/
    • Như các bình luận cùng cấp, trong một số trường hợp cần phải cưỡng chế
      Cũng có thể xem đây là cách tránh các bug ẩn. Nó giống với "The server chose violence" [1] [2], và cũng đáng nghĩ xem định luật Postel đã cản trở khả năng tương tác đến mức nào. Điểm này thường bị quên trong nhiều khía cạnh của chứng nhận FIPS
      [1] https://cliffle.com/blog/hubris-reply-fault/
      [2] https://news.ycombinator.com/item?id=40178652

  • Cuối cùng bí danh kiểu generic cũng đã có, đúng là tính năng lẽ ra cần có từ lâu

  • Mong chờ nhất là cờ tool mới. Giờ có thể bỏ tools.go xấu xí rồi

  • Tốt. Tôi đã chờ bản phát hành này vì GOAUTH
    Hy vọng làm việc với các kho git riêng tư sẽ đỡ phiền hơn, nhưng xem go help goauth thì có vẻ không nên kỳ vọng quá nhiều