Loại bỏ Core Types và quá trình tiến hóa gọn gàng của ngôn ngữ Go

• Cùng với việc đưa tính năng generics vào Go 1.18, một khái niệm mới là core type cũng được thêm vào, nhưng đã được quyết định loại bỏ trong 1.25
• Core type là một khái niệm trừu tượng nhằm giúp việc hiện thực trình biên dịch thuận tiện hơn, dùng để thay thế underlying type hiện có khi xử lý toán hạng của kiểu generic
• Trong đặc tả ngôn ngữ, cụm "underlying type" cũng đã được thay bằng "core type"

Tham số kiểu và ràng buộc kiểu

• Tham số kiểu đóng vai trò như chỗ giữ chỗ cho kiểu sẽ được quyết định trong tương lai và được xác định tại thời điểm biên dịch
• Ràng buộc kiểu quyết định những phép toán có thể áp dụng cho kiểu tham số đó
• Trong Go, ràng buộc kiểu được định nghĩa bằng cách kết hợp yêu cầu về phương thức và kiểu, qua đó hình thành type set
• Type set là tập hợp của mọi kiểu thỏa mãn một interface cụ thể

  type Constraint interface {  
    ~[]byte | ~string  
    Hash() uint64  
  }  
  

• Cách tiếp cận dựa trên type set như vậy rất linh hoạt và mạnh mẽ trong việc định nghĩa các phép toán cho kiểu generic

  func at[bytestring Constraint](s bytestring, i int) byte {  
    return s[i]  
  }  
  

Sự ra đời và giới hạn của core type

• Core type được định nghĩa như một quy tắc để đơn giản hóa việc dùng kiểu generic trong một số phép toán
• Cách xác định core type:
  • Với kiểu thông thường, core type giống với underlying type của kiểu đó
  • Với tham số kiểu, chỉ khi mọi kiểu trong type set đều có cùng underlying type thì core type mới tồn tại
• Tuy nhiên, cách làm này gây ra các vấn đề sau:
  • Đặc tả ngôn ngữ trở nên phức tạp hơn, khiến cả những quy tắc đơn giản cũng khó hiểu
  • Khái niệm core type bị nhắc đến một cách không cần thiết cả trong mã không dùng generic
  • Một số phép toán có dùng khái niệm core type trở nên quá hạn chế, khiến cả những phép toán thực tế an toàn cũng không được phép
  • Sự thiếu nhất quán với các quy tắc không dùng core type làm giảm tính thống nhất trong toàn bộ thiết kế ngôn ngữ

Loại bỏ core type trong Go 1.25

• Trong bản phát hành Go 1.25 (dự kiến vào tháng 8 năm 2025), đã quyết định loại bỏ khái niệm core type khỏi đặc tả ngôn ngữ
• Thay vào đó, mỗi phép toán sẽ được mô tả bằng các câu chữ tường minh nêu rõ ràng buộc cần thiết
• Tác động chính của thay đổi này:
  • Giảm số lượng khái niệm, giúp việc học Go dễ hơn
  • Mã không dùng generic trở nên rõ ràng mà không phụ thuộc vào khái niệm generic
  • Có thể thiết kế quy tắc linh hoạt hơn cho từng phép toán cụ thể
  • Tạo nền tảng cho các mở rộng tính năng trong tương lai (ví dụ: truy cập trường chung, tăng cường khả năng của slice, cải thiện suy luận kiểu, v.v.)

Những áp dụng chính và hiệu quả kỳ vọng

• Mọi câu chữ trong đặc tả từng nhắc đến core type sẽ bị loại bỏ hoặc được thay bằng diễn đạt tường minh
• Trong thông báo lỗi của trình biên dịch, thuật ngữ core type cũng sẽ được loại bỏ và thay bằng mô tả cụ thể hơn
• Không ảnh hưởng đến hành vi của các chương trình Go hiện có
• Đặc tả ngôn ngữ sẽ đơn giản hơn, và từ góc nhìn người dùng, Go sẽ trực quan và rõ ràng hơn

[GN⁺]

Ý kiến Hacker News

• Thật tốt khi nhóm Go xử lý các thay đổi trong đặc tả một cách rất thận trọng

  • Generics của Go là một thay đổi lớn và có thể khó sử dụng
  • Tôi nghĩ các ràng buộc giúp ngăn việc lạm dụng generics
  • Tôi đã thấy trong các dự án Java và Typescript việc lạm dụng hệ thống kiểu khiến mã nguồn trở nên khó hiểu
  • Tôi mong nhóm Go tiếp cận ngôn ngữ một cách bảo thủ

• 10 năm qua của đội ngũ phát triển Go là quá trình tìm kiếm sự cân bằng giữa tính năng và sự đơn giản

  • Generics cho thấy rất rõ cốt lõi của động lực này
  • Việc triển khai một hệ thống kiểu như Rust trên Go có độ phức tạp quá lớn
  • Một chút quay lại theo hướng coi trọng sự đơn giản là điều tốt
  • Mục tiêu của Go là trở thành một Java tốt hơn cho các nhóm kỹ sư tầm trung

• Go 1.25 không bổ sung tính năng ngôn ngữ thực sự nào

  • Ở 1.30, sum types có thể sẽ được thêm vào

• Tôi đã theo dõi Go từ trước cả bản dựng Windows

  • Mọi thứ tôi học vào năm 2011 vẫn còn nguyên giá trị đến nay
  • Tôi không có cơ hội làm việc với Go, nhưng đã học qua các dự án nhỏ
  • Tôi từng thất vọng vì trong một buổi phỏng vấn với lập trình viên Go có phát biểu rằng có lẽ generics sẽ không được đưa vào Go
  • Giờ generics đã được đưa vào, nên tôi dự định bắt đầu một side project bằng Go

• Việc nói rằng khi đối số của close là tham số kiểu thì mọi kiểu đều phải là channel có cùng kiểu phần tử là không đúng

  • Kiểu phần tử không ảnh hưởng đến close, và ngay cả khi dùng tập kiểu có các kiểu phần tử khác nhau thì vẫn biên dịch tốt
  • Cần cải thiện tài liệu
  • Tôi hy vọng việc mở rộng tính linh hoạt như shared field sẽ được đẩy nhanh

• Tôi đang học Go một cách chậm rãi và có nền tảng C++

  • Tôi tự hỏi liệu điều này có giống với template specialization hay không
  • Tôi mong nhiều ngôn ngữ hơn sẽ hỗ trợ điều này

• [dead]

• Giờ AI tạo sinh đã có thể viết mã, nên tôi tự hỏi liệu garbage collector có còn cần thiết hay không

[aer0700]

Giờ đây AI tạo sinh đã có thể viết mã, nên tôi tự hỏi liệu trình thu gom rác có còn cần thiết nữa không

Thật gợi nhiều suy nghĩ...

[galadbran]

Ồ.. nếu AI đạt đến mức có thể viết ra loại mã ở trình độ đó (mã xử lý quản lý bộ nhớ một cách hoàn hảo), thì có lẽ sẽ rất khó để các lập trình viên con người tiếp tục giữ vai trò như hiện nay.

[kandk]

Có thể giải 1+1=2 bằng toán học rồi, vậy cần gì phải giải bằng AI nữa..

[jeiea]

Liệu GC cũng có ý nghĩa ở khía cạnh giảm bớt phần mã khuôn mẫu để con người đọc và giảm lượng ngữ cảnh mã phải lần theo không?
Nếu là dự đoán rằng thậm chí sẽ không còn cần phải đọc mã nữa thì chuyện đó lại khó nói.
Nhìn việc bình luận gốc cũng bị làm mờ đi thì có vẻ nó không nhận được nhiều sự đồng cảm.

[savvykang]

Không phải có thể loại bỏ reference counting khi thời điểm cấp phát và giải phóng bộ nhớ có thể được tính toán ở thời điểm biên dịch sao? Có vẻ như tác giả bình luận gốc trên Hacker News chưa hiểu vấn đề tái sử dụng bộ nhớ.