가끔 Go는 No-Go가 되어야 합니다

Java 개발자가 Go에 Java 스타일을 강요하면 문제가 발생함
- Go 철학은 단기적으로는 덜 유용하지만, 장기적으로는 큰 차이를 만듦
- JVM 생태계에 깊이 빠진 사람들은 Go를 즐기기 어려움
많은 개발자들이 너무 이른 추상화를 시도함
- 간단한 반복이 충분할 때 불필요한 추상화를 만듦
Go의 표준 라이브러리는 크지만 모든 것을 할 수 있을 만큼 크지는 않음
- 프로젝트마다 바퀴를 재발명하는 경향이 있음
- Go는 서버/CLI 애플리케이션에 이상적임
프로그래밍 언어 선택보다 더 큰 도전 과제가 존재함
- Go의 메커니즘과 철학에 적응하는 것이 중요함
Go를 좋아하는 이유를 이해하기 어려움
- 언어 자체보다는 도구 체인과 배포의 용이함을 선호함
Go의 핵심 팀이 잘못된 결정을 되돌리는 것이 좌절감을 줌
- 좋은 패키지 시스템과 도구가 존재함
- 복잡한 ERP 시스템에는 Java가 더 나은 선택일 수 있음
Go는 UNIX와 같은 문제를 가짐
- 복잡성을 사용자에게 떠넘기는 경향이 있음
- Java의 런타임은 Go에 비해 빠르게 발전하고 있음