Go 디자인 철학: 적을수록 좋다, 그것은 어디에서 왔는가?-Golang-php.cn

전에 Go 커뮤니티에서 지식과 경험을 공유할 때, less is more, less is more, the road to simple, the road to simple 등과 같은 속어를 자주 들었습니다.

Go 문제와 제안을 논의할 때에도 어떤 사람들은 "less is more"라는 말을 사용하여 주장을 반박하거나 지지하는데, 이는 매우 흥미롭습니다. 모두가 매우 궁금해할 것입니다. 이 단어는 어디에서 왔으며 무엇을 의미합니까?

황금문의 출처

이러한 뿌리깊은 공동체 문화 개념은 핵심 인물에 의해 제안되었을 것입니다. 그는 다음 문장을 말한 저자입니다:

누구든지 알아볼 수 있나요?

바둑 언어의 아버지, 롭 파이크(Rob Pike)입니다.

Rob Pike는 "적은 것이 더 많다"라는 문구를 여러 차례 언급했으며 이는 널리 유포되었습니다.

다음과 같은 경우에 공유하세요:

2012년 Go SF 컨퍼런스에서 "Less is exponentially more^[1]"이 공유되었으며, 이는 대중 의견을 모아 편집한 최초의 기사였습니다. .
2015년 dotGo 컨퍼런스에서 공유된 내용은 "Simplicity is Complicated^[2]"으로 계속해서 문화를 주입하고 의견을 나누었습니다.

이 관점의 다양한 변형이 업계에 널리 유포되어 Go 커뮤니티에서 독특한 "문화"를 형성합니다.

물론 커뮤니티 반응을 보면 칭찬도 있고 비판도 있습니다.

음성 내용

다음은 Rob Pike의 "Less is exponentially more^[3]"의 인용문입니다. 텍스트 부분은@MIKESPOOK^[4] 번역입니다. 재정렬하고 다듬고 인용하겠습니다. , 사진을 통해 바퀴를 재발 명하지 않고 명확하게 설명하겠습니다.

아래와 같이:

Background

이 내용은 2012년 6월 샌프란시스코에서 열린 바둑 컨퍼런스에서 제(롭 파이크)가 강연한 내용입니다.

이것은 비공개 연설입니다. 저는 Go 프로젝트 팀의 어느 누구를 대신하여 말하는 것이 아니지만, Go를 가능하게 하기 위해 그들이 한 모든 일에 대해 팀에게 감사의 말씀을 전하고 싶습니다.

동시에 이런 연설 기회를 주신 San Francisco Go 커뮤니티에도 감사의 말씀을 전하고 싶습니다.

Go에서 가장 놀라운 점은 무엇입니까

몇 주 전에 "Go를 시작한 이후로 가장 놀랐던 점은 무엇입니까?"라는 질문을 받았습니다.

저는 즉시 답변을 받았습니다. 하지만 C++ 프로그래머가 Go를 이해하기를 바랍니다. 대체 언어로 사용되지만 Python과 Ruby를 사용하는 Go 프로그래머가 더 많고 C++를 사용하는 프로그래머는 소수에 불과합니다.

우리(켄, 로버트, 나)는 원래 C++ 프로그래머였으며 우리가 작성한 소프트웨어의 문제를 해결하기 위해 새로운 언어를 설계했습니다.

그리고 다른 C++ 프로그래머들은 이러한 문제에 별로 관심을 두지 않는 것 같은데, 이는 약간 모순되는 것 같습니다.

우리가 Go를 개발한 이유

오늘은 우리가 Go를 만들게 된 계기와, 그래서는 안 됐는데 왜 놀랐는지에 대해 이야기하고 싶습니다.

저는 C++보다 Go에 대해 더 많이 논의할 것을 약속합니다. C++을 모르더라도 주제를 완벽하게 따라갈 수 있습니다.

답은 다음과 같이 요약할 수 있습니다. 적을수록 좋다거나 적을수록 적다고 생각하시나요?

The Story of Bell Labs

여기에 은유로서의 실화가 있습니다.

Bell Labs는 원래 물리 연구용 111, 컴퓨터 과학 연구용 127 등 세 가지 숫자로 식별되었습니다.
1980년대 초, 우리가 알고 있던 연구가 성장하고 있기 때문에 우리 작업을 쉽게 식별하려면 숫자를 하나 더 추가해야 한다는 메모가 예정대로 도착했습니다. 그래서 우리 센터는 1127이 됩니다.
론 하딘은 농담 반 진담으로 우리가 정말로 세상을 더 잘 이해한다면 세상을 한 자릿수 줄여 127을 27로 만들 수 있다고 말했습니다.

물론 경영진이 농담을 듣지 않았거나 듣고 싶지 않았을 수도 있지만 거기에는 큰 지혜가 있다고 생각합니다. 적을수록 좋습니다. 더 잘 이해할수록 더 암시적입니다.

이 아이디어를 기억해주세요.

Go 개발 배경

C++ 컴파일 대기

2007년 9월, 저는 거대한 Google C++ 프로그램(여러분 모두가 사용했던) 핵심 작업에 대해 사소하지만 중요한 작업을 하고 있었습니다.

대규모 분산 클러스터를 컴파일하는 데 약 45분이 걸렸습니다.

C++ 새로운 기능 개선

C++ 표준화 위원회에 근무하는 Google 직원 여러 명이 보고서를 제출할 것이라는 알림을 받았습니다.

그들은 당시 C++0x(현재는 C++11로 알려짐)라고 불린 기능에 어떤 개선 사항이 있는지 알려줄 것입니다.

1시간 동안 진행된 프레젠테이션 동안 우리는 이미 35가지 기능이 계획되어 있다는 이야기를 들었습니다.

사실 더 많은 기능이 있지만 보고서에는 35개 기능만 설명되어 있습니다. 물론 일부 기능은 작지만 보고서에서 언급할 가치가 있을 만큼 중요합니다.

다음과 같이 매우 미묘하고 이해하기 어려운 부분도 있습니다.

rvalue 참조.
가변 템플릿
사용자 정의 리터럴.

이 때 나는 다음과 같은 질문을 했습니다. C++ 위원회는 실제로 C++의 문제점은 충분한 기능이 없다는 것이라고 생각합니다 ?

확실히, 또 다른 Ron Hardin 농담에서는

언어를 단순화하는 것이 기능을 추가하는 것보다 더 많은 것을 성취합니다 물론 이것은 약간 우스꽝스럽지만 이 아이디어를 명심하십시오

성적인 언어 실험

몇 달만요. 이 C++ 강연에 앞서 제가 1980년대에 개발한 장난감 동시성 언어에 대해 직접 강연한 적이 있습니다. 이 언어는 Go의 전신입니다. Newsqueak에서 누락된 몇 가지 아이디어 때문에 Google에 근무하면서 다시 생각하게 되었습니다. 서버측 코드 작성이 쉬워지고 Google이 그 혜택을 누릴 수 있게 되었습니다.

사실 저는 이러한 아이디어를

C++로 구현하려고 했지만, 실패

C++ 제어 구조를 동시 작업에 연결하는 것이 너무 어려웠습니다. 결국 실제 이점을 보기가 어려웠습니다.

저는 C++를 잘 사용하지 못했다는 것을 인정하지만 순수 C++로 인해 여전히 모든 것이 너무 투박해 보입니다.

그런데 그 C++0x 보고서는 나를 다시 생각하게 만들었습니다. 나를 정말로 괴롭히는 한 가지는 (그리고 Ken과 Robert도 확실히 귀찮게 할 것입니다) 새로운 C++ 메모리 모델에 원자 유형이 있다는 것입니다.

이미 과부하된 유형 시스템에 이렇게 미세한 설명 세부 정보 모음을 추가하는 것은 절대 실수처럼 느껴집니다. 이것은 또한 근시안적이다. 향후 10년 안에 하드웨어가 급속히 발전할 것이라는 점은 거의 확실하다. 언어를 오늘날의 하드웨어와 너무 밀접하게 묶는 것은 매우 어리석은 일이다.

초기팀 이동

발표회를 마치고 사무실로 돌아왔습니다. 나는 또 다른 편집을 시작하고 의자를 로버트 쪽으로 돌리고 핵심 문제에 대해 소통하기 시작했습니다.

편집이 끝나기 전에 우리는 Ken을 데려와 무엇을 할지 결정했습니다.

우리는 C++ 작성을 계속하지 않을 것이며 특히 저는 Google 코드를 작성할 때 동시성을 쉽게 작성할 수 있기를 원합니다.

동시에 우리는 나중에 이야기할 "빅 프로그래밍"을 제어하기 위해 앞으로 나아가고 싶습니다.

특집토론하러가기

화이트보드에 우리가 원하는 것들과 필요한 조건들을 잔뜩 적어두었습니다. 구문적, 의미적 세부 사항은 무시되고 청사진과 큰 그림이 구상됩니다.

그때 받은 흥미로운 이메일이 아직도 남아있습니다.

다음은 발췌 내용입니다.

Robert: 시작점은 C입니다. 몇 가지 명백한 결함을 수정하고, 어수선한 부분을 제거하고, 누락된 기능을 추가합니다.
Rob: 이름이 'go'입니다. 이름의 유래를 만들 수 있지만 기초가 좋습니다. 짧고 쓰기 쉽습니다. 도구: goc, gol, goa. 대화형 디버거/인터프리터가 있는 경우 "go"라고 부르세요. 확장자는 .go입니다.
Robert: 빈 인터페이스는 인터페이스{}입니다. 모든 인터페이스를 구현하므로 void * 대신 사용할 수 있습니다.

모든 것을 정확하게 표현하지 못했습니다. 예를 들어 배열과 슬라이스를 매핑하는 데 거의 1년이 걸렸습니다. 그러나 언어의 중요한 기능 대부분은 처음 며칠 만에 결정되었습니다.

Robert는 C++가 아니라 C가 출발점이라고 말했습니다. 잘 모르겠지만, 특히 Ken이 주변에 있다면 C를 의미한다고 생각합니다.

하지만 사실 우리는 결국 C에서 시작하지 않았습니다. 우리는 처음부터 연산자, 괄호, 중괄호 및 일부 키워드만 빌려서 시작했습니다. (물론 우리가 아는 다른 언어에서도 최선을 다합니다.)

어쨌든, 우리는 이제 C++와 반대되는 작업을 수행하고 있습니다. 모든 것을 해체하고 원점으로 돌아가 다시 시작합니다. 우리는 더 나은 C++나 더 나은 C를 설계하려는 것이 아닙니다. 우리가 관심을 갖는 소프트웨어 유형에 대한 더 나은 언어입니다.

결국 C와 C++과는 완전히 다른 언어가 되었습니다. 각 릴리스는 점점 더 다양해지고 있습니다.

Go 기능 목록

Go에서 C 및 C++에 대한 중요한 단순화 목록을 만들었습니다.

표준 구문(파싱에 기호 테이블이 필요하지 않음).
쓰레기 수집(전용).
헤더 파일이 없습니다.
명시적 종속성
순환 종속성이 없습니다.
상수는 숫자만 가능합니다.
int와 int32는 다른 유형입니다.
레터 케이스 설정 가시성.
모든 유형에는 메서드가 있을 수 있습니다(클래스 없음).
하위 유형 상속이 없습니다(하위 클래스화 없음).
패키지 수준 초기화 및 정의된 초기화 순서.
파일이 패키지로 컴파일됩니다.
패키지 수준 전역 표현식은 순서와 무관합니다.
산술 변환이 없습니다(상수는 보조 처리됩니다).
암시적 인터페이스 구현("구현" 정의가 필요하지 않음).
임베디드(상위 클래스로 업그레이드할 수 없음).
메서드는 함수처럼 정의됩니다(특별한 위치 요구 사항 없음).
메서드는 함수입니다.
인터페이스에는 메서드만 포함됩니다(데이터 없음).
메서드는 이름으로만 일치합니다(유형으로는 일치하지 않음).
시공,파괴 방법이 없습니다.
사후 증가 및 사후 감소는 표현식이 아니라 명령문입니다.
사전 증가나 사전 감소가 없습니다.
과제는 표현식이 아닙니다.
할당 및 함수 호출이 정의된 순서대로 실행합니다("시퀀스 포인트" 없음).
포인터 연산이 없습니다.
메모리는 항상 0 값으로 초기화됩니다.
지역 변수의 주소를 가져오는 것이 합법적입니다.
메소드에는 "this"가 없습니다.
분할된 스택.
정적 또는 기타 유형 주석이 없습니다.
템플릿이 없습니다.
특별한 것은 없습니다.
문자열, 슬라이스, 맵이 내장되어 있습니다.
배열 경계 확인.

이 단순화된 목록과 언급되지 않은 몇 가지 퀴즈 외에도 저는 Go가 C나 C++보다 표현력이 더 뛰어나다고 믿습니다. 적을수록 좋습니다.

그래도 모든 것을 버릴 수는 없습니다. 유형이 작동하는 방식을 구조화하고, 실제로 적절한 구문을 갖고, 라이브러리 상호 작용을 더 좋게 만드는 말로 표현할 수 없는 일을 만들 필요가 여전히 있습니다.

슬라이스 및 맵, 복합 선언, 파일당 최상위 표현식(거의 잊어버린 중요 사항), 리플렉션, 가비지 수집 등 C 또는 C++에서 사용할 수 없는 몇 가지 기능도 추가했습니다. 물론 동시성도 있습니다.

제네릭이 없다는 것은 상상할 수 없습니다.

물론 분명히 빠진 것은 유형 계층 구조입니다. 이에 대해 몇 가지 더러운 말을 하도록 허락해 주십시오.

Go의 원래 버전에서 누군가 제네릭 없이 언어로 작업하는 것을 상상할 수 없다고 말했습니다. 이전에 어딘가에서 언급했듯이 이것은 정말 마법 같은 리뷰라고 생각합니다.

공정하게 말하자면, 그는 아마도 STL이 C++에서 제공한 기능이 얼마나 마음에 드는지 자신만의 방식으로 표현하고 있었을 것입니다. 토론을 위해 그에게 의심의 이익을 주자.

int 리스트나 맵 문자열 같은 컨테이너를 작성하는 것은 참을 수 없는 부담이라고 하더군요. 나는 이것이 놀라운 점이라고 생각한다.

제네릭이 없는 언어에서도 저는 이러한 문제에 거의 시간을 할애하지 않습니다.

객체 지향 접근

하지만 더 중요한 것은 이러한 부담을 덜어주는 솔루션이 타입이라고 말했습니다. 유형. 기능적 다형성도 아니고, 언어 기초도 아니고, 다른 지원도 아니고, 단지 유형일 뿐입니다.

이것이 나를 사로잡은 디테일이다.

C++ 및 Java에서 Go로 전환하는 프로그래머는 유형 작업, 특히 상속 및 서브클래싱 및 이에 수반되는 모든 작업의 프로그래밍 스타일을 그리워합니다. 제가 장르에 관해서는 문외한일지도 모르지만, 이 모델이 표현력이 뛰어나다는 것을 본 적이 없습니다.

나의 고인이 된 친구 Alain Fournier는 장학금의 가장 낮은 형태가 분류라고 믿었다고 말한 적이 있습니다. 그럼 그거 알아? 유형 계층 구조는 분류입니다.

A가 B에서 상속되는지, B가 A에서 상속하는지 여부 등 각 유형의 상위 항목을 포함하여 어떤 조각이 어떤 상자에 들어갈지 결정해야 합니다.

정렬 가능한 배열은 정렬된 배열인가요, 아니면 배열로 표현되는 정렬기인가요? 모든 문제가 유형 중심 설계라고 믿는다면 결정을 내려야 합니다.

저는 이런 식으로 프로그래밍을 생각하는 것이 우스꽝스럽다고 생각합니다. 핵심은 사물 간의 조상 관계가 아니라 사물이 당신을 위해 무엇을 할 수 있는지입니다.

물론, 인터페이스가 Go에 등장하는 곳입니다. 그러나 그것들은 이미 진정한 Go 철학인 청사진의 일부입니다.

C++과 Java가 유형 상속과 유형 분류에 관한 것이라면 Go는 구성에 관한 것입니다.

Unix 파이프의 최종 발명자인 Doug McIlroy는 1964년에 다음과 같이 썼습니다(!).

우리는 어떻게든 정원 수도꼭지와 호스처럼 메시지 데이터를 하나씩 연결해야 합니다. 이는 IO에서도 사용되는 방법입니다.

이것도 Go에서 사용하는 방식입니다. Go는 이 아이디어를 한 단계 더 발전시켰습니다. 결합과 연결에 관한 언어이다.

분명한 예는 인터페이스가 구성 요소 결합을 제공하는 방식입니다. 메소드 M만 구현하면 무엇인지 상관하지 않고 적절한 위치에 배치할 수 있습니다.

또 다른 중요한 예는 동시성이 독립적으로 실행되는 계산을 연결하는 방법입니다. 그리고 특이한(그러나 매우 간단한) 유형 구성 패턴도 있습니다. 바로 임베딩입니다.

이것은 C++이나 Java 프로그램과는 전혀 다른 Go만의 독특한 조합 기술입니다.

C++/Java의 대규모 프로그래밍 패턴

제가 언급하고 싶은 Go와 관련 없는 디자인이 있습니다. Go는 대규모 팀이 작성하고 유지 관리하는 대규모 프로그램을 작성하는 데 도움을 주기 위해 설계되었습니다.

"빅 프로그래밍"이라는 관점이 있는데 왠지 C++와 Java가 이 분야를 지배하고 있습니다. 나는 이것이 단지 역사적 실수이거나 산업재해라고 생각한다. 그러나 객체지향 디자인이 뭔가를 할 수 있다는 믿음은 널리 받아들여지고 있습니다.

저는 그런 말을 전혀 믿지 않습니다. 대형 소프트웨어에는 방법론의 보호가 필요하지만 강력한 종속성 관리와 명확한 인터페이스 추상화 또는 멋진 문서화 도구는 필요하지 않지만 강력한 종속성 관리, 명확한 인터페이스 추상화 및 우수한 문서화 도구보다 더 중요하지는 않습니다. , 그리고 이들 중 어느 것도 C++가 잘하는 것은 아닙니다(물론 Java가 더 잘하지만).

Go로 작성된 소프트웨어가 충분하지 않기 때문에 아직은 알 수 없지만, Go가 큰 프로그래밍 세계에서 두각을 나타낼 것이라고 확신합니다. 시간이 모든 것을 증명합니다.

C++ 프로그래머가 Go를 좋아하지 않는 이유

이제 제가 강연 시작 부분에서 언급한 놀라운 질문으로 돌아가겠습니다.

C++를 파괴하도록 설계된 언어인 Go는 왜 존재합니까? C++ 프로그래머의 마음을 얻지 못하셨나요?

농담은 제쳐두고 Go와 C++의 철학이 완전히 다르기 때문이라고 생각합니다.

C++를 사용하면 모든 문제를 손끝에서 해결할 수 있습니다.

C++11 FAQ에서 다음 내용을 인용했습니다.

C++는 특별히 작성된 손으로 작성한 코드의 엄청난 성장보다 더 넓은 범위의 추상화, 우아함, 유연성 및 무료 표현 기능을 제공합니다.

이런 생각의 방향은 바둑과는 다릅니다. 제로 비용은 목표가 아니며 적어도 CPU 비용이 제로는 아닙니다. Go의 제안은 프로그래머의 작업량을 최소화하는 것입니다.

Go는 모든 것을 포괄하는 것은 아닙니다. 모든 것을 내장할 수는 없습니다. 실행의 모든 세부 사항을 정확하게 제어할 수는 없습니다. 예를 들어 RAII가 없습니다. 대신 가비지 콜렉션을 사용할 수 있습니다. 메모리 해제 기능도 없습니다.

당신이 얻는 것은 강력하지만 이해하기 쉽고 문제 해결을 위해 연결하고 결합하는 데 사용되는 일부 모듈을 구축하는 데 사용하기 쉽습니다.

다른 언어로 작성된 솔루션만큼 빠르고, 세련되고, 이념적으로 명확하지 않을 수 있지만 확실히 작성하기 쉽고, 읽기 쉽고, 이해하기 쉽고, 유지 관리하기 쉽고, 안전합니다.

즉, 약간 너무 단순하다는 뜻입니다.

Python 및 Ruby 프로그래머: 표현력을 많이 포기하지 않고 성능을 얻고 동시성과 함께 춤을 추기 때문에 Go로 이동하세요.
C++ 프로그래머: 언어에 대한 정확한 제어권을 얻기 위해 열심히 싸웠고, 얻은 어떤 것도 포기하고 싶지 않기 때문에 Go로 이동할 수 없습니다. 그들에게 소프트웨어는 단순히 작업을 완료하는 것이 아니라 특정 방식으로 작업을 완료하는 것입니다.

그래서 질문은, 바둑의 성공이 그들의 세계관을 반증하는가 하는 것입니다. 우리는 처음부터 뭔가를 깨달아야 합니다.

C++11의 새로운 기능에 흥미를 느끼는 사람들은 기능이 그렇게 많지 않은 언어에는 관심이 없을 것입니다. 비록 언어가 그들이 상상했던 것보다 더 많은 것을 제공한다는 것이 밝혀졌다고 해도 말입니다.

모두들 감사합니다.