이 기사는 이전에 게시된 글에 대한 답변으로 작성되었습니다. 대척지 기사.

지난 XNUMX년 넘게 저는 Go를 사용하여 개발된 청구 시스템을 갖춘 특수 RADIUS 서버를 구현해 왔습니다. 그 과정에서 나는 언어 자체의 복잡성을 배우고 있습니다. 프로그램 자체는 매우 간단하며 이 기사의 목적은 아니지만 Go 자체를 사용한 경험은 이를 옹호하는 데 몇 마디 말할만한 가치가 있습니다. Go는 심각하고 확장 가능한 코드를 위한 점점 더 주류 언어가 되어가고 있습니다. 이 언어는 Google에서 만들어졌으며 적극적으로 사용됩니다. 결론적으로 저는 솔직히 Go 언어의 디자인이 UNintelligent 프로그래머에게 좋지 않다고 생각합니다.

약한 프로그래머를 위해 설계 되었습니까?

약한 사람은 문제를 말합니다. 아이디어와 꿈에 대한 강렬한 이야기..

Go는 배우기가 매우 쉬우므로 실제로 전혀 교육을 받지 않고도 코드를 읽을 수 있습니다. 이 언어 기능은 많은 글로벌 기업에서 비핵심 전문가(관리자, 고객 등)와 함께 코드를 읽을 때 사용됩니다. 이는 디자인 중심 개발과 같은 방법론에 매우 편리합니다.
초보 프로그래머라도 XNUMX~XNUMX주 후에는 꽤 괜찮은 코드를 생성하기 시작합니다. 제가 공부한 책은 "Go 프로그래밍"(마크 서머필드 지음)입니다. 이 책은 매우 훌륭하며 언어의 많은 뉘앙스를 다룹니다. Java, PHP 등 불필요하게 복잡한 언어에 이어 마법의 부족함이 상쾌합니다. 그러나 조만간 많은 제한된 프로그래머들은 새로운 분야에서 오래된 방법을 사용하려는 아이디어를 갖게 됩니다. 이것이 정말로 필요한가?

언어의 주요 사상가인 Rob Pike는 Go 언어를 이해하기 쉽고 사용하기 효과적인 산업 언어로 만들었습니다. 이 언어는 대규모 팀의 생산성을 극대화하도록 설계되었으며 이에 대해서는 의심의 여지가 없습니다. 많은 초보 프로그래머들은 누락된 기능이 많다고 불평합니다. 단순성에 대한 이러한 열망은 언어 디자이너의 의식적인 결정이었고, 그것이 왜 필요한지 완전히 이해하려면 개발자의 동기와 그들이 Go에서 달성하려고 했던 것이 무엇인지 이해해야 합니다.

그렇다면 왜 그렇게 간단하게 만들어졌는가? 다음은 Rob Pike의 몇 가지 인용문입니다.

여기서 중요한 점은 우리 프로그래머는 연구자가 아니라는 점입니다. 그들은 일반적으로 아주 어려서 공부를 마치고 우리에게 왔습니다. 아마도 Java, C/C++ 또는 Python을 공부했을 것입니다. 그들은 훌륭한 언어를 이해할 수 없지만 동시에 우리는 그들이 좋은 소프트웨어를 만들기를 원합니다. 그렇기 때문에 언어는 이해하기 쉽고 배우기 쉬워야 합니다.

그는 대략적으로 C와 비슷할 정도로 친숙할 것입니다. Google에서 일하는 프로그래머는 일찍 경력을 시작하며 대부분 절차적 언어, 특히 C 계열 언어에 익숙합니다. 새로운 프로그래밍 언어의 빠른 생산성에 대한 요구 사항은 언어가 너무 급진적이지 않아야 함을 의미합니다.

현명한 말이지, 그렇지?

단순함의 유물

단순함은 아름다움의 필수 조건입니다. 레프 톨스토이.

단순함을 유지하는 것은 모든 디자인에서 가장 중요한 목표 중 하나입니다. 아시다시피 완벽한 프로젝트는 추가할 것이 없는 프로젝트가 아니라 제거할 것이 없는 프로젝트입니다. 많은 사람들은 복잡한 문제를 해결(또는 표현)하려면 복잡한 도구가 필요하다고 믿습니다. 그러나 그렇지 않습니다. PERL 언어를 예로 들어보겠습니다. 언어 이데올로기는 프로그래머가 하나의 문제를 해결하려면 적어도 세 가지 다른 방법을 가지고 있어야 한다고 믿었습니다. Go 언어의 이데올로기는 다른 길을 택했습니다. 그들은 한 가지 방법이지만 정말 좋은 방법이면 목표를 달성하기에 충분하다고 결정했습니다. 이 접근 방식에는 심각한 기반이 있습니다. 유일한 방법은 배우기 쉽고 잊어버리기는 어렵습니다.

많은 이민자들은 언어에 우아한 추상화가 포함되어 있지 않다고 불평합니다. 예, 이것은 사실입니다. 그러나 이것이 언어의 주요 장점 중 하나입니다. 언어에는 최소한의 마법이 포함되어 있으므로 프로그램을 읽는 데 깊은 지식이 필요하지 않습니다. 코드의 장황함에 관해서는 이것은 전혀 문제가 되지 않습니다. 잘 작성된 Golang 프로그램은 구조가 거의 또는 전혀 없이 세로로 읽힙니다. 또한 프로그램을 읽는 속도는 적어도 작성 속도보다 훨씬 빠릅니다. 모든 코드가 균일한 형식(내장 gofmt 명령을 사용하여 수행됨)을 가지고 있다고 생각하면 몇 줄을 추가로 읽는 것은 전혀 문제가 되지 않습니다.

표현력이 별로 좋지 않음

예술은 자유가 제한되는 것을 용납하지 않습니다. 정확성은 그의 책임이 아닙니다.

단순성에 대한 욕구로 인해 Go에는 다른 언어에 익숙한 사람들이 자연스러운 것으로 인식하는 구성이 부족합니다. 처음에는 다소 불편할 수도 있지만 나중에는 프로그램이 읽기가 훨씬 쉽고 명확하다는 것을 알게 됩니다.

예를 들어 명령줄 인수에서 stdin 또는 파일을 읽는 콘솔 유틸리티는 다음과 같습니다.

package main

import (
    "bufio"
    "flag"
    "fmt"
    "log"
    "os"
)

func main() {

    flag.Parse()

    scanner := newScanner(flag.Args())

    var text string
    for scanner.Scan() {
        text += scanner.Text()
    }

    if err := scanner.Err(); err != nil {
        log.Fatal(err)
    }

    fmt.Println(text)
}

func newScanner(flags []string) *bufio.Scanner {
    if len(flags) == 0 {
        return bufio.NewScanner(os.Stdin)
    }

    file, err := os.Open(flags[0])

    if err != nil {
        log.Fatal(err)
    }

    return bufio.NewScanner(file)
}

D의 동일한 문제에 대한 해결책은 다소 짧아 보이지만 읽기가 쉽지 않습니다.

import std.stdio, std.array, std.conv;

void main(string[] args)
{
    try
    {
        auto source = args.length > 1 ? File(args[1], "r") : stdin;
        auto text   = source.byLine.join.to!(string);

        writeln(text);
    }
    catch (Exception ex)
    {
        writeln(ex.msg);
    }
}

복사의 지옥

인간은 자신 안에 지옥을 가지고 있습니다. 마틴 루터.

초보자들은 제네릭이 부족하다는 점에서 Go에 대해 끊임없이 불평합니다. 이 문제를 해결하기 위해 대부분은 직접 코드 복사를 사용합니다. 예를 들어, 정수 목록을 합산하는 함수는 각 데이터 유형에 대해 간단한 복사-붙여넣기 외에 다른 방법으로는 이 기능을 구현할 수 없다고 예비 전문가들이 믿고 있습니다.

package main

import "fmt"

func int64Sum(list []int64) (uint64) {
    var result int64 = 0
    for x := 0; x < len(list); x++ {
        result += list[x]
    }
    return uint64(result)
}

func int32Sum(list []int32) (uint64) {
    var result int32 = 0
    for x := 0; x < len(list); x++ {
        result += list[x]
    }
    return uint64(result)
}

func main() {

    list32 := []int32{1, 2, 3, 4, 5}
    list64 := []int64{1, 2, 3, 4, 5}

    fmt.Println(int32Sum(list32))
    fmt.Println(int64Sum(list64))
}

언어에는 그러한 구성을 구현하는 데 충분한 수단이 있습니다. 예를 들어 일반 프로그래밍은 괜찮습니다.

package main

import "fmt"

func Eval32(list []int32, fn func(a, b int32)int32) int32 {
    var res int32
    for _, val := range list {
        res = fn(res, val)
    }
    return res
}

func int32Add(a, b int32) int32 {
    return a + b
}

func int32Sub(a, b int32) int32 {
    return a + b
}

func Eval64(list []int64, fn func(a, b int64)int64) int64 {
    var res int64
    for _, val := range list {
        res = fn(res, val)
    }
    return res
}

func int64Add(a, b int64) int64 {
    return a + b
}

func int64Sub(a, b int64) int64 {
    return a - b
}

func main() {

    list32 := []int32{1, 2, 3, 4, 5}
    list64 := []int64{1, 2, 3, 4, 5}

    fmt.Println(Eval32(list32, int32Add))
    fmt.Println(Eval64(list64, int64Add))
    fmt.Println(Eval64(list64, int64Sub))
}

그리고 우리의 코드는 이전 사례에 비해 다소 길어졌지만 일반화되었습니다. 따라서 모든 산술 연산을 구현하는 것이 어렵지 않습니다.

많은 사람들이 D 프로그램이 훨씬 더 짧아 보인다고 말할 것이며, 그 말이 옳을 것입니다.

import std.stdio;
import std.algorithm;

void main(string[] args)
{
    [1, 2, 3, 4, 5].reduce!((a, b) => a + b).writeln;
}

그러나 D 구현은 오류 처리 문제를 완전히 무시하므로 더 짧을 뿐 더 정확하지는 않습니다.

실제 생활에서는 논리의 복잡성이 증가할수록 그 격차가 급격히 좁아집니다. 표준 언어 연산자를 사용하여 수행할 수 없는 작업을 수행해야 하는 경우 격차가 더욱 빠르게 줄어듭니다.

유지보수성, 확장성, 가독성 측면에서 보면 Go 언어가 비록 장황함에서는 떨어지지만 승리한다고 생각합니다.

어떤 경우에는 일반화된 프로그래밍이 우리에게 부인할 수 없는 이점을 제공합니다. 이는 sort 패키지에 명확하게 설명되어 있습니다. 따라서 목록을 정렬하려면 sort.Interface 인터페이스를 구현하면 됩니다.

import "sort"

type Names []string

func (ns Names) Len() int {
    return len(ns)
}

func (ns Names) Less(i, j int) bool {
    return ns[i] < ns[j]
}

func (ns Names) Swap(i, j int) {
    ns[i], ns[j] = ns[j], ns[i]
}

func main() {
    names := Names{"London", "Berlin", "Rim"}
    sort.Sort(names)
}

오픈 소스 프로젝트를 선택하고 grep "interface{}" -R 명령을 실행하면 혼란스러운 인터페이스가 얼마나 자주 사용되는지 알 수 있습니다. 마음이 가까운 동지들은 이 모든 것이 제네릭이 부족하기 때문이라고 즉시 말할 것입니다. 그러나 항상 그런 것은 아닙니다. DELPHI를 예로 들어보겠습니다. 이러한 동일한 제네릭이 있음에도 불구하고 임의의 데이터 유형을 사용하는 작업을 위한 특수 VARIANT 유형이 포함되어 있습니다. Go 언어도 마찬가지입니다.

참새 총에서

그리고 구속복은 광기의 크기에 맞아야합니다. 스타니슬라프 레크.

많은 극단적인 팬들은 Go에 제네릭을 생성하는 또 다른 메커니즘인 리플렉션이 있다고 주장할 수 있습니다. 그리고 그들의 말이 옳을 것입니다... 하지만 아주 드문 경우일 뿐입니다.

Rob Pike는 우리에게 이렇게 경고합니다.

이는 주의해서 사용해야 하는 강력한 도구입니다. 꼭 필요한 경우가 아니면 피해야 합니다.

Wikipedia는 다음과 같이 알려줍니다.

리플렉션은 프로그램이 실행 중에 자체 구조와 동작을 모니터링하고 수정할 수 있는 프로세스를 나타냅니다. 반사의 기본 프로그래밍 패러다임을 반사 프로그래밍이라고 합니다. 이것은 일종의 메타프로그래밍입니다.

그러나 아시다시피 모든 비용은 귀하가 지불해야 합니다. 이 경우는 다음과 같습니다.

• 프로그램 작성의 어려움
• 프로그램 실행 속도

따라서 반사는 대구경 무기처럼 주의해서 사용해야 합니다. 리플렉션을 무분별하게 사용하면 프로그램을 읽을 수 없고 지속적인 오류가 발생하며 속도가 느려집니다. 속물 프로그래머가 좀 더 실용적이고 겸손한 다른 동료들 앞에서 자신의 코드를 과시할 수 있는 것입니다.

시진핑의 문화적 수하물? 아니요, 다양한 언어로 제공됩니다!

재산과 함께 빚도 상속인에게 남습니다.

많은 사람들이 언어가 전적으로 C 유산에 기반을 두고 있다고 믿고 있지만 사실은 그렇지 않습니다. 이 언어는 최고의 프로그래밍 언어의 여러 측면을 통합합니다.

구문

우선, 문법 구조의 구문은 C 언어의 구문을 기반으로 합니다. 그러나 DELPHI 언어도 상당한 영향을 미쳤습니다. 따라서 프로그램의 가독성을 크게 저하시키는 중복된 괄호가 완전히 제거되었음을 알 수 있습니다. 이 언어에는 DELPHI 언어 고유의 ":=" 연산자도 포함되어 있습니다. 패키지의 개념은 ADA와 같은 언어에서 차용되었습니다. 사용되지 않은 엔터티의 선언은 PROLOG 언어에서 차용되었습니다.

의미론

패키지는 DELPHI 언어의 의미를 기반으로 했습니다. 각 패키지는 데이터와 코드를 캡슐화하고 개인 및 공용 엔터티를 포함합니다. 이를 통해 패키지 인터페이스를 최소한으로 줄일 수 있습니다.

위임 방식에 따른 구현 작업은 DELPHI 언어를 차용했습니다.

편집

농담이 있는 것은 당연합니다. Go는 C 프로그램이 컴파일되는 동안 개발되었습니다. 이 언어의 강점 중 하나는 초고속 컴파일입니다. 아이디어는 DELPHI 언어에서 차용되었습니다. 각 Go 패키지는 DELPHI 모듈에 해당합니다. 이러한 패키지는 실제로 필요한 경우에만 다시 컴파일됩니다. 따라서 다음 편집 후에는 전체 프로그램을 컴파일할 필요가 없으며 변경된 패키지와 이러한 변경된 패키지에 의존하는 패키지만 다시 컴파일해야 합니다(이 경우에도 패키지 인터페이스가 변경된 경우에만).

상위 수준 구성

이 언어에는 C와 같은 저수준 언어와 전혀 관련이 없는 다양한 고급 구조가 포함되어 있습니다.

• 라인
• 해시 테이블
• 조각
• 덕 타이핑은 RUBY(불행히도 많은 사람들이 그 잠재력을 최대한 이해하지 못하거나 사용하지 않음)와 같은 언어에서 차용되었습니다.

메모리 관리

메모리 관리는 일반적으로 별도의 기사가 필요합니다. C++와 같은 언어에서는 제어가 전적으로 개발자에게 맡겨져 있지만 DELPHI와 같은 이후 언어에서는 참조 계산 모델이 사용되었습니다. 이 접근 방식을 사용하면 고아 클러스터가 형성되었기 때문에 순환 참조가 허용되지 않으며 Go에는 이러한 클러스터(예: C#)에 대한 감지 기능이 내장되어 있습니다. 또한 가비지 수집기는 현재 알려진 대부분의 구현보다 더 효율적이며 이미 많은 실시간 작업에 사용될 수 있습니다. 언어 자체는 변수를 저장할 값이 스택에 할당될 수 있는 상황을 인식합니다. 이렇게 하면 메모리 관리자의 로드가 줄어들고 프로그램 속도가 향상됩니다.

동시성과 동시성

언어의 병렬성과 경쟁력은 칭찬할 수 없습니다. 저수준 언어는 Go와 원격으로 경쟁할 수도 없습니다. 공평하게 말하면, 이 모델은 언어 작성자가 발명한 것이 아니라 단순히 오래된 ADA 언어에서 차용했다는 점에 주목할 가치가 있습니다. 이 언어는 모든 CPU를 사용하여 수백만 개의 병렬 연결을 처리할 수 있으며 다중 스레드 코드에서 일반적으로 발생하는 교착 상태 및 경쟁 조건과 관련된 문제를 훨씬 덜 복잡하게 처리할 수 있습니다.

추가 혜택

이익이 된다면 모두가 이타적이 될 것입니다.

언어는 또한 우리에게 다음과 같은 의심할 여지 없는 이점을 제공합니다.

• 프로젝트를 빌드한 후 단일 실행 파일을 사용하면 애플리케이션 배포가 크게 단순화됩니다.
• 정적 유형 지정 및 유형 추론을 사용하면 테스트를 작성하지 않고도 코드의 오류 수를 크게 줄일 수 있습니다. 나는 테스트를 전혀 작성하지 않고 코드 품질을 크게 저하시키지 않는 일부 프로그래머를 알고 있습니다.
• 매우 간단한 크로스 컴파일과 표준 라이브러리의 뛰어난 이식성을 통해 크로스 플랫폼 애플리케이션 개발을 크게 단순화합니다.
• RE2 정규식은 스레드로부터 안전하며 실행 시간을 예측할 수 있습니다.
• 대부분의 프로젝트를 타사 프레임워크 없이 수행할 수 있게 해주는 강력한 표준 라이브러리입니다.
• 언어는 문제를 해결하는 방법보다는 문제에 집중할 만큼 강력하지만, 문제를 효율적으로 해결할 수 있을 만큼 낮은 수준입니다.
• Go 에코 시스템에는 테스트, 문서화, 패키지 관리, 강력한 린터, 코드 생성, 경쟁 조건 감지기 등 모든 상황에 맞게 개발된 도구가 이미 포함되어 있습니다.
• Go 버전 1.11에는 널리 사용되는 VCS 호스팅을 기반으로 구축된 의미론적 종속성 관리 기능이 내장되어 있습니다. Go 생태계를 구성하는 모든 도구는 이러한 서비스를 사용하여 코드를 한 번에 다운로드, 빌드 및 설치합니다. 정말 훌륭해요. 버전 1.11이 출시되면서 패키지 버전 관리 문제도 완전히 해결되었습니다.
• 언어의 핵심 아이디어는 마술을 줄이는 것이기 때문에 언어는 개발자가 명시적으로 오류 처리를 수행하도록 장려합니다. 그리고 이것은 정확합니다. 그렇지 않으면 단순히 오류 처리를 완전히 잊어버릴 것이기 때문입니다. 또 다른 점은 대부분의 개발자가 의도적으로 오류 처리를 무시하고 단순히 오류를 위로 전달하는 방식을 선호한다는 것입니다.
• 언어는 순수한 형태의 Go에는 가상이 없기 때문에 고전적인 OOP 방법론을 구현하지 않습니다. 그러나 인터페이스를 사용하는 경우 이는 문제가 되지 않습니다. OOP가 없기 때문에 초보자의 진입 장벽이 크게 줄어듭니다.

지역사회 이익을 위한 단순성

복잡하기는 쉽고 단순화하기는 어렵습니다.

Go는 단순하게 설계되었으며 그 목표를 성공적으로 달성했습니다. 팀워크의 이점을 이해하고 엔터프라이즈 수준 언어의 끝없는 가변성에 지친 똑똑한 프로그래머를 위해 작성되었습니다. 무기고에 상대적으로 작은 구문 구조 세트가 있으므로 시간이 지나도 실제로 변경되지 않으므로 개발자는 언어 혁신을 끝없이 연구하는 것이 아니라 개발에 많은 시간을 할애할 수 있습니다.

기업은 또한 여러 가지 이점을 얻습니다. 진입 장벽이 낮아 전문가를 빠르게 찾을 수 있고, 언어의 불변성으로 인해 10년 후에도 동일한 코드를 사용할 수 있습니다.

결론

뇌가 크다고 해서 어떤 코끼리도 노벨상 수상자가 된 적은 없습니다.

개인 자존심이 팀 정신보다 우선하는 프로그래머들과 학문적 도전과 끝없는 "자기 개선"을 좋아하는 이론가들에게 이 언어는 정말 나쁩니다. 작업 결과에서 미적 즐거움을 얻고 동료들 앞에서 자신의 전문성을 보여주세요(IQ가 아닌 이러한 기준으로 지능을 측정하는 경우). 인생의 모든 것과 마찬가지로, 그것은 개인적인 우선순위의 문제입니다. 모든 가치 있는 혁신과 마찬가지로 언어도 이미 보편적 거부에서 대중 수용에 이르기까지 먼 길을 걸어왔습니다. 언어는 단순함이 독창적이며, 아시다시피 모든 독창적인 것은 간단합니다!

출처 : habr.com