Hacker News 의견

• 프로젝트 회고에 시간을 할애하는 핵심 인물들에 대한 감사함

  • 시스템 프로그래밍에 초점을 맞춘 언어 제한
  • 언어와 원칙을 명확히 정의하여 모호함과 목적이 다른 설계 낭비 방지
  • 품질을 우선시하여 문제를 배포 전에 해결하는 것이 모든 이해관계자에게 저렴함
  • 커뮤니티 공유와 엄격한 언어 및 릴리스 관리의 균형 유지
  • 구글의 비개입이 Go의 성공에 기여했으며, 이는 다른 프로젝트에서도 가능한지 의문 제기
  • Go가 서버 측 소프트웨어를 자바에서 네이티브 컨테이너로 이동시키는 핵심 기술이었으며, 지난 10년간 웹 애플리케이션 인프라의 대부분을 지원함

• Go 언어와 커뮤니티에 대한 애정

  • 2012년 파이썬 개발자로서 Go를 접하고 비트 조작의 용이성에 놀람
  • 10년 후 여전히 Go의 대부분의 기능이 잘 작동하는 것에 놀라움
  • Rob, Ian, Russ 등이 Go를 위해 한 일과 커뮤니티와의 "도로의 울퉁불퉁함"에 대한 솔직함에 감사
  • 패키지 관리 문제에 대한 비판적인 시각도 있지만, 현재 좋은 해결책에 도달했다고 평가

• Go의 패키지 관리 시스템에 대한 비판적인 경험 공유

  • 10년 전 go-nuts에서 Go의 패키지 관리 방식에 대해 비판적인 의견을 제시했을 때 Rob Pike로부터 무시당한 경험

• Go 언어에 대한 비판적인 시각

  • 언어의 깊은 문제에 대한 인정 부족
  • 타입 시스템, 에러 처리, 안전하지 않은 동시성, 단순한 문법 등으로 인해 Go를 추천하지 않음
  • Rust를 주 언어로 사용하며, Go가 가지지 못한 비전을 Rust에서 발견함

• Ken Thompson의 C 컴파일러 사용 결정에 대한 흥미로운 점

  • LLVM 대신 Ken Thompson의 C 컴파일러를 사용한 결정에 대한 불만과 초기 버전의 최적화되지 않은 코드 생성에 대한 언급
  • 이 결정으로 인해 세그먼티드 스택을 빠르게 구현할 수 있었음

• gofmt의 성공적인 도입에 대한 강조

  • 프로젝트 초기부터 코드 포맷에 대한 논쟁을 완전히 제거하여 큰 가치를 제공함
  • 여러 새로운 언어가 gofmt를 모방하거나 비슷한 도구를 만드는 것을 보임

• GopherConAU 주최자로서 전체 재생 목록 공유

  • 재생 목록을 공개할 수 없는 이유를 모르겠음

• Go를 사용하여 모노레포를 쉽게 만들고 앱을 빠르게 빌드할 수 있는 장점

  • Go로 CLI 도구를 만들기 쉽고 유닉스 파이프라인의 일부로 사용할 수 있음
  • Go가 대용량 로그 분석 등에 유용함

• Go의 상호 운용성과 C FFI에 대한 선택 언급 부족

  • "Go로 다시 작성"이라는 답변이 다른 옵션들을 배제함

• 컴파일러를 자체 언어로 작성하는 것에 대한 의견

  • 자체 언어로 컴파일되지 않는 언어가 컴파일러 작성에 적합하지 않은지에 대한 질문 제기
  • 컴파일러에 적합한 언어가 다른 애플리케이션에 적합하지 않을 것이라는 함축에 대한 이해 부족과 더 많은 맥락 요구