핵심 타입(Core Types) 제거와 Go 언어의 간결한 진화

(go.dev)

2P by GN⁺ 7일전 | ★ favorite | 댓글 6개

Go 1.18에서 제네릭(generics) 기능 도입과 함께 새로운 개념인 핵심 타입(core type) 이 추가되었으나, 1.25에서 제거하기로 결정
핵심 타입은 컴파일러 구현 편의를 위한 추상 개념으로, 제네릭 타입 피연산자 처리 시 기존의 기저 타입(underlying type)을 대체함
언어 명세에서도 기존의 "기저 타입"을 "핵심 타입"으로 대체하여 사용함

타입 매개변수와 타입 제약

타입 매개변수는 미래에 결정될 타입을 위한 자리 표시자 역할을 하며 컴파일 시점에 결정됨
타입 제약은 해당 매개변수 타입으로 가능한 연산을 결정함
Go에서는 메서드와 타입 요구사항을 조합하여 타입 제약을 정의하며, 이를 통해 타입 집합(type set)을 형성함
타입 집합은 특정 인터페이스를 만족하는 모든 타입의 모임을 의미함
```
type Constraint interface {  
  ~[]byte | ~string  
  Hash() uint64  
}  
```
이러한 타입 집합 기반의 방식은 제네릭 타입 연산을 정의하는 데 매우 유연하고 강력함
```
func at[bytestring Constraint](s bytestring, i int) byte {  
  return s[i]  
}  
```

핵심 타입의 도입과 한계

핵심 타입은 일부 연산에서 제네릭 타입의 사용을 간단하게 만들기 위한 규칙으로 정의됨
핵심 타입 정의 방식:
- 일반 타입인 경우, 핵심 타입은 해당 타입의 기저 타입과 동일함
- 타입 매개변수인 경우, 타입 집합 내 모든 타입이 동일한 기저 타입을 가져야 핵심 타입이 존재함
하지만 이 방식은 다음과 같은 문제점을 유발함:
- 언어 명세가 복잡해져 단순한 규칙도 이해하기 어려워짐
- 비제네릭 코드에도 불필요하게 핵심 타입 개념이 언급됨
- 핵심 타입 개념이 있는 일부 연산은 과도하게 제한적이 되어 실제론 안전한 연산도 허용되지 않음
- 핵심 타입을 사용하지 않는 규칙들과의 불일치로 인해 언어 설계 전반에 일관성이 떨어짐

Go 1.25에서 핵심 타입 제거

Go 1.25 릴리스(2025년 8월 예정)에서는 핵심 타입 개념을 언어 명세에서 제거하기로 결정함
각 연산마다 필요한 제약을 명시적인 문장으로 기술하는 방식으로 전환됨
변경의 주요 효과:
- 개념 수를 줄여 Go 언어 학습이 더 쉬워짐
- 비제네릭 코드가 제네릭 개념에 의존하지 않고 명확해짐
- 특정 연산별로 더 유연한 규칙 설계 가능
- 향후 기능 확장을 위한 토대 마련 (예: 공통 필드 접근, 슬라이스 기능 강화, 타입 추론 개선 등)

주요 적용 사항 및 기대 효과

핵심 타입을 언급하던 모든 명세 문구가 제거되거나 명시적인 문장으로 교체됨
컴파일러 에러 메시지에서도 핵심 타입이라는 용어가 제거되고 더 구체적인 설명이 제공됨
기존 Go 프로그램의 동작에는 영향 없음
언어 명세는 더 간단해지고, 사용자 입장에서 Go 언어는 더 직관적이고 명확해짐

▲

GN⁺ 7일전 [-]

Hacker News 의견

Go 팀이 사양 변경을 매우 신중하게 다루는 점이 좋음
- Go 제네릭은 큰 변화이며 사용하기 어려울 수 있음
- 제약이 제네릭의 과도한 사용을 막아준다고 생각함
- Java와 Typescript 프로젝트에서 타입 시스템을 과도하게 사용하여 코드가 불명확해지는 경우를 봄
- Go 팀이 언어에 보수적으로 접근하길 바람
Go 개발팀의 지난 10년은 기능과 단순성 사이의 균형을 찾는 과정이었음
- 제네릭은 이러한 동적의 핵심을 잘 보여줌
- Go 위에 Rust와 같은 타입 시스템을 구현하는 것은 복잡성이 너무 큼
- 단순성을 중시하는 방향으로의 약간의 회귀가 좋음
- Go는 중급 엔지니어 팀에게 더 나은 Java가 되는 것이 목표임
Go 1.25는 실제 언어 기능을 추가하지 않음
- 1.30에서는 sum types가 추가될 수도 있음
Go를 Windows 빌드 이전부터 따라왔음
- 2011년에 배운 모든 것이 여전히 유효함
- Go로 작업할 기회가 없었지만 작은 프로젝트로 학습함
- Go 개발자 인터뷰에서 제네릭이 Go에 도입되지 않을 것 같다는 발언이 실망스러웠음
- 이제 제네릭이 도입되어 Go로 사이드 프로젝트를 시작할 계획임
close의 인자가 타입 파라미터일 때 모든 타입은 동일한 요소 타입의 채널이어야 한다는 것은 사실이 아님
- 요소 타입은 close에 영향을 주지 않으며, 다른 요소 타입을 가진 타입 세트를 사용할 때도 컴파일이 잘 됨
- 문서 개선이 필요함
- 공유 필드와 같은 유연성 확장이 가속화되길 바람
Go를 천천히 배우고 있으며, C++ 배경이 있음
- 템플릿 특수화와 유사한 것인지 궁금함
- 더 많은 언어가 이를 지원하길 바람
[dead]
이제 생성 AI가 코드를 작성할 수 있게 되었는데, 가비지 컬렉터가 여전히 필요한지 궁금함