go 언어의 단점: 1. 기술적 경로 선택으로 인한 "성능 단점" Go는 성능이 매우 민감한 일부 상황에서는 Go를 선택할 때 여전히 주의해야 합니다. 2. "단일 표현 방법"과 명시적인 오류 처리는 약간 "구식"입니다. 3. 가장 작은 버전은 주류에서 벗어난 MVS를 선택합니다. 4. Go 핵심 팀은 언어의 발전을 완전히 제어합니다. Go 언어에 채택되어 추가되면 Go 커뮤니티와 Go 핵심 팀 사이에 "균열"이 발생합니다. 5. 약한 기능
이 튜토리얼의 운영 환경: Windows 7 시스템, GO 버전 1.18, Dell G3. 컴퓨터
모든 프로그래밍 언어에는 고유한 장점과 단점이 있으며 Go도 예외는 아닙니다. Go의 장점:
Go의 장점
1. 배우기 쉬움
Go 언어는 C 언어와 유사한 구문을 포함하는 간단한 구문을 가지고 있습니다. 새로운 개발자라도 며칠 만에 Go 언어를 배울 수 있습니다.
2. 자유롭고 효율적입니다.
Go 언어의 컴파일 속도는 Java 및 C++이며 C 언어에 가까운 운영 효율성과 PHP에 가까운 개발 효율성을 갖추고 있습니다. Go 언어는 운영 효율성과 개발 효율성을 완벽하게 통합한다고 할 수 있습니다.
동시에 Go 언어도 현재 모든 것을 지원합니다. 절차적 프로그래밍, 객체지향 프로그래밍, 인터페이스 지향 프로그래밍, 함수형 프로그래밍을 포함한 프로그래밍 패러다임을 개발자는 필요에 따라 자유롭게 결합할 수 있습니다.
3. 강력한 표준 라이브러리
Go의 표준 라이브러리는 매우 안정적이고 다양합니다. 네트워크, 시스템, 암호화, 인코딩, 그래픽 및 기타 측면, 특히 네트워크 및 시스템 라이브러리를 포함하여 개발자가 대규모 프로그램을 개발할 때 타사 라이브러리에 거의 의존할 수 없습니다.
4. 가상 머신을 사용해야 하는 경우 Go 언어 코드는 바이너리 실행 파일로 직접 출력될 수 있으며 Go 언어에는 자체 링커가 있으며 시스템에서 제공하는 컴파일러나 링커에 의존하지 않습니다. 따라서 컴파일된 바이너리입니다.
5. 기본 동시성 지원
Go 언어는 언어 계층에서 기본적으로 동시성을 지원하며 사용이 매우 간단합니다. 고루틴은 스레드와 유사하지만 Go 언어의 스레딩을 위한 경량 방법입니다. 고루틴을 만드는 데 드는 비용은 몇 천 바이트에 불과합니다.
보통은 그렇습니다. 수백 개의 스레드를 실행하면 데스크톱 호스트가 오버로드되지만 동일한 호스트는 수천 또는 수만 개의 Goroutine을 실행할 수 있습니다. 고루틴 및 채널 기반 동시성 방법을 사용하면 CPU 리소스 사용을 극대화할 수 있습니다. 6. 강력한 안정성
Go 언어는 강력한 컴파일 검사, 엄격한 코딩 표준 및 강력한 안정성을 갖추고 있습니다. 또한 Go 언어는 소프트웨어 수명 주기(예: 개발, 테스트, 배포, 유지 관리 등)의 각 측면에 대한 도구도 제공합니다. ), 예: 도구 이동, fmt 이동, 테스트 이동 등
7. 가비지 컬렉션
Go 언어를 사용하여 개발할 때 개발자는 메모리 적용에만 주의하면 되며 Go 언어에는 자동 관리를 위한 런타임이 내장되어 있기 때문에 메모리 해제에 대해 걱정할 필요가 없습니다. GC(Garbage Collection, 가비지 수집 메커니즘)는 현재 완벽하지는 않지만 개발 중에 직면하는 대부분의 상황에 충분히 대처할 수 있으므로 개발자가 비즈니스에 더 집중할 수 있습니다. 동시에 Go 언어를 사용하면 개발자도 이 작업을 수행할 수 있습니다. 최적화되었습니다.
Go의 단점
1. 기술적인 경로 선택으로 인한 "성능 단점"우리 모두 알고 있듯이 Go는 가비지 컬렉션이 포함된 프로그래밍 언어이므로 Go의 STW(Stop The World) 시간은 GC 지연이 너무 작아서 여전히 GC 클래스 프로그래밍 언어에 속하며 Java 및 C#과 같은 진영에 속합니다. 동시에 자연스럽게 프로그래밍 언어와 분리됩니다. 메모리를 수동으로 관리하고 런타임 GC 부담이 없는 C, C++ 및 Rust로 라인을 지웠습니다. Go 언어의 원래 의도는 시스템 수준 프로그래밍 언어가 되는 것이지만 Go의 런타임 성능은 99.99%의 경우 요구 사항을 충족할 수 있지만 Baidu의 수조 개의 트래픽[포워딩 엔진 BFE], 시계열 데이터베이스[influxdb], 분산 관계형 데이터베이스(TiDB) 및 기타 성능에 민감한 프로젝트는 Go를 구현하기로 선택했지만 성능에 매우 민감한 일부 상황에서는 여전히 Go를 선택할 때 주의해야 한다는 점을 부인할 수 없습니다.
2 자신의 디자인 철학을 고수함으로써 발생하는 "표현 단점"
1) "단일" 표현 방법
다른 언어에서 Go 캠프로 전환한 많은 개발자들은 Go의 트릭이 너무 적고, 루틴 없음 많은, Go가 "표현 단점"을 보이는 이유는 "글을 작성하는 방법이 하나 또는 몇 가지 밖에 없다는 것을 옹호한다"는 디자인 철학의 원칙에서 비롯됩니다. 이 원칙은 일부 개발자들이 자신의 실력을 과시하려는 심리적 요구를 충족시키지 못하기 때문에 Go는 평범한 자격을 갖춘 프로그래머들만이 사용하는 언어라는 비판을 받습니다.
[Go 1.18에서는 이러한 "단점"에 대한 "보상"으로 간주될 수 있는 제네릭(유형 매개변수)이 추가됩니다. 그러나 오랫동안 Go의 가치와 디자인 철학을 인식해 온 우리 Gophers에게는 Go의 표현력을 크게 향상시킨 [generics]가 트릭과 트릭의 "온상"이 되지 않을까 매우 걱정됩니다.
2) "오래된" 명시적 오류 처리
Go 언어는 탄생 이후 C++, Java, Python과 같은 주류 프로그래밍 언어와 같은 예외를 기반으로 하는 구조화된 try-catch-finally 오류 처리를 제공하지 않았습니다. 메커니즘, Go 디자이너는 [예외를 프로그램 제어 구조에 결합하면 코드 혼란이 발생할 수 있습니다]라고 믿습니다. Go는 모든 Go 개발자가 각 오류에 명시적으로 주의를 기울이고 처리하도록 "강제"하는 오류 값 비교를 기반으로 하는 간단한 오류 처리 메커니즘을 제공합니다. 암호. 그러나 이러한 디자인 철학의 지속성은 다른 언어의 많은 개발자들에 의해 "낡았다"고 조롱되었으며 "반세기 전의 고대 메커니즘"이라고 불렸습니다. (저자 주: 1970년대 C 언어가 탄생했을 때 사용했던 오류 처리 메커니즘)
Go 개발팀도 [Go 오류 처리 새 버전]을 여러 버전으로 출시했습니다. Go2 계획]. 바둑 커뮤니티에서도 이 문제에 대해 오랫동안 토론하고 심지어 "다툼"을 벌였습니다. 유명한 Gopher Dave Cheney가 발언했고 Rob Pike가 발언했으며 유명한 Go 트레이너이자 " Go 언어 실전 전투 " Go 팀의 시도 제안이 발표된 후 Go 커뮤니티에 시도 계획에 반대하는 공개 서한을 게시했습니다. 결국 Go 디자인 철학을 주장하는 그룹이 우위를 점하게 되었고, 시도 제안은 거부되어 [Go 1.13 버전]에 포함되지 않았습니다!
3. 주류에서 벗어난 "틈새 단점"
Go의 초기 패키지 종속성 관리 메커니즘 설계에는 Google 내부의 대규모 단일 코드 웨어하우스 및 트렁크 기반 개발 모델의 영향으로 인해 꽤 많은 "결함"이 있습니다. . Google 외부의 Go 언어는 다양한 측면에서 목소리를 들었습니다. Go 패키지 관리 메커니즘은 오랫동안 커뮤니티의 요구를 충족할 수 없었습니다. 결과적으로 [vendor 메커니즘] 및 [dep]과 같은 패키지 종속성 관리를 개선하려는 시도가 있었습니다.
2018년 초, 대부분의 Gophers가 dep가 공식 Go 툴 체인의 일부로 "자연스럽게" 업그레이드될 것이라고 생각했을 때 Go 코어 팀의 기술 리더이자 Go의 초기 멤버 중 한 명인 Russ Cox가 있었습니다. 자신의 개인 블로그에 게시된 핵심 팀 그는 Go 모듈의 전신인 "패키지 종속성 관리"에 대한 Go 팀의 기술 솔루션을 체계적으로 정교하게 설명하는 [7개의 기사]를 연속으로 게시했습니다.
vgo의 주요 아이디어는 다음과 같습니다: 주류 프로그래밍 언어의 현재 패키지 종속성 관리 규칙에 위배되는 의미 체계 가져오기 버전 관리 및 최소 버전 선택, 특히 새로운 접근 방식으로 간주되는 [MVS(최소 버전 선택)] 주류에서!
4. Go 코어 팀의 "민주적 중앙집권주의"로 인한 "커뮤니티 불이익"
은 Go 코어 팀의 "언어 기능 증가"를 위한 커뮤니티 제안의 광범위한 채택과 다릅니다. 언어 진화에 대한 태도 완전한 통제를 통해 커뮤니티의 대다수가 동의하지 않는 한 반드시 Go 언어에 채택되어 추가될 것입니다. 저는 농담으로 이를 "민주적 중앙집권제"라고 부릅니다. 즉, 실제 투표권은 실제로 소수에게 있습니다. Go 핵심 팀에서 커뮤니티를 대표하는 사람들.
2018년 초 dep와 vgo 사이의 분쟁은 이러한 "불이익"의 전형적인 표현입니다. 커뮤니티가 1년 넘게 구축하기 위해 열심히 노력한 dep 프로젝트는 vgo에 의해 "압축"되었으며, 이는 Russ Cox와 이를 설계하는 데 시간을 투자한 다른 몇몇 사람들이 디자인했습니다. 패키지 종속성 관리 도구 표준은 Go 모듈의 성공을 위한 "디딤돌"이 되었습니다. Go 팀의 Go 모듈 사용 결정이 옳다고 밝혀지더라도 이로 인해 Go 커뮤니티와 Go 코어 팀 사이에 "갈등"이 존재하므로 지난 2년간 Go 코어 팀은 Go 커뮤니티와의 관계를 개선하고 Go 제안을 제안하고 검토하고 수락하는 과정을 표준화하고 투명하게 하기가 어렵습니다.
5. 종합공격 실패 후, 기대실패로 인한 '기능적 약점'
Go 1.5 출시 이후 부트스트래핑 및 GC 지연이 대폭 감소하여 2009년까지 Go가 점차 주목을 받았습니다. 두 번째로 TIOBE 올해의 최고의 프로그래밍 언어상을 수상함으로써 Go 언어는 다소 "부풀려졌습니다." 뿐만 아니라 엔터프라이즈급 Java 시장도 점령해야 합니다. 터미널(android.ios)과 프런트엔드(js)에서도 기존 경쟁자를 물리쳐야 합니다.
어떤 분들은 제 위의 말이 우스꽝스럽다고 생각하실 수도 있지만 근거가 없는 것은 아닙니다. Go 언어는 터미널과 프런트엔드 측면에서 정말 큰 성과를 거두었습니다. Go의 역사를 아는 사람이라면 Go 팀에 Go 기술 구축을 목표로 하는 [gomobile 프로젝트]()에 전담 개발자가 참여한 적이 있다는 것을 알고 있습니다. Go 언어로 터미널 애플리케이션을 작성하는 목적을 달성하기 위해 [gopherjs 프로젝트]는 Go 코드를 js 코드로 컴파일하고 나중에 주요 브라우저에서 실행할 수 있습니다. gopherjs는 go 프로젝트가 기본적으로 웹 어셈블리를 지원하도록 도왔습니다. 웹 어셈블리로의 컴파일과 브라우저에서의 실행을 지원합니다
.그러나 위의 시도는 결국 "원하는 것을 얻는 것"에 실패했습니다. 현재 상황은 터미널 및 프론트엔드 애플리케이션 분야에서 Go 코딩을 사용하는 사람이 거의 없다는 것입니다. 그래서 Go는 점차 진정되어 자신이 잘하던 주전장으로 돌아가 엔터프라이즈급 애플리케이션, 인프라, 미들웨어, 마이크로서비스, 명령줄 애플리케이션 등의 분야로 복귀했고, 점점 더 많은 개발자들의 호감을 얻었습니다. 이 필드.
그러나 전면적인 공격이 실패하면서 많은 개발자들은 "Go의 기능이 약하다"는 핑계를 댔습니다. 심지어 어떤 사람들은 [나의 아버지 구글]이 Go의 백도어를 만들도록 내버려둘 수 없었다고 말하기도 합니다.
【관련 추천: Go 비디오 튜토리얼, 프로그래밍 교육】
위 내용은 Go 언어의 단점은 무엇입니까?의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!