2P by neo 1일전 | favorite | 댓글 2개
  • 저자는 오리너구리

    • 비판을 무시하기 위해 저자를 무능하다고 치부하는 것은 게으른 방식임.
    • 주니어 개발자는 새로운 시각으로 문제를 바라볼 수 있으며, 이는 고용의 중요한 이유임.
    • 저자는 주니어 개발자가 아니며, 다양한 경험을 통해 언어 설계에 대한 이해를 가지고 있음.
  • 엄마가 담배를 피우니 괜찮을 거야

    • 다른 회사들이 사용하는 기술을 무조건 따라가는 것은 비효율적임.
    • 기술 블로그는 회사의 이미지를 좋게 보이게 하려는 목적이 있음.
    • Tailscale의 블로그는 솔직하지만, Go의 문제를 해결하기 위해 많은 노력이 필요함.
  • 좋은 부분

    • Go는 비동기 런타임과 쓰레기 수집기가 뛰어남.
    • 패키지 관리, 리팩토링, 크로스 컴파일링 등의 도구가 사용하기 쉬움.
    • 그러나 Go의 단점은 무시할 수 없으며, 언어의 설계가 우연히 이루어졌다는 점이 문제임.
  • Go는 섬이다

    • Go는 다른 언어와의 상호 운용성이 부족함.
    • Go의 도구 체인은 독특하며, 기존의 어셈블리 언어나 디버거를 사용할 수 없음.
    • 네트워크 경계를 통해 Go와 통합하는 것이 가장 쉬운 방법임.
  • 전부 아니면 아무것도 (그래서 아무것도 안 함)

    • Go는 초기화되지 않은 구조체 필드를 남길 수 있음.
    • 제로 값이 의미를 가지는 것은 순진한 생각이며, 많은 경우에 문제가 됨.
    • Go의 문화는 문제를 해결하기보다는 주의하라는 식임.
  • "Rust는 완벽하고 너희는 모두 바보야"

    • Rust는 점진적으로 도입할 수 있으며, 다른 언어와 잘 통합됨.
    • Rust의 성공은 부분적으로 안전한 언어로의 전환이 가능하다는 점에 있음.
    • Rust의 문제점도 존재하지만, 이는 점진적으로 해결되고 있음.
  • Go를 프로토타입/스타터 언어로 사용

    • Go는 배우기 쉬운 언어로 여겨지지만, 실제로는 많은 경험이 필요함.
    • 코드가 잘못되었음을 명확히 알 수 있는 기능이 부족함.
    • Go의 단점은 시간이 지남에 따라 드러나며, 쉽게 이동할 수 없는 언어임.
  • 우리가 Golang을 계속 사용하는 이유에 대한 거짓말

    • 다른 사람들이 사용하니 우리에게도 좋을 것이라는 생각
    • 언어 설계의 결함을 개별적으로 또는 집합적으로 괜찮다고 여기는 것
    • 주의 깊게 하면 문제를 극복할 수 있다는 생각
    • 작성하기 쉬우니 생산 소프트웨어 개발도 쉽다는 생각
    • 언어가 단순하니 모든 것이 단순하다는 생각
    • 나중에 언제든지 다시 작성할 수 있다는 생각

아주 찰나와 같은 시간동안 집중적으로 Go언어와 함께하고 있는 아마추어가 글을 남겨도 될까 싶습니다만... Go언어는 장점과 단점이 정말 명확해서 선택하시는 분들도, 피하시는 분들도 분명한 이유가 있어 보입니다. 개인적으로 Rust 언어와 비교할 건 아닌 거 같고 Kotlin(Java)과 비교하는 게 맞는 거 같습니다.

Go의 고루틴은 정말 훌륭하지만, 마법은 아닙니다. 특히 백엔드에서 MySQL을 하나만 쓰는 작은 프로젝트에서는 이 동시성이라는 게 관리하기 정말 까다롭습니다. JS/TS런타임에서는 크게 신경 안써도 되는 MySQL 자원 고갈 현상이나 풀 관리가 생각보다 어렵거든요. 결국 이 상황에서는 DB가 병목이 되므로 Go언어의 동시성에 대한 장점이 일부 퇴색됩니다. (JS/TS 런타임의 비동기 I/O나 이벤트 루프가 오히려 더 적절할 수도 있음) 당장 hey 같은 도구로 -c 100 이렇게 때려넣어보면 알 수 있습니다.

그리고 훌륭한 GC가 있지만, 그렇다고 함부로 객체를 포인터만 넘겨서 쓰다가 뒤처리는 나몰라라 해선 안됩니다. 모든 게 트레이트오프가 있지만, Go언어도 가능하면 작은 객체들은 그냥 값 복사로 넘겨서 사용하고 함수가 끝나면 바로 처리되도록 하는게 낫습니다. 제가 낡은 사고에 같혀 있는 걸지도 모르겠지만, C/C++ 언어처럼 효율의 관점으로 포인터를 쉽게 접근하면 안되었습니다.

error 를 함수 리턴할 때 거의 매번 리턴하고 그걸 매번 if err != nil {} 로 검사해야 하는 건 정말 귀찮지만, 이건 장점입니다. try catch 보다 비용이 저렴하니까요. 그리고 finally {} 와 같은 역할을 해주는 defer 키워드도 훌륭합니다. 자원 해제 시점을 고민할 필요가 없으니 좋습니다. 표준 라이브러리만으로 훌륭한 백엔드 서버 구성이 바로 가능한 점도 좋구요 (1.23 이상) 무엇보다 타켓 OS에 맞춰 빌드하면 다른 런타임이나 사전 설치가 필요하지 읺다는 점이 가장 좋습니다.

Go언어를 길게 쓰진 않았는데 너무 개인적인 의견으로 길게 쓰는 것 같아 이만 줄입니다. ㅎㅎ 저는 Go언어도 좋고 다른 언어도 좋습니다!

Hacker News 의견
  • Go 언어의 단점에 대한 많은 지적이 있지만, 명시적 오류 처리는 그 중 하나가 아님. 예외 처리는 너무 쉽게 실수할 수 있는 "마법" 같은 층을 추가함. 개인 프로젝트에서는 Rust를 선호하지만, 다양한 수준의 개발자가 참여하는 대규모 프로젝트에서는 Go의 철학이 현대 세계에서 가장 합리적인 오류 처리 접근법임.

    • Go는 단순함 덕분에 다른 "새로운" 언어보다 더 많이 채택되고 있음. 최고의 언어는 아니지만, 많은 내장된 의견으로 인해 일반 목적 언어로는 종종 최고의 선택임.
  • Rust와 Go는 매우 다르며, 사람들이 원하는 중간 지점은 현재 존재하지 않음.

    • Rust의 타입 시스템과 유사한 타입 시스템을 가진 상대적으로 간단한 언어가 필요함.
    • Gleam과 Kotlin이 약간 비슷하지만 완전히 그렇지는 않음. Rust는 너무 복잡해서 비전공자나 비전문가에게는 어려움.
    • 완벽한 언어는 없지만, Go와 Rust는 놀라운 점을 가져왔음. 두 언어에서 영감을 받아 널리 사용 가능한 간단한 프로그래밍 언어가 만들어지길 바람.
  • 단순한 언어를 좋아함. 기술은 항상 트레이드오프가 있기 때문에 균형 잡힌 비판이 중요함.

    • Go를 선택한 이유에 대한 블로그 링크를 공유함.
  • 언어를 비판하는 것이 왜 그렇게 중요한지 궁금함. 비판은 건설적인 스타일로 작성되지 않음.

    • 모든 언어는 비판받을 수 있음. Go는 "더 정교한" 언어와의 차이에도 불구하고 프로젝트에서 훌륭하게 작동함.
    • Go 팀에 피드백을 주고 언어의 느린 발전을 지켜보며 커뮤니티에서 서비스를 계속 제공함.
  • Go의 비판을 읽을 때마다 여전히 Go를 계속 사용할 것임.

    • 이론적으로 많은 문제가 있지만, 실제로는 여전히 좋은 프로그래밍 언어임.
    • 명시적 오류 처리를 좋아함. 다른 언어의 단점도 크게 신경 쓰지 않음.
    • Go의 단점에 민감한 사람들은 계속 불평할 것임. 자신에게 잘 맞는 언어를 선택함.
  • 다른 언어를 사용할 때마다 Go로 돌아가고 싶음.

    • Go는 설치하고 코드 다운로드 후 작성하면 끝임. 버전, 런타임, 설정, 빌드 도구, 패키지 관리자 등을 고민할 필요가 없음.
    • Rust도 비슷한 경험을 제공할 수 있음. Python, Typescript, Java를 사용할 때는 설정과 관련된 문제로 인해 프로그래밍이 두려움.
  • 더 나은 Python을 찾고 있었음. Go는 명백한 선택이었지만, 문법을 싫어함.

    • Rust는 많은 특수 문자를 사용하고, Lisp는 괄호와 역폴란드 표기법 때문에 싫어함.
    • Python 코드를 Nuitka로 컴파일하여 바이너리를 제공함. C#의 AOT 컴파일에 관심이 있음.
    • Nim과 Crystal을 좋아하지만 작은 커뮤니티가 장벽임. Nim은 작은 커뮤니티에도 불구하고 훌륭한 언어임.
  • Go와 Rust가 자주 비교되는 이유를 모르겠음. Java와 비교하는 것이 더 적절함.