목록으로
'언젠가 읽기' 컨텐츠는 논문이나 영문 컨텐츠 등 언젠가 읽으려고 즐겨찾기 하고선 읽지 않고 계속 미룰만한 컨텐츠를 읽고 요약하거나 소개합니다.

때로는 '가자'가 '안 가다'가 되어야 한다

언젠가 읽기
2025. 3. 13. PM 8:30:19

요약: 왜 Go는 때때로 사용하지 말아야 하는가

저자 소개 및 배경

저자는 내년에 클라이언트를 변경하면서 프로그래밍 언어도 Go에서 Java로 전환할 계획이라고 밝힙니다. Go의 메커니즘과 철학에 대해 오랫동안 불만을 품어왔으며, 이번 전환에 안도감을 느끼고 있습니다. 저자는 특정 소프트웨어 개발 유형에 따라 Go가 적합하지 않을 수 있다고 주장합니다.

Go의 단점

1. Go는 지루하다

Go는 루프를 위한 for 외에 필터, 맵, 리듀스를 수행할 수 있는 내장 함수가 없고, 다른 언어에서 제공하는 다양한 트릭이 부족합니다. Reddit 사용자 rochakgupta는 Go가 "지루하지만 좋은" 언어라고 설명하며, 필수적인 기능들이 부족하여 외부 패키지에 의존해야 한다고 지적했습니다. 예를 들어, samber/lo 패키지는 많은 프로젝트에서 사용되고 있으며, Go의 기본 패키지인 slices에서도 일부 기능이 추가되었지만 여전히 부족하다고 느낍니다. 저자는 반복문을 반복해서 작성하는 대신 맵과 필터 같은 고수준의 연산을 선호합니다.

2. Go는 클린 코드 원칙을 저해한다

함수를 추출하면 대부분의 경우 두 번째 반환 타입이 에러가 되며, 이는 추가적인 if err != nil 검사를 삽입해야 함을 의미합니다. 이러한 에러 처리는 코드의 복잡성을 증가시키고, HTTP 핸들러의 코드 라인이 불필요하게 길어지게 만듭니다. 저자는 이러한 문제로 인해 코드를 정리하기 어렵다고 느끼며, panic()과 복구 미들웨어를 사용하는 방안을 고려하기도 했습니다.

3. Go는 변수, 메서드, 함수의 긴 이름 사용을 장려하지 않는다

Go는 변수명이나 함수명을 짧게 유지하도록 권장하여, 코드의 가독성이 떨어질 수 있습니다. 예를 들어, 수신 변수명을 ca와 같이 짧게 사용하는 것은 가독성을 저해하며, 팀 내에서 코드 리뷰 시 불필요한 논쟁을 초래할 수 있습니다.

4. Go는 의도적으로 작고 간단하며 Do It Yourself(직접 구현)를 권장하지 않는다

Go는 간단한 HTTP 핸들러를 쉽게 설정할 수 있지만, 기본 미들웨어(예: 지수 백오프, 교차 사이트 요청 등)를 포함하지 않습니다. 이는 표준적인 기능을 구현하기 위해 여러 패키지를 조합해야 하며, 이는 개발자의 부담을 증가시킵니다.

결론

Go는 그 단순성과 최소주의로 인해 때때로 개발자의 생산성과 코드의 가독성을 저해할 수 있습니다. 특정 프로젝트와 요구 사항에 따라 Go가 적합하지 않을 수 있으며, 이 경우 다른 언어로의 전환을 고려할 필요가 있습니다.

함께 읽으면 좋은 참고 자료

  • "Why Go is Boring and That's a Good Thing" - Russ Cox
  • "Error Handling: No-Goes in Go"
  • "Go is Boring and That's Good" - Reddit 게시글

[출처] Go Should Sometimes Be a No-Go