Rust는 어떤 면에서는 굉장합니다. 그러나 빠르게 움직여야 하는 스타트업을 선택하기 전에 두 번 고려하세요.

나는 프로그래밍 언어에 대한 성전을 시작하거나 시작하고 싶지 않기 때문에 이 글을 쓰는 것을 주저했습니다. (불길한 미끼를 없애기 위해 Visual Basic은 최고의 언어입니다!) 그러나 많은 사람들이 Rust에 대한 나의 경험과 프로젝트에 Rust를 선택해야 하는지 여부를 묻습니다. 그래서 저는 빠르게 움직이고 팀을 확장하는 것이 정말 중요한 스타트업 환경에서 Rust를 사용하는 것에 대해 제가 본 장단점을 공유하고 싶습니다.

나는 특정한 것에 대해 Rust의 팬임을 분명히 하고 싶습니다 . 이 게시물은 Rust가 언어로서 얼마나 나쁜지에 대한 것이 아닙니다. 그러나 내가 말하고 싶은 것은 Rust를 사용하는 것이 당신이 빨리 움직이려고 한다면 주요 요인이 될 수 있는 사소하지 않은 생산성 타격을 거의 확실하게 수반할 것이라는 점입니다. 속도 영향이 회사 및 제품에 대한 언어의 이점만큼 가치가 있는지 신중하게 평가하십시오.

바로 앞에, Rust는 설계된 일에 매우 뛰어나며 프로젝트에 Rust의 특정 이점(고성능, 초강력 타이핑, 가비지 수집이 필요 없는 시스템 언어 등)이 필요한 경우에 말해야 합니다. 그런 다음 Rust는 훌륭한 선택입니다. 그러나 저는 Rust가 그다지 적합하지 않은 상황에서 자주 사용되며 팀은 많은 이점을 얻지 못한 채 Rust의 복잡성과 오버헤드의 대가를 지불한다고 생각합니다.

Rust에 대한 나의 주된 경험은 이전 스타트업에서 2년 조금 넘게 일하면서 얻은 것입니다. 이 프로젝트는 클라우드 기반 SaaS 제품으로, 거의 기존의 CRUD 앱에 불과했습니다. 데이터베이스 앞에 REST 및 gRPC API 엔드포인트를 제공하는 마이크로서비스 집합과 기타 일부 백-서비스입니다. 최종 마이크로서비스(자체는 Rust와 Python의 조합으로 구현됨). Rust는 주로 회사 창립자 두 명이 Rust 전문가였기 때문에 사용되었습니다. 시간이 지나면서 우리는 팀을 상당히 성장시켰고(엔지니어링 인원을 거의 10배 늘림) 코드베이스의 크기와 복잡성도 상당히 커졌습니다.

팀과 코드베이스가 성장함에 따라 시간이 지남에 따라 Rust를 계속 사용하는 데 점점 더 많은 세금을 내고 있다고 느꼈습니다. 때때로 개발이 느렸고, 새로운 기능을 출시하는 데 예상보다 오래 걸렸으며, 팀은 Rust를 사용하기로 한 초기 결정으로 인해 실질적인 생산성 저하를 느꼈습니다. 다른 언어로 코드를 다시 작성하면 장기적으로 개발이 훨씬 더 민첩해지고 전달 시간이 빨라지지만 주요 재작성 작업을 위한 시간을 찾는 것은 매우 어려웠을 것입니다. 그래서 우리는 총알을 깨물고 많은 양의 코드를 다시 작성하기로 결정하지 않는 한 Rust에 갇혀 있었습니다.

녹은 얇게 썬 빵 이후로 가장 좋은 것으로 여겨졌는데 왜 우리에게는 잘 작동하지 않았습니까?

Rust는 엄청난 학습 곡선을 가지고 있습니다.

나는 내 경력에서 수십 개의 언어로 작업했으며 거의 ​​예외 없이 대부분의 현대적이고 절차적인 언어(C++, Go, Python, Java 등)는 모두 기본 개념 측면에서 매우 유사합니다. 각 언어에는 차이점이 있지만 일반적으로 언어마다 다른 몇 가지 주요 패턴을 학습한 다음 매우 빠르게 생산적일 수 있습니다.그러나 Rust를 사용하려면 배워야 합니다.완전히 새로운 아이디어— 수명, 소유권 및 차용 검사기와 같은 것. 이는 다른 공통 언어로 작업하는 대부분의 사람들에게 친숙한 개념이 아니며 숙련된 프로그래머에게도 상당히 가파른 학습 곡선이 있습니다.

이러한 "새로운" 아이디어 중 일부는 물론 다른 언어, 특히 기능적인 언어에 존재하지만 Rust는 이러한 아이디어를 "주류" 언어 설정으로 가져오므로 많은 Rust 초보자에게 생소할 것입니다.

내가 함께 일했던 가장 똑똑하고 경험이 많은 개발자였음에도 불구하고 팀의 많은 사람들(나 자신 포함)은 Rust에서 특정 작업을 수행하는 정식 방법, 컴파일러에서 종종 난해한 오류 메시지를 파악하는 방법 또는 핵심 라이브러리가 작동하는 방식을 이해하는 방법(자세한 내용은 아래 참조). 우리는 팀이 지식과 ​​전문 지식을 공유하는 데 도움이 되도록 매주 "Rust 학습" 세션을 갖기 시작했습니다. 모두가 느린 개발 속도를 느꼈기 때문에 이것은 모두 팀의 생산성과 사기를 크게 떨어뜨렸습니다.

소프트웨어 팀에서 새로운 언어를 채택하는 것이 어떤 것인지 비교하기 위해 Google의 한 팀은 C++에서 Go로 완전히 전환한 최초의 팀 중 하나였습니다. 15명 정도의 팀이 처음으로 Go로 꽤 편안하게 코딩했습니다. Rust를 사용하면 매일 몇 달 동안 언어로 작업한 후에도 팀의 대부분의 사람들이 완전히 유능하다고 느끼지 못했습니다. 많은 개발자들이 자신의 기능이 착륙하는 데 예상보다 오래 걸리고 Rust를 이해하는 데 너무 오랜 시간을 소비하고 있다는 사실에 종종 당혹스럽다고 말했습니다.

Rust가 해결하려는 문제를 해결하는 다른 방법이 있습니다.

위에서 언급했듯이 우리가 구축한 서비스는 상당히 간단한 CRUD 앱이었습니다. 이 서비스에 대한 예상 부하는 이 특정 시스템의 수명 동안 최대 초당 몇 개의 쿼리를 넘지 않을 것입니다. 이 서비스는 실행하는 데 많은 시간이 걸릴 수 있는 상당히 정교한 데이터 처리 파이프라인의 프런트엔드였으므로 서비스 자체가 성능 병목 현상이 될 것으로 예상되지 않았습니다. Python과 같은 기존 언어가 좋은 성능을 제공하는 데 문제가 있을 것이라는 특별한 우려는 없었습니다. 웹 대면 서비스가 처리해야 하는 것 외에 특별한 안전이나 동시성 요구 사항은 없었습니다. 우리가 Rust를 사용한 유일한 이유는 시스템의 원래 작성자가 Rust 전문가였기 때문이지 이런 종류의 서비스를 구축하는 데 특히 적합했기 때문이 아닙니다.

Rust는 개발자 생산성보다 안전이 더 중요하다는 결정을 내렸습니다. 이것은 OS 커널에서 코드를 작성하거나 메모리가 제한된 임베디드 시스템과 같은 많은 상황에서 올바른 절충안이지만 모든 경우에 올바른 절충안이라고 생각하지 않습니다. 특히 속도가 중요한 스타트업에서는 그렇지 않습니다. 나는 실용주의자입니다. 팀의 모든 구성원이 이러한 문제를 완전히 방지하도록 설계된 언어를 사용하여 생산성이 4배 저하되는 것보다 팀에서 가끔 발생하는 메모리 누수 또는 Python 또는 Go로 작성된 코드의 유형 오류를 디버깅하는 데 시간을 할애하는 편이 낫 습니다 . .

위에서 언급했듯이 Google 팀은 전적으로 Go로 서비스를 구축했으며 시간이 지남에 따라 8억 명 이상의 사용자와 Google 검색 QPS의 4배 정도를 지원하는 수준으로 성장했습니다. 이 서비스를 구축하고 실행하는 동안 Go의 유형 시스템이나 가비지 컬렉터로 인해 발생한 문제에 부딪힌 횟수는 한 손으로 셀 수 있습니다. 기본적으로 Rust가 피하도록 설계된 문제는 좋은 테스트, 좋은 린팅, 좋은 코드 검토, 좋은 모니터링 등 다른 방법으로 해결할 수 있습니다. 물론 모든 소프트웨어 프로젝트가 이러한 사치를 누리는 것은 아니므로 다른 상황에서는 Rust가 좋은 선택이 될 수 있다고 상상할 수 있습니다.

Rust 개발자를 고용하는 데 어려움을 겪을 것입니다.

우리는 이 회사에 있는 동안 수많은 사람들을 고용했지만 엔지니어링 팀에 합류한 60명 이상의 사람들 중 약 2~3명만이 Rust에 대한 이전 경험이 있었습니다. 이것은 Rust 개발자를 찾기 위한 노력이 부족해서가 아닙니다 — 그들은 단지 거기에 없을 뿐입니다. (동일한 이유로 우리는 Rust 로만 코딩하기를 원하는 사람들을 고용하는 것을 주저했습니다 . 언어 및 기타 기술 선택이 민첩한 방식으로 이루어져야 하는 스타트업 환경에서 설정하는 것은 나쁜 기대라고 생각하기 때문입니다.) Rust가 더 주류가 됨에 따라 Rust 개발 인재의 수는 시간이 지남에 따라 변할 것입니다.

또 다른 두 번째 요인은 Rust를 사용하면 팀에서 Rust를 아는 사람들과 그렇지 않은 사람들 사이에 분열이 생길 것이 거의 확실하다는 것입니다. 우리는 이 서비스를 위해 "난해한" 프로그래밍 언어를 선택했기 때문에 기능 구축, 생산 문제 디버깅 등에 도움이 되었을 수 있는 회사의 다른 엔지니어들은 대체로 도움을 줄 수 없었습니다. Rust 코드베이스의 꼬리. 엔지니어링 팀의 이러한 대체 가능성 부족은 빠르게 움직이고 팀의 모든 구성원의 결합된 강점을 활용하려고 할 때 실질적인 문제가 될 수 있습니다. 내 경험상, 사람들은 일반적으로 C++와 Python 같은 언어 사이를 이동하는 데 거의 어려움이 없지만 Rust는 충분히 새롭고 복잡해서 사람들이 함께 작업하는 데 장벽이 됩니다.

라이브러리와 문서는 미성숙합니다.

이것은 (희망합니다!) 시간이 지나면 해결되겠지만 Go와 비교할 때 Rust의 라이브러리와 문서화 생태계는 믿을 수 없을 정도로 미숙합니다. 이제 Go는 전 세계에 출시되기 전에 Google의 전체 전담 팀에서 개발하고 지원했다는 이점이 있으므로 문서와 라이브러리가 상당히 세련되었습니다. 이에 비해 Rust는 오랫동안 진행 중인 작업처럼 느껴졌습니다. 많은 인기 있는 라이브러리에 대한 문서가 매우 드물고 사용 방법을 이해하기 위해 특정 라이브러리 의 소스 코드 를 읽어야 하는 경우가 많습니다 . 이것은 나쁘다.

팀의 Rust 사과론자들은 종종 "async/await는 여전히 정말 새롭습니다." 및 "예, 해당 라이브러리에 대한 문서가 부족합니다."와 같은 말을 하지만 이러한 단점은 팀에 상당한 영향을 미쳤습니다. 우리는 서비스의 웹 프레임워크로 Actix를 채택함으로써 초기에 큰 실수를 저질렀습니다. 그 결정은 아무도 수정 방법을 알아낼 수 없는 라이브러리 깊숙이 묻혀 있는 버그와 문제에 부딪히면서 엄청난 고통과 괴로움을 초래했습니다. (공평하게 말하면 이것은 몇 년 전의 일이고 지금은 상황이 개선되었을 수 있습니다.)

물론 이런 종류의 미숙함은 실제로 Rust에만 국한된 것은 아니지만 팀이 지불해야 하는 세금에 해당합니다. 핵심 언어 문서와 자습서가 아무리 훌륭하더라도 라이브러리 사용 방법을 알 수 없다면 별 문제가 되지 않습니다(물론 처음부터 모든 것을 작성하려는 경우가 아니라면).

Rust는 새로운 기능을 대략적으로 만드는 것을 매우 어렵게 만듭니다.

나는 다른 사람에 대해 모르지만 적어도 나에게는 새로운 기능을 구축할 때 일반적으로 모든 데이터 유형, API 및 기타 세부 정보가 먼저 작동하지 않습니다. 나는 종종 몇 가지 기본 아이디어가 작동하도록 노력하고 일이 어떻게 작동해야 하는지에 대한 내 가정이 다소 정확한지 확인하려고 코드를 작성합니다. 예를 들어 Python에서 이 작업을 수행하는 것은 매우 쉽습니다. 타이핑과 같은 작업을 빠르고 느슨하게 수행할 수 있고 아이디어를 대략적으로 작성하는 동안 특정 코드 경로가 손상되더라도 걱정할 필요가 없기 때문입니다. 나중에 돌아가서 모든 것을 깔끔하게 만들고 모든 유형 오류를 수정하고 모든 테스트를 작성할 수 있습니다.

Rust에서 이런 종류의 "초안 코딩"은 매우 어렵습니다. 왜냐하면 컴파일러 는 유형 및 수명 검사를 통과하지 못하는 빌어먹을 모든 것에 대해 불평할 수 있고 불평할 것이기 때문 입니다. 이것은 생산 준비가 된 최종 구현을 구축해야 할 때 완벽하게 이해되지만 아이디어를 테스트하거나 기본 기반을 마련하기 위해 무언가를 함께 짜내려고 할 때 절대적으로 짜증납니다. 매크로는 어느 정도 도움 이 unimplemented!되지만 여전히 컴파일하기 전에 스택에서 모든 유형을 확인해야 합니다.

정말 짜증나는 것은 로드 베어링 인터페이스의 유형 서명을 변경해야 하고 유형이 사용되는 모든 장소를 변경하는 데 시간을 소비하여 무언가에 대한 초기 찌르기가 가능한지 확인하는 것입니다. 그런 다음 다시 변경해야 한다는 것을 깨달았을 때 모든 작업을 다시 실행합니다.

러스트는 무엇을 잘하나요?

Rust에 대해 제가 좋아하는 점과 다른 언어로 갖고 싶은 Rust의 기능이 분명히 있습니다. match구문이 훌륭합니다 . , 및 특성은 정말 강력하며 Option연산자 는 오류를 처리하는 우아한 방법입니다. 이러한 아이디어 중 많은 부분이 다른 언어로 된 대응물을 가지고 있지만 Rust의 접근 방식은 특히 우아합니다.ResultError?

나는 높은 수준의 성능과 안전성이 필요하고 빠르게 성장하는 전체 팀과 함께 코드의 주요 부분을 빠르게 발전시켜야 할 필요성에 대해 크게 걱정하지 않는 프로젝트에 Rust를 절대적으로 사용할 것입니다. 개별 프로젝트나 매우 작은(예: 2-3명) 팀의 경우 Rust가 적합할 것입니다. Rust는 성능과 안전이 가장 중요한 커널 모듈, 펌웨어, 게임 엔진 등과 같은 것들과 출하 전에 철저한 테스트를 수행하기 어려울 수 있는 상황에서 훌륭한 선택입니다

[원본]

https://mdwdotla.medium.com/using-rust-at-a-startup-a-cautionary-tale-42ab823d9454