스마트 프로그래머에게 Go 디자인이 나쁜 이유

지난 몇 달 동안 저는 구현을 위해 Go를 사용해 왔습니다. 개념의 증거 (대략.: 아이디어의 기능을 테스트하기 위한 코드) 여가 시간에는 부분적으로 프로그래밍 언어 자체를 공부합니다. 프로그램 자체는 매우 간단하고 이 기사의 목적은 아니지만 Go 자체를 사용해 본 경험은 이에 대해 몇 마디 언급할 가치가 있습니다. Go는 (대략.: 2015년에 작성된 기사) 심각한 확장 가능한 코드에 널리 사용되는 언어입니다. 이 언어는 Google에서 만들어졌으며 적극적으로 사용됩니다. 결론적으로, 저는 솔직히 Go 언어의 디자인이 똑똑한 프로그래머에게 좋지 않다고 생각합니다.

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

Go는 배우기가 매우 쉬우므로 소개하는 데 어느 날 저녁이 걸렸고 그 후에는 이미 생산적으로 코딩할 수 있었습니다. 내가 바둑을 배우던 책은 Go 프로그래밍 소개 (번역), 온라인으로 구매 가능합니다. 이 책은 Go 소스 코드 자체와 마찬가지로 읽기 쉽고, 좋은 코드 예제가 있으며, 한 번에 읽을 수 있는 약 150페이지가 포함되어 있습니다. 이러한 단순성은 처음에는 신선한 느낌을 줍니다. 특히 지나치게 복잡한 기술로 가득 찬 프로그래밍 세계에서는 더욱 그렇습니다. 그러나 결국에는 조만간 "이게 정말일까? "라는 생각이 떠오릅니다.

Google은 Go의 단순함이 판매 포인트이며 Go 언어는 대규모 팀의 생산성을 극대화하도록 설계되었다고 주장하지만, 나는 그것이 의심스럽습니다. 누락되었거나 지나치게 상세한 기능이 있습니다. 그리고 모든 것은 개발자에 대한 신뢰가 부족하고 그들이 올바른 일을 할 수 없다는 가정 때문입니다. 이러한 단순성에 대한 열망은 언어 디자이너의 의식적인 결정이었고, 그것이 왜 필요한지 완전히 이해하려면 개발자의 동기와 그들이 Go에서 달성하려고 했던 것이 무엇인지 이해해야 합니다.

그렇다면 왜 그렇게 간단하게 만들어졌는가? 다음은 몇 가지 인용문입니다. 롭 파이크 (대략.: Go 언어의 공동 창시자 중 한 명):

여기서 중요한 점은 우리 프로그래머(대략.: Google 직원)는 연구자가 아닙니다. 그들은 일반적으로 아주 어려서 공부를 마치고 우리에게 왔습니다. 아마도 Java, C/C++ 또는 Python을 공부했을 것입니다. 그들은 훌륭한 언어를 이해할 수 없지만 동시에 우리는 그들이 좋은 소프트웨어를 만들기를 원합니다. 그렇기 때문에 그들의 언어는 이해하고 배우기 쉬워야 합니다.
 
그는 대략적으로 C와 비슷할 정도로 친숙할 것입니다. Google에서 일하는 프로그래머는 일찍 경력을 시작하며 대부분 절차적 언어, 특히 C 계열 언어에 익숙합니다. 새로운 프로그래밍 언어의 빠른 생산성에 대한 요구 사항은 언어가 너무 급진적이지 않아야 함을 의미합니다.

무엇? 그래서 Rob Pike는 기본적으로 Google 개발자들이 그다지 좋지 않기 때문에 바보들을 위한 언어를 만들었다고 말하고 있습니다(대략.: dumbed down) 무언가를 할 수 있도록 합니다. 자신의 동료를 어떤 오만한 표정으로 바라보나요? 저는 항상 Google 개발자가 지구상에서 가장 뛰어나고 뛰어난 사람들 중에서 직접 선발되었다고 믿어왔습니다. 확실히 그들은 더 어려운 일을 처리할 수 있을까요?

과도한 단순성의 인공물

단순함은 모든 디자인에서 가치 있는 목표이며, 단순함을 만들려고 노력하는 것은 어렵습니다. 그러나 복잡한 문제를 해결하거나 표현하려고 할 때 때로는 복잡한 도구가 필요합니다. 복잡성과 복잡성은 프로그래밍 언어의 가장 좋은 특징은 아니지만 언어가 이해하고 사용하기 쉬운 우아한 추상화를 만들 수 있는 중간 지점이 있습니다.

표현력이 별로 좋지 않음

단순성에 대한 약속 때문에 Go에는 다른 언어에서 자연스럽게 인식되는 구성이 부족합니다. 이는 처음에는 좋은 생각처럼 보일 수 있지만 실제로는 장황한 코드가 생성됩니다. 그 이유는 분명합니다. 개발자가 다른 사람의 코드를 쉽게 읽을 수 있어야 하지만 실제로 이러한 단순화는 가독성을 해칠 뿐입니다. Go에는 약어가 없습니다. 많거나 전혀 없습니다.

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

package main

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

func main() {

    flag.Parse()
    flags := flag.Args()

    var text string
    var scanner *bufio.Scanner
    var err error

    if len(flags) > 0 {

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

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

        scanner = bufio.NewScanner(file)

    } else {
        scanner = bufio.NewScanner(os.Stdin)
    }

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

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

    fmt.Println(text)
}

이 코드 역시 가능한 한 일반적이도록 노력하고 있지만 Go의 강요된 장황함이 방해가 되고 결과적으로 간단한 문제를 해결하면 많은 양의 코드가 생성됩니다.

예를 들어 다음은 동일한 문제에 대한 해결책입니다. 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);
    }
}

이제 누가 더 읽기 쉬워졌나요? 나는 D에게 투표하겠습니다. 그의 코드는 그가 작업을 더 명확하게 설명하기 때문에 훨씬 더 읽기 쉽습니다. D는 훨씬 더 복잡한 개념을 사용합니다(대략.: 대체 함수 호출 и 템플릿) Go 예제에서보다 이해하기가 어렵지만 실제로는 복잡한 것이 없습니다.

복사의 지옥

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 int16Sum(list []int16) (uint64) {
    var result int16 = 0
    for x := 0; x < len(list); x++ {
        result += list[x]
    }
    return uint64(result)
}

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

func main() {

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

    fmt.Println(int8Sum(list8))
    fmt.Println(int16Sum(list16))
    fmt.Println(int32Sum(list32))
    fmt.Println(int64Sum(list64))
}

그리고 이 예는 서명된 유형에도 작동하지 않습니다. 이 접근 방식은 반복하지 않는다는 원칙을 완전히 위반합니다(DRY)는 가장 유명하고 분명한 원칙 중 하나이며 많은 오류의 원인을 무시합니다. Go는 왜 이런 일을 하는가? 이것은 언어의 끔찍한 측면입니다.

D에 대한 동일한 예:

import std.stdio;
import std.algorithm;

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

단순하고 우아하며 요점이 명확합니다. 여기서 사용되는 함수는 reduce 템플릿 유형 및 조건자에 대한 것입니다. 예, 이것은 Go 버전보다 더 복잡하지만 똑똑한 프로그래머가 이해하기 그렇게 어렵지는 않습니다. 어떤 예가 유지 관리하기 쉽고 읽기 더 쉽습니까?

단순형 시스템 바이패스

나는 이 글을 읽는 Go 프로그래머들이 입에 거품을 물고 “당신은 잘못하고 있어요!”라고 비명을 지르게 될 것이라고 상상합니다. 글쎄, 일반 함수와 유형을 만드는 또 다른 방법이 있지만 이는 유형 시스템을 완전히 깨뜨립니다!

문제를 해결하기 위해 어리석은 언어 수정의 예를 살펴보십시오.

package main

import "fmt"
import "reflect"

func Reduce(in interface{}, memo interface{}, fn func(interface{}, interface{}) interface{}) interface{} {
    val := reflect.ValueOf(in)

    for i := 0; i < val.Len(); i++ {
        memo = fn(val.Index(i).Interface(), memo)
    }

    return memo
}

func main() {

    list := []int{1, 2, 3, 4, 5}

    result := Reduce(list, 0, func(val interface{}, memo interface{}) interface{} {
        return memo.(int) + val.(int)
    })

    fmt.Println(result)
}

이 구현 Reduce 기사에서 빌려왔습니다 Go의 관용적 제네릭 (대략.: 번역을 찾을 수 없습니다. 도움을 주시면 감사하겠습니다.) 글쎄, 그것이 관용적이라면 관용적이지 않은 예를 보는 것이 싫습니다. 용법 interface{} - 희극이며 언어에서는 타이핑을 우회하는 데만 필요합니다. 이는 빈 인터페이스이며 모든 유형이 이를 구현하므로 모든 사람에게 완전한 자유가 허용됩니다. 이런 프로그래밍 스타일은 정말 추악하지만 그게 다가 아닙니다. 이와 같은 곡예적인 업적을 위해서는 런타임 리플렉션을 사용해야 합니다. Rob Pike조차도 그의 보고서 중 하나에서 언급했듯이 이를 남용하는 개인을 좋아하지 않습니다.

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

나는 이런 말도 안되는 소리 대신 D 템플릿을 사용하겠습니다. 누가 그런 말을 할 수 있겠어? interface{} 더 읽기 쉽고 심지어 유형이 안전합니까?

종속성 관리의 문제점

Go에는 인기 있는 호스팅 제공업체를 기반으로 구축된 종속성 시스템이 내장되어 있습니다. VCS. Go와 함께 제공되는 도구는 이러한 서비스에 대해 알고 있으며 해당 서비스에서 코드를 한 번에 다운로드, 빌드 및 설치할 수 있습니다. 이것은 훌륭하지만 버전 관리에는 큰 결함이 있습니다! 예, Go 도구를 사용하여 github 또는 bitbucket과 같은 서비스에서 소스 코드를 얻을 수 있지만 버전을 지정할 수는 없습니다. 그리고 유용성을 희생하면서 다시 단순함을 추구합니다. 나는 그러한 결정의 논리를 이해할 수 없습니다.

이 문제에 대한 해결책에 대해 질문한 후 Go 개발팀은 포럼 스레드, 이 문제를 해결하는 방법을 설명했습니다. 그들의 권장 사항은 어느 날 전체 저장소를 프로젝트에 복사하고 "그대로" 두는 것이었습니다. 도대체 그들은 무슨 생각을 하고 있는 걸까요? 우리는 Go 제작자가 무시하고 소스 코드만 복사하는 훌륭한 태그 지정 및 버전 지원을 갖춘 놀라운 버전 제어 시스템을 보유하고 있습니다.

시진핑의 문화수하물

제 생각에는 Go는 평생 C를 사용해 온 사람들과 새로운 것을 시도하고 싶지 않은 사람들이 개발한 것 같습니다. 언어는 추가 휠이 있는 C로 설명될 수 있습니다(원본.: 훈련 바퀴). 병렬 처리에 대한 지원(그런데 훌륭합니다)을 제외하고는 새로운 아이디어가 없으며 이는 부끄러운 일입니다. 당신은 거의 사용할 수 없는 형편없는 언어로 뛰어난 병렬성을 갖고 있습니다.

또 다른 삐걱거리는 문제는 Go가 절차적 언어(C의 조용한 공포와 같은)라는 것입니다. 결국 구식이고 시대에 뒤떨어진 느낌이 드는 절차적 스타일로 코드를 작성하게 됩니다. 객체지향 프로그래밍이 만병통치약은 아니라는 건 알지만 세부사항을 유형으로 추상화하고 캡슐화를 제공할 수 있다면 좋을 것입니다.

자신의 이익을 위한 단순성

Go는 단순하게 설계되었으며 그 목표를 성공적으로 달성했습니다. 이는 오래된 언어를 템플릿으로 사용하여 약한 프로그래머를 위해 작성되었습니다. 간단한 작업을 수행할 수 있는 간단한 도구가 함께 제공됩니다. 읽기 쉽고 사용하기 쉽습니다.

이는 매우 장황하고 인상적이지 않으며 똑똑한 프로그래머에게는 좋지 않습니다.

감사 메르신발드 편집을 위해

출처 : habr.com