Go 1.27 새 인터랙티브 투어, 리시버와 독립적인 타입 파라미터를 갖는 제네릭 메서드가 핵심 기능으로 등장

제네릭 도입 놀라운데, 언어 설계자들 생각이 왜 바뀐 건지 궁금함. 20년 걸려서 제대로 이해했다는 설명은 안 믿김, 원래 설계 단계에서 고려했어야 하는 문제잖아

원년 멤버들이 다른 프로젝트로 옮기고 새 커뮤니티 메인테이너들이 프로포절/거버넌스 과정 거쳐서 합의에 도달한 거임, 그게 다임

나 예전에 Go 팀에 있었는데 진짜 그게 다임. Ian 혼자서 제네릭 방안을 대여섯 개는 제안했다가 스스로 기각했음. 결국 다들 마음에 드는 언어+구현 계획이 나온 거지, 제네릭 반대하는 사람은 못 봤음

처음 설계에 없었다고 나중에 넣기 더 어려웠다는 것도 사실 아님. 이 사이트에서 Go 까는 거 근거 없는 추측이 너무 많음

이진 탐색 버그 없는 구현도 1946년부터 1962년까지 16년 걸렸다는데, 제네릭 구현에 20년 걸린 것도 그럴 수 있다고 봄

여전히 1970년대 수준의 제네릭보다 못함 ㅋㅋ

솔직히 아무것도 안 바뀜. Go는 원래 특별한 생태계였는데 제네릭 넣은 건 큰 실수임. 예전엔 아무 Go 코드나 보면 바로 이해가 됐는데 이제는 아님

이 정도 수준의 제네릭이면 Go 다시 관심 생김

제네릭 문법 진짜 읽기 어려움

장황하긴 한데 타입 추론이 잘 도와줘서 그나마 깔끔함, 근데 나는 진짜 필요할 때만 씀

그래도 C++ 제네릭보단 훨씬 나음

제네릭으로 if err 패턴 없앨 수 있음? 결국 Option 쓰면 편의성에서 손해 보고 안전성만 얻는 구조라 실익이 별로 없다고 봄

Go 팀이 작년 6월에 에러 처리 문법 관련 프로포절은 더 이상 안 다루기로 선언함, 개인적으로는 그 결정에 동의함

유휴 HTTP 응답 바디를 자동으로 드레인하는 건 조용한 동작 변경이라 위험함, 대부분 앱엔 개선이겠지만 기존 동작에 의존하던 곳엔 문제될 수 있음

MaxIdleConns를 0으로 설정해서 유휴 커넥션을 오래 두는 경우에만 영향 있을 거라고 릴리스 노트에서 설명함, 그런 경우엔 킵얼라이브를 끄라고 권장함

stdlib에 SIMD 들어가고 map에도 쓰이는 거 좋아 보임, 핫루프 코드에 적용해볼 자리 찾아봐야겠음

제네릭은 미끄러운 비탈길임, 10년 지나면 Go도 C++이랑 구분 안 갈 거임

제약 조건에 ~C, ~[]S 같은 한 글자짜리 이름 쓰는 거 진짜 별로임, Comparable이나 Slicable처럼 이름 지었어야 함