(b Box[T]) Map[U any](f func(T) U) Box[U] 같은 인지 부담을 Go가 피해 가서 좋았는데 아쉬움

이름을 제외하면 인지 부담은 고차 함수에서 오므로 피하기 어려움. 이를 없애면 코드 중복이 크게 늘어남
구체성을 유지하고 고수준 추상화를 피하려는 마음은 이해하지만, 쉽게 자동화할 수 있는 작업을 자동화하지 않겠다는 결정이며 컴퓨터 분야의 본능과 목적에 어긋나기에 오래 지속되지 못함

이름 규칙을 개선하면 이해하기 쉬워질 수 있음
Go에서는 (b Box[InType]) Map[OutType any](transformFunction func(InType) OutType) Box[OutType], Python에서는 def map[OutType](self, transform_function: Callable[[InType], OutType]) -> Box[OutType], Java에서는 public Box map(Function transformFunction)처럼 역할이 드러나는 이름을 쓰는 편이 나음

제네릭 매개변수에 한 글자 이름을 쓰는 관습을 이해하기 어려움. C++에서 시작해 다른 언어들이 따라 한 듯하지만, IN과 OUT, In과 Out, TIn과 TOut처럼 쓰면 훨씬 읽기 쉬울 것임

애초에 좋은 Go 코드가 아님. Go라면 for 루프를 써야 하며, 제네릭이 생겼다고 ML·Haskell·Rust·C#처럼 작성할 필요는 없음

익숙함의 차이일 수 있지만 구두점을 더 넣으면 훨씬 이해하기 쉬워 보임. 문법이 형식적으로 모호하지 않다고 해서 사람 눈에도 명확한 것은 아님 func (b: Box[T]).Map[U: any](f: func(T) -> U) -> Box[U]

HTTP 응답 본문을 자동으로 비우는 동작은 위험한 묵시적 변경임. 대부분의 애플리케이션에는 개선이겠지만 기존 동작에 의존했다면 매우 미묘한 문제가 생길 수 있음

Go 팀도 릴리스 노트에서 이를 다룸. Transport의 MaxIdleConns를 0으로 설정하는 등 유휴 연결을 대량으로 남겨 두는 용례에만 영향이 있을 것으로 보며, 이 경우 연결 재사용을 비활성화하라고 권장함

Go의 강점은 늘 표준 라이브러리였고, 특히 암호화 패키지가 훌륭함

The quieter but bigger change 같은 어리석은 LLM 특유의 표현을 쓰지 않았으면 함

LLM이 쓴 글에 계속 노출되면 인간도 점차 그런 식으로 쓰고 말하게 될지 궁금함. 결국 LLM과 인간의 글을 구분할 수 없어질지도 모르며, 나도 농담으로 footgun 같은 단어를 예전보다 자주 쓰게 됨
“밖의 동물들은 돼지에서 인간으로, 인간에서 돼지로, 다시 돼지에서 인간으로 시선을 옮겼지만, 어느 쪽이 어느 쪽인지 이미 구분할 수 없었음.” — George Orwell, Animal Farm

글 전체가 명백히 LLM 생성물로 보이므로 릴리스 노트를 직접 읽는 편이 훨씬 나음

Worth flagging, real gap, transparent win, center of gravity 같은 상투적 문구에 이제 지침

이 글은 대부분 LLM으로 생성된 듯함

Golang의 제네릭 문법은 읽기가 너무 어려워 보임

한참 살펴보니 Java보다는 Go 쪽이 나은 듯함. 다른 Go 코드와 마찬가지로 제네릭 함수의 시그니처를 여러 줄로 나누면 크게 나쁘지 않음
Java는 볼수록 난잡해 보이며 Map>, ? extends Map>>>>>> config; 같은 코드는 특히 끔찍할 것임. Go는 이곳에서 비판을 많이 받지만, 적은 코드로 런타임 없이 컴파일된 바이너리를 만들 수 있어 좋아함. 고루틴에 익숙해지고 나니 주 용도인 웹 애플리케이션 백엔드에도 꽤 탄탄함

장황하긴 해도 타입 추론 덕분에 상당히 깔끔해짐. 제네릭을 다룰 때는 집중력을 한 단계 높이게 되며, 정말 필요할 때만 사용하는 기능 중 하나임

읽기 어렵지만 일반적인 코드라기보다는 TypeScript의 고급 타입처럼 주로 라이브러리 내부에 머무는 기능으로 봄

표준 라이브러리에 SIMD가 추가되고 map에서도 사용되는 점이 좋음. 기존 코드의 성능 핵심 루프에서 실험할 곳을 찾아봐야겠음