2017.08.09

구글 '고' 언어에서 개선해야 할 8가지

Paul Krill | InfoWorld
구글의 오픈소스 고(Go) 언어용 개발툴을 개선하기 위해 마이크로소프트와 레드햇의 언어 서버 프로토콜과 비슷한 자체 언어 서버를 가져야 할까?

현재 고 언어 컨트리뷰터 토론 그룹 내에서는 이와 관련된 논의가 한창이다. 아직 결론이 나지 않았고 활발하게 서로 의견을 내고 있다. 현재 많은 컨트리뷰터로부터 공감을 얻고 있는 것은 다음과 같다.

- 언어 서버 IDE와 기타 툴의 도입: 코드와 패키지 관련 정보를 색인하고 표시할 수 있다. 한 컨트리뷰터는 "마이크로소프트의 언어 서버 프로토톨은 에디터와 IDE내에서 광범위하게 지원되고 있다"라고 썼다. 이 프로토콜은 여러 코드 에디터와 IDE에 걸쳐 다양한 언어를 통합하기 위해 개발됐다.
- 통계를 리포트하는 표준 카운터 API 개발
- 일부 어셈블리 코드 재작성
- 고 크립토 코드 재작성: 크립토 코드는 어셈블리 내에서 성능 향상을 사용된다. 그러나 이 코드는 디버그하고 유지하고 읽기가 까다롭다. 한 참석자는 "이를 새로 만들면 코드 유지보수를 더 쉬워질 것이다. 고유의 프로세서를 추가하고 128비트 처리 지원을 강화하면 고의 크립토 성능을 향상할 수 있을 것이다"라고 썼다.
- 처리/비트 패키지 확장: 이 패키지는 비트 조작을 최적화하는 역할을 하는 것으로, 이달 중 나올 고 1.9 버전에 포함돼 있다.
- 컴파일러와 런타임내 가비지 컬렉션과 관련 툴의 리팩터 : 코어 툴과 IDE의 오버헤드를 줄일 수 있다.
- 빠른 문법 확인을 위해 IDE에 컴파일러 내장
- 메모리내 코드 컴파일: 파일 시스템을 줄이고 연속적인 테스트를 할 수 있다.

이 토론 그룹에서 제기된 다른 이슈로는 의존성 관리와 인터페이스 관련 문제가 있다. 의존성 관리는 새 버전을 내놓는 기간과 관련이 있다. 컨트리뷰터들에 따르면, 현재 표준 라이브러리의 핵심 패키지를 수정해 새 버전을 내놓거나 보안 이슈에 대응하기 위한 새 버전을 내놓는 데 6개월이 걸린다. 한 컨트리뷰터는 "의존성 관리를 개선하면 표준 라이브러리에서 추출한 일부 패키지를 자체 프로젝트에 넣는 마이그레이션을 더 수월하게 할 수 있다"라고 썼다.

표준 라이브러리 인터페이스 사용의 어려움을 지적하는 목소리도 높다. 한 컨트리뷰터는 "io.Reader가 컨텍스트를 도입해 읽기 작업을 막는 것을 중단할 수 있으면 더 좋을 것 같다"라고 썼다. 고의 오류에 관한 토론도 진행중이다. 한 사용자는 "많은 고 사용자가 '오류'가 인터페이스라는 사실에 대해 혼란을 느끼거나 이해하지 못하고 있다. 이는 io.EOF 같은 구분점 오류를 마스킹하지 않고 오류에 더 많은 정보를 넣는 것을 어렵게 만들 수 있다"라고 썼다. ciokr@idg.co.kr 
2017.08.09

구글 '고' 언어에서 개선해야 할 8가지

Paul Krill | InfoWorld
구글의 오픈소스 고(Go) 언어용 개발툴을 개선하기 위해 마이크로소프트와 레드햇의 언어 서버 프로토콜과 비슷한 자체 언어 서버를 가져야 할까?

현재 고 언어 컨트리뷰터 토론 그룹 내에서는 이와 관련된 논의가 한창이다. 아직 결론이 나지 않았고 활발하게 서로 의견을 내고 있다. 현재 많은 컨트리뷰터로부터 공감을 얻고 있는 것은 다음과 같다.

- 언어 서버 IDE와 기타 툴의 도입: 코드와 패키지 관련 정보를 색인하고 표시할 수 있다. 한 컨트리뷰터는 "마이크로소프트의 언어 서버 프로토톨은 에디터와 IDE내에서 광범위하게 지원되고 있다"라고 썼다. 이 프로토콜은 여러 코드 에디터와 IDE에 걸쳐 다양한 언어를 통합하기 위해 개발됐다.
- 통계를 리포트하는 표준 카운터 API 개발
- 일부 어셈블리 코드 재작성
- 고 크립토 코드 재작성: 크립토 코드는 어셈블리 내에서 성능 향상을 사용된다. 그러나 이 코드는 디버그하고 유지하고 읽기가 까다롭다. 한 참석자는 "이를 새로 만들면 코드 유지보수를 더 쉬워질 것이다. 고유의 프로세서를 추가하고 128비트 처리 지원을 강화하면 고의 크립토 성능을 향상할 수 있을 것이다"라고 썼다.
- 처리/비트 패키지 확장: 이 패키지는 비트 조작을 최적화하는 역할을 하는 것으로, 이달 중 나올 고 1.9 버전에 포함돼 있다.
- 컴파일러와 런타임내 가비지 컬렉션과 관련 툴의 리팩터 : 코어 툴과 IDE의 오버헤드를 줄일 수 있다.
- 빠른 문법 확인을 위해 IDE에 컴파일러 내장
- 메모리내 코드 컴파일: 파일 시스템을 줄이고 연속적인 테스트를 할 수 있다.

이 토론 그룹에서 제기된 다른 이슈로는 의존성 관리와 인터페이스 관련 문제가 있다. 의존성 관리는 새 버전을 내놓는 기간과 관련이 있다. 컨트리뷰터들에 따르면, 현재 표준 라이브러리의 핵심 패키지를 수정해 새 버전을 내놓거나 보안 이슈에 대응하기 위한 새 버전을 내놓는 데 6개월이 걸린다. 한 컨트리뷰터는 "의존성 관리를 개선하면 표준 라이브러리에서 추출한 일부 패키지를 자체 프로젝트에 넣는 마이그레이션을 더 수월하게 할 수 있다"라고 썼다.

표준 라이브러리 인터페이스 사용의 어려움을 지적하는 목소리도 높다. 한 컨트리뷰터는 "io.Reader가 컨텍스트를 도입해 읽기 작업을 막는 것을 중단할 수 있으면 더 좋을 것 같다"라고 썼다. 고의 오류에 관한 토론도 진행중이다. 한 사용자는 "많은 고 사용자가 '오류'가 인터페이스라는 사실에 대해 혼란을 느끼거나 이해하지 못하고 있다. 이는 io.EOF 같은 구분점 오류를 마스킹하지 않고 오류에 더 많은 정보를 넣는 것을 어렵게 만들 수 있다"라고 썼다. ciokr@idg.co.kr 
X