dakeshi

오직을 강조하신 이유가 명백해졌네요. 👍 타입 자체보다 송수신이 강조되니 훨씬 좋아졌습니다. 아래와 같은 형태도 괜찮을 듯. 보내기만 가능(float 64 타입의 값) 받기만 가능(int 타입의 값)

롭 파이크의 제안을 읽어보니 infinite precision(=arbitary precision)은 하드웨어 레지스터 처리 용량에 상관없이 프로그래밍 레벨 단계(상위 레벨)에서 구현하는 것으로 보이는데 제가 이해한게 맞나요? 위키에서도 약간 혼동되게 설명해놨네요. 처음에는 호스트 하드웨어에 따라...

8번과 관련해서 go 버전 넘버도 섹션에 포함하면 어떨까요? 번역자 이름 아래 정도에 위치시키면 작업 추적하는데 도움이 될 것 같습니다. Effectvie Go 문서를 보니 discussion open 된 것 중에 이미 수정된...

1번과 관련해서 Effective Go의 경우 번역글 첫 부분이 아래 구조로 되어있네요. *원문 : 영문섹션이름(섹션 링크) *번역자: 번역자 이름(@id 또는 이메일) 이 형태를 사용해도 괜찮을것 같네요. go 버전 넘버도 추가한다면 글...

Go 버전은 아래 포맷으로 통일했습니다. (README 참고) ``` * Go 버전: 1.9 ```

`패키지 이름없이 사용된 타입 이름`이라는게 import 한 패키지에 있는 타입의 이름을 의미하는 건가요? 아니면 외부 패키지가 아니라 해당 소스 코드에서 선언한 type의 이름을 사용한 경우를 말하나요?

https://www.transifex.com/golang-korea/go-specification/translate/#ko/program_initialization_and_execution_package_initializationmd/130649498

리뷰를 앞부분만 한 것 같네요. 다시 리뷰 대기열로 옮기겠습니다.

### 버그 리포트 pr은 번역 파일에 대한 approve시 생성되는게 원칙인데, 신규 approve가 발생하지 않은 상황에서 pr이 생성되는 문제 발견. 더욱이 이미 merge된 내용의 pr이 중복 생성됨 #170, #174 는 시간...

### 단점 번역 파일에 대한 approve가 아니라 파일 내 문장 단위로 approve 처리시 중간 번역물 기준으로 pr이 생성되는 문제점 존재함.(GitHub 자동 sync 모드일 때)