💡 I am going to use Golang to refer to what is known as the Go programming language, simply because it is more search engine friendly.

두 가지 새로운 언어1가 있는데 이들은 강력한 승자로 2010년대Golang와 Rust에 등장했다.Rust는 분명히 개발자 커뮤니티의 새로운 연인이지만, 나는 Golang이 이미 더 많은 상업적 성공을 거두었다고 생각한다.예를 들어 이 시대에 출현한 가장 큰 딱정벌레들은 골랑을 그들의 주요 언어로 사용하고 있다. 코인베이스, 트위치, 우버와 내가 일하는 곳: Tiktok이다.
그런데 왜요?왜 고랑이야?분명히, 고란어는 자신의 의견을 매우 고집하는 언어이다.사람들은 골랑이 한 선택이 모든 사람에게 매력적이지 않다는 것을 인정해야만 했다.몇 가지 문제가 반복적으로 언급되었는데, 그럼에도 불구하고, 나는 여기서 다시 한 번 말하겠다. 왜냐하면 나는 개인적으로 그것들도 받아들이기 어렵다고 생각하기 때문이다.

복제약

범용 지원은 현대 소프트웨어를 구축하는 데 매우 중요하지만, Golang은 곧 발표될 1.18 버전에서만 지원할 계획이다.처음 발표된 지 거의 10년이 지났다.다른 언어가 매개 변수의 다태성을 통해 유사한 기능을 쉽게 제공할 수 있을 때 다음 코드를 작성하는 것을 좋아하는 사람은 없다고 생각합니다.

func MinInt(a, b int) int {
    if a < b {
        return a
    }
    return b
}

func MinInt32(a, b int32) int32 {
    if a < b {
        return a
    }
    return b
}

func MinInt64(a, b int64) int64 {
    if a < b {
        return a
    }
    return b
}

이미지 소스2

오류 처리

나는 예외가 좋은 일이라고 말하지 않을 것이다. 모든 언어에는 예외가 있어야 한다.그 밖에 Option 또는 Maybe 유형도 각자의 장단점이 있어 모든 상황에 적용되지 않을 수 있다.그러나 현재 Golang 커뮤니티는 사용if err != nil에 대한 선택이 상당히 원시적인 것 같다.나는 Golang 커뮤니티가 심지어 새로운 인코딩 스타일"the happy path"을 발명함으로써 오류 처리의 부족함을 보완하려고 시도했다고 생각한다.이것은 아주 좋은 시도이다. 아마도 어느 정도는 의미가 있을 것이다. 그러나 나는 우리가 모든 함수가 호출된 오류 코드를 강제로 검사하지 않기를 바란다.

기본값 또는 선택적 매개 변수 없음

그래서 사람들은 선택할 수 있는 파라미터를 표시하기 위해 바늘을 사용하기 시작했다.나는 이미 보았고 심지어 이런 함수를 많이 썼다고 생각한다.

func doSomething(..., int* mode) {
    if mode == nil {
        mode = 1    
    }
    ...
}

호출자가 전달하지 않는 매개 변수를 선택할 수 있도록 하기 위해서, 이것은 만족스럽지 않습니다. 사용자는 함수에 가변 매개 변수 nil for mode 를 실제 컴파일할 수 있도록 전달해야 하지만, 이것은 SO answer 에 열거된 다른 옵션보다 훨씬 좋습니다. 예를 들어 함수가 가변 매개 변수 interface{} 의 비추거나 특수한 struct 를 받아들일 수 있도록 합니다.

전용 열거 유형이 없습니다

고랑 커뮤니티는 왜 이렇게 하지 않아도 되는지 여러 가지 이유를 다시 한 번 제기할 것이다.그러나 나는 this example'깨끗한'매거를 정의하지 않은 문법 구조의 문제를 완벽하게 정리했다고 생각한다.나는 왜 우리가 2021년에 C 스타일의 비범위 매거를 처리해야 하는지 모르겠다.

오만한 도서관 설계

너는 이 선이 무엇을 하는지 알아맞힐 수 있니?

fmt.Println(t.Format("20060102150405"))

이것은 datetime 대상을 yyyyMMddHHmmss 형식으로 포맷합니다.그런데 이 특수번호는 어떻게 된 거예요?Golang 핵심 팀은 유니버설"2006-01-02T15:04:05Z07:00"보다 시간 형식 지령으로 특정한 시간점"yyyyMMddHHmmss"을 확정한 것 같다.왜?나는 정말 상상할 수 없다.그러나 나는 이런 스타일을 사용하는 데 낭비되는 정력을 과소평가할 수밖에 없다. 이런 스타일은 표준 라이브러리를 통해 많은 프로그래머들에게 강요된 것이다.
이 목록은 계속할 수 있지만, 프로그래밍 언어가 완벽하지 않기 때문에, 나는 여기에 멈추게 한다.나는 네가 Golang이 해결해야 할 진정한 문제가 있다는 것을 알았지만, 그것은 여전히 매우 성공적이라고 생각한다.그런데 왜요?무슨 좋은 점이 있습니까?비록 결함이 있지만, 왜 사람들은 그것을 좋아합니까?

돈.

무시해서는 안 될 요소 중 하나는 수만 억 달러의 회사 지원이 있다는 것이다.나는 지금 전 세계의 인정을 받아야 한다고 생각한다. 모든 언어가 태어날 때부터 평등한 것은 아니다.애플Objective-c/Swift이 있고 구글도 Kotlin과Dart를 지원한다.이 언어들은 모두 어느 정도의 유행성을 가지고 있다.그것들은 가장 좋은 언어입니까?그렇게 지도 모른다, 아마, 아마...그러나 잘 유지되고 발전 잠재력이 있는 언어를 원한다면 상업적 배경이 있는 언어를 선택하겠지?

병발성

누군가는 Golang이 합병에 성공했다고 말할 것이다.그것의 매력은 수천 개의 고로틴을 시작할 수 있고, 모든 고로틴은 한 사용자에게 서비스를 제공하며, 큰 메모리나 CPU 제한을 받지 않기 때문이다.금세기 초에 이 업계는 거대한 도전에 직면했다C10k problem.Golang은 새로운 원시 버전인 Goroutines를 제공함으로써 이런 상황을 교묘하게 벗어났다.

의 부팅 속도가 매우 빨라서 통상적으로 운영체제 레벨 스레드

보다 수량 레벨 빠르다

메모리 흔적이 더 작고 처음에는 4k 스택 크기였지만 필요에 따라 증가

수동 제어가 거의 필요 없다. 사용자는 수동으로 goroutine에 가입할 필요가 없다. goroutine가 작업을 완성할 때 GC는 대부분의 업무를 책임질 것이다.

이러한 옵션은 20세기 10년대 초에 제공되었을 때 다른 옵션보다 훨씬 좋았다. 후자가 어떤 병발성을 얻는 유일한 옵션은 저급 운영체제 라인을 사용하는 것이다. 이것은 여러 연결이 존재할 때 서비스가 큰 메모리를 차지하지 않도록 라인을 실현하도록 할 수 있다.
그러나 Goroutines가 이렇게 특수해서 Golang이 유일한 신축 가능한 언어가 되었는가?아닌 것 같아.최근 몇 년 동안 비동기 프로그래밍의 흥기는 최초로 node.js에 나타났지만 나중에 Python와 C++에 나타났다.점점 더 많은 언어가 로컬에서 협동 프로그램을 통합시켰는데 Goroutine는 그 중의 또 다른 유형에 불과하다. 아래 참조the Golang doc.

Goroutines are part of making concurrency easy to use. The idea, which has been around for a while, is to multiplex independently executing functions—coroutines—onto a set of threads. When a coroutine blocks, such as by calling a blocking system call, the run-time automatically moves other coroutines on the same operating system thread to a different, runnable thread so they won't be blocked. The programmer sees none of this, which is the point. The result, which we call goroutines, can be very cheap: they have little overhead beyond the memory for the stack, which is just a few kilobytes.

To make the stacks small, Go's run-time uses resizable, bounded stacks. A newly minted goroutine is given a few kilobytes, which is almost always enough. When it isn't, the run-time grows (and shrinks) the memory for storing the stack automatically, allowing many goroutines to live in a modest amount of memory. The CPU overhead averages about three cheap instructions per function call. It is practical to create hundreds of thousands of goroutines in the same address space. If goroutines were just threads, system resources would run out at a much smaller number.

따라서 기본적으로 Golang은 이 방면에서 다른 언어보다 한 걸음 앞서고 있다고 생각합니다. 왜냐하면 Golang은 다른 언어가 제공하지 않은 저렴하고 사용하기 쉬운 협동 프로그램 원어를 제공했기 때문입니다.Golang의 Goroutine 구현이 매우 뛰어나고 Goroutine 스케줄러의 작업이 매우 뛰어나다는 것을 부인할 수 없다.나는 이것이 바로 Golang이 대량의 사용자군을 얻은 원인이라고 생각한다. 그들은 특히 네트워크나 분포식 시스템에 대해 코드를 작성하고 발송해야 한다.어쩐지 Golang이 이 분야에서 큰 성공을 거두었더라니 docker, kubernetes와 유사한 클라우드 원생 infra, 그리고 Uber, Twitch 또는 Tiktok와 유사한 온라인 실시간 서비스를 만들었다.
많은 사람들이 일류 채널이나 CSP의 보편적인 사용이 Golang에서 코드를 작성하고 발송하는 것을 더욱 쉽게 만들었다고 생각할 것이다. 나는 동의하지 않는다고 말하지 않을 것이다. 왜냐하면 나는 이런 주장을 반대할 충분한 경험이 없다고 생각하기 때문이다.하지만 나는 그것을 지지한다고 말하지 않을 것이다.두 가지 주요 원인이 있다.

Golang still의 공평한 비트 공유 메모리 통신을 사용하고 있습니다.sync 가방은 어떤 Golang repo에서도 자주 사용되며, 사람들은 Lock나Waitgroup 등 병발 원어를 사용해서 Goroutines를 조율한다.

나 자신에게 있어서 고로틴을 사용할 때 가장 흔히 볼 수 있는 용례는 원격 http/rpc 서비스에서 일부 내용을 얻는 것이기 때문에 채널을 사용하여 고로틴 간의 조율을 할 필요가 없다. 왜냐하면 데이터를 공유하지 않았기 때문이다.보통 우리는 하나의 통로만 사용하면 결과를 얻을 수 있다.그래서 나는 논리를 간소화하기 위해 통로를 사용할 수 있다는 상황을 만난 적이 없다.이런 상황에서 나는 더욱 광범위하게 사용되는 async/await 모델을 자주 놓치게 된다. 이런 모델에서 결과는 일반 함수처럼 goroutine에서 되돌아올 수 있다.

그래서 나는 채널이 모든 것을 더욱 좋아지게 할 수 있다고 믿지 않는다.나는 그것들이 왜 쓸모가 있는지 알지만, 왜 다른 언어로 라이브러리로 실현할 수 없는지 모르겠다.

구축, 성능 및 배포

Golang의 컴파일러 속도가 너무 빨라요.내 로컬 컴퓨터에서 131개의 파일과 26k행 코드를 포함하는 항목을 컴파일하는 데 5초도 걸리지 않는다.비록 나는 자바 프로그래머가 아니지만, 이것은 어떤 C++ 컴파일러보다도 훨씬 좋다™ 사용자: 자바 컴파일러가 같은 성능 수준에 도달할 수 없다는 것은 매우 확실합니다.
언어를 해석하는 것이 어떻냐고 물어볼 것이다. 왜냐하면 그것들은 번역할 필요가 없기 때문이다.그렇지만, 그것들의 운행 시 성능은 훨씬 느리고, 메모리의 점용도 더욱 크다.나는 현실 세계에서 무의미한 또 다른 기준으로 당신들을 짜증나게 하지는 않겠지만, 나의 경험으로 볼 때, Golang은 이곳에서 확실히 우세하다.
Golang은 언어를 설명하는 것보다 또 다른 장점이 있다. 즉, 배치할 때 서버에 바이너리 파일을 보내기만 하면 되고, 여러 의존항을 먼저 설치할 필요가 없다.이것은 매우 간단한 것 같지만, 파이톤 서비스를 docker 용기에 포장하려고 시도하면, 보통 필요한 (큰) 디스크 공간에 놀랄 수 있습니다.

결론

지금 이 순간, 나는 노래에 대해 복잡한 느낌을 가지고 있는데, 한편으로는 그것은 정말 원시적이다.그것을 사용하는 것은 마치 전쟁터에서 칼을 사용하는 것과 같고, 다른 사람들은 이미 레이저총을 사용하고 있다.그러나 이것은 확실히 다른 언어가 현재 제공할 수 없는 것이 있다. 그것은 빠른 컴파일러, 성능이 매우 좋은 협동 프로그램 (특히 그것GMP scheduler에 대한 호출, 활발한 지역 사회와 킬러급 프로그램, 예를 들어 docker와 k8s이다.
최종적으로 큰 문제는 수백만 명의 사용자를 동시에 서비스할 필요가 없는 웹 서비스를 구축하고 있다면 Golang을 선택하겠는가?이 가능하다, ~할 수 있다,...그러나 만약 당신이 큰 회사라면, 당신은 정말 더 적은 메모리와 CPU를 사용하는 데 절약할 돈을 고려해야 합니까?어쩌면, 어쩌면, 골랑이 너를 가치가 있다고 느끼게 할지도 모른다.
기계 학습과 데이터 과학의 흥행으로 이 시대의 가장 성공적인 언어는 파이톤이라고 말할 수도 있다.그러나 파이톤은 30번째 생일을 막 축하한 오래된 언어라는 것을 명심하세요.여기서 우리는 지난 10년 동안의 진정한 새로운 언어를 강조한다.  ↩
Go and generics : ProgrammerHumor   ↩