나는 Go를 정말 좋아함. 모노레포 환경에서 특히 빛을 발함. 새 애플리케이션을 추가할 때 폴더 하나 만들고 main() 함수가 있는 go 파일만 넣으면 됨. 루트에서 go install ./... 하면 전체가 빠르게 빌드됨
CLI 프로그램을 빠르게 만들어야 할 때 이 단순함이 정말 신의 한 수였음
다른 언어들도 거의 다 이렇게 할 수 있는 거 아닌가 하는 의문이 있음
이런 모노레포 활용 사례는 더 자주 언급되어야 한다고 생각함
예전엔 언어가 병목이 아니라고들 했지만, Go를 처음 봤을 때 “이건 다르다”는 생각이 들었음. 배우기도 정말 빠름 — 언어 스펙이 작아서 그런 듯함.
체감상 Rust의 80% 기능을 20% 노력으로 얻는 느낌임
Go의 좋은 점은 언어 전체를 짧은 시간 안에 다 익힐 수 있다는 점임. 동시성이나 함정까지 포함해서 전부 파악 가능함. 반면 C#이나 C++은 너무 복잡해서 전체를 이해하는 사람은 거의 없음
Rob Pike의 말처럼 Go는 주니어 개발자를 위해 설계된 언어임. 구글 내부에서 빌드 시간을 줄이려는 목적도 컸음. 그래서 사용하지 않는 의존성이 있으면 컴파일 에러가 남 (출처)
언어 스펙이 작다고 꼭 단순한 건 아님. 예를 들어 Swift는 스펙이 커도 느슨하게 정의되어 있음. Go 스펙을 보다가 정수 리터럴 문법에서 오류를 발견했을 정도임
하지만 Rust의 남은 20% 기능이 유용성의 80% 를 차지한다는 점이 아쉬움
게다가 Go도 점점 복잡해지고 있음. 예를 들어 제네릭이 추가된 이후로 단순함이 줄어듦
내게 Go는 과도하게 단순화된 Rust 같음. 코드 자동 수정, 반복문 강제, map 키 존재 확인도 불편함.
배열 처리나 enum 정의도 어색하고, 회사의 linter 규칙 때문에 코드가 쪼개져서 마치 엔터프라이즈 Java 같아짐.
그래도 인터페이스는 단순하고, 배우기 빠름.
만약 Go가 제대로 된 enum, 자연스러운 slice 문법, iterator, 결과 언래핑 단축 문법을 가졌다면 훨씬 좋았을 것임
Go의 단점 중 하나는 짧은 변수명 문화임. 구조체 첫 필드가 상속처럼 동작하거나, 대문자/소문자로 접근 제어를 하는 것도 불편함.
기본 json 라이브러리도 빈 slice를 null로 직렬화하는 등 문제 많음.
그래도 툴링 속도는 빠르고, 실용성은 인정함
나는 Go의 lexer/parser를 포크해서 Result[T]/Option[T] , sum type, iterator, tuple 등을 추가한 실험 언어를 만들었음 (agl 프로젝트)
Go에도 enum은 있음. 다만 sum type이 없을 뿐임. 배열과 slice는 C와 거의 동일하고, “매직”이 부족해서 오히려 혼란스러워 보일 뿐임. 결과 언래핑은 커뮤니티가 오랫동안 논의 중이지만 아직 깔끔한 해법이 없음
Hacker News 의견
나는 Go를 정말 좋아함. 모노레포 환경에서 특히 빛을 발함. 새 애플리케이션을 추가할 때 폴더 하나 만들고
main()함수가 있는 go 파일만 넣으면 됨. 루트에서go install ./...하면 전체가 빠르게 빌드됨CLI 프로그램을 빠르게 만들어야 할 때 이 단순함이 정말 신의 한 수였음
예전엔 언어가 병목이 아니라고들 했지만, Go를 처음 봤을 때 “이건 다르다”는 생각이 들었음. 배우기도 정말 빠름 — 언어 스펙이 작아서 그런 듯함.
체감상 Rust의 80% 기능을 20% 노력으로 얻는 느낌임
내게 Go는 과도하게 단순화된 Rust 같음. 코드 자동 수정, 반복문 강제, map 키 존재 확인도 불편함.
배열 처리나 enum 정의도 어색하고, 회사의 linter 규칙 때문에 코드가 쪼개져서 마치 엔터프라이즈 Java 같아짐.
그래도 인터페이스는 단순하고, 배우기 빠름.
만약 Go가 제대로 된 enum, 자연스러운 slice 문법, iterator, 결과 언래핑 단축 문법을 가졌다면 훨씬 좋았을 것임
기본 json 라이브러리도 빈 slice를 null로 직렬화하는 등 문제 많음.
그래도 툴링 속도는 빠르고, 실용성은 인정함
결과 언래핑은 커뮤니티가 오랫동안 논의 중이지만 아직 깔끔한 해법이 없음
배열 중간에서 요소를 자주 삭제한다면 자료구조 선택이 잘못된 것임
slices.Delete로 삭제 가능하고,if err != nil강제 같은 건 언어 문제가 아니라 팀 규칙 문제임Go가 Apple II용으로 출시되는 줄 알고 잠시 기대했음 (SWEET16 참고)
새로운 Go 코드베이스에 기여하기가 쉬움.
언어의 단순함과 gofmt, golangci-lint 같은 표준 도구 덕분에 모든 코드베이스가 비슷한 구조를 가짐.
다른 언어 커뮤니티처럼 빌드 도구 논쟁이 없음
다만
%연산자의 음수 처리 방식은 헷갈렸음자동 코드 현대화 도구(modernizer) 도입이 흥미로움.
gopls v0.18.0부터 구문 분석을 통해 오래된 관용구를 찾아 더 빠르고 안전한 코드로 자동 변환해줌.
gofmt가 스타일 일관성을 만든 것처럼, modernizer는 관용구 일관성을 만들어줄 것임
golangci-lint에서 exhaustive, exhaustruct, wrapcheck 같은 린터를 켜면 안전성이 크게 향상되고 개발 속도가 빨라짐
우리 회사에서는 Go 백엔드 개발자를 위한 10주 온보딩 프로그램을 운영 중임 (계획 링크)
Python에서 Go로 전환한 지 7년 됐는데, 이게 스타트업 성공의 핵심 요인이었음
처음엔 Go를 의심했지만, 지금은 가장 좋아하는 언어임. 단순하면서도 강력함.
다만 null 검사, 에러 스택 트레이스, sum type의 exhaustive 체크가 기본 제공되면 좋겠음
Go는 함수형 프로그래밍 관련 기능이 조금만 더 있으면 완벽할 것 같음.
특히 불변성과 null 처리, switch exhaustiveness가 아쉬움.
Uber의 NilAway를 써서 보완 중이지만, 타입 시스템 차원에서 지원되면 더 좋겠음