golang에서 부트스트래핑을 구현하는 방법: 먼저 [Go 1.4] 이상을 설치한 다음 기존 Go 도구 체인을 사용하여 [Go 1.5] 도구 체인의 기본 버전을 만들고 마지막으로 이를 사용하여 [go_bootstrap]을 빌드합니다. 표준 라이브러리 및 표준 구성 요소.
golang이 부트스트래핑을 구현하는 방식:
自举
(부트스트래핑)은 "컴파일할 대상 프로그래밍 언어로 컴파일러(또는 어셈블러)를 작성"하는 프로세스입니다. 일반적으로 부트스트래핑에는 다음과 같은 여러 가지 장점이 있습니다.
부트스트랩되는 언어를 테스트하기 위한
일반적으로 더 높은 수준이고 더 높은 수준의 추상화를 제공하는 언어로 컴파일러 작성을 지원합니다.
컴파일러의 부트스트래핑은 종종 우리가 만들려는 언어를 컴파일하기 위한 방법을 제공해야 하는 "닭이냐 달걀이냐" 문제로 이어집니다.
Go의 상황은 Go 1.5를 빌드하려면 먼저 Go 1.4 이상을 설치한 다음 기존 Go 도구 체인을 사용하여 Go 1.5 도구 체인의 기본 버전을 만들어야 한다는 것입니다. Go 1.5 툴체인이 컴파일되면(Go 1.4) 이를 사용하여 자체 빌드할 수 있으며, go_bootstrap과 나머지 표준 라이브러리 및 표준 구성 요소를 빌드하는 데 추가로 사용할 수 있습니다. 이 프로세스에는 중간 단계가 추가됩니다. 결과 툴체인은 자체 빌드에 사용되며 향후 Go 버전에 적용할 수 있습니다.
부트스트래핑을 구현하려는 Go의 계획에 대해 자세히 알아보기 위해 InfoQ에서 Russ를 인터뷰했습니다.
부트스트래핑을 달성한 것은 Go 언어의 큰 이정표인 것 같습니다. 언어의 진화 과정에서 왜 이 단계에서 이런 결정을 내리게 됐는지 자세히 설명해주실 수 있나요?
Go는 훌륭한 범용 언어이지만 Google 서버에서 실행되는 것과 같이 대규모 동시성 서버 측 소프트웨어를 작성할 때 사용하도록 설계되었습니다. 부트스트래핑이 더 일찍 구현된다면 Go 컴파일러는 최초의 대규모 Go 언어 프로그램이 될 것입니다. 이는 언어 설계에 부정적인 영향을 미치고 실제 목표에서 멀어지게 할 것입니다.Ken Thompson은 나에게 Go로 프로그램을 작성하는 것이 C를 사용하는 것보다 쉽다고 말한 적이 있습니다. 한 가지 이유는 Go가 매달린 포인터, 메모리 누수, 버퍼 오버플로, 심층 재귀 중 스택 오버플로, void*의 오용 및 예상치 못한 숫자 변환과 같은 몇 가지 일반적인 유형의 C 버그를 제거하기 때문입니다.이식성 등 부트스트래핑을 일찍 구현하지 않는 몇 가지 기술적인 이유도 있으며, 소스 코드에서 컴파일하는 것이 부트스트래핑보다 쉽고, 가능한 한 빨리 안정적인 컴파일러 구현을 가질 수도 있습니다.
Go를 사용하여 Go를 빌드하는 것과 C를 사용하는 것과 비교했을 때 특정 영역에서 어떤 부분이 확실히 개선되었다고 생각하시나요?
Go 프로젝트의 경우 언어의 런타임을 C에서 Go로 변환하는 것이 더 중요했기 때문에 이를 먼저 수행했습니다. 이제 우리는 컴파일러로 돌아왔습니다.표준 Go 툴체인은 표준 C 툴체인보다 모듈성, 단위 테스트 및 성능 분석을 더 잘 지원하지만, 나를 가장 흥분시키는 것은 내부 API를 수정하거나 리팩토링할 때 애플리케이션 자동화 프로세스(gofix와 같은) 작성 가능성입니다.
"Go 1.3+ 컴파일러 점검" 문서에서 기존 컴파일러를 C에서 Go로 마이그레이션하는 5단계 프로세스를 설명합니다. 지금까지 어떤 단계가 완료되었나요? 나머지 단계는 언제 완료될 예정인가요?
문서화 측면에서 현재 2단계에 있습니다. 번역기가 완성되어 런타임을 변환하는 데 도움이 되었습니다. 우리는 이것을 컴파일러에 적용하고 있습니다. Go 1.5 컴파일러로의 전환이 완료되기를 바랍니다. 정리 작업은 Go 1.5 이후 프로젝트에서 수행됩니다.
관련 학습 권장 사항: Go 언어 튜토리얼
위 내용은 golang에서 부트스트래핑을 구현하는 방법은 무엇입니까?의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!