Cargo는 전달된 인수와 전역 git 구성을 기반으로 이 파일을 기본값으로 채웠습니다. 그는 또한 hello_world 디렉토리를 git 저장소로 초기화했습니다.

이것이 src/main.rs 안에 있어야 할 내용입니다:

화물이 "Hello World!"를 생성했습니다. 우리를 위해, 당신은 이미 프로그래밍을 시작할 수 있습니다!

Cargo에는 이에 대해 더 자세히 설명하는 자체 매뉴얼이 있습니다.

결론

이것은 Rust를 경험하면서 자주 사용하게 될 기본 사항입니다. 이제 툴킷은 제쳐두고 언어 자체에 대해 자세히 알아 보겠습니다.

두 가지 방법이 있습니다. “Rust 학습” 섹션을 열어 실제 프로젝트를 공부하거나 맨 아래부터 시작하여 “구문 및 의미” 섹션부터 시작하여 점차 위로 올라가는 것입니다. 체계적 언어에 대한 경험이 있는 프로그래머는 "Rust 배우기"를 선호할 가능성이 높지만, 동적 언어에 대한 경험이 있는 프로그래머는 후자의 길을 가고 싶어할 것입니다. 사람마다 배우는 방법이 다릅니다! 귀하에게 적합한 것을 선택하십시오.

Rust는 인기를 얻고 있지만 여전히 많은 사람들이 그 가치와 기능을 이해하지 못하고 있습니다. Rust 프로그래밍 언어의 주요 장점에 대해 알려 드리겠습니다.

Rust와 다른 언어의 공통점은 무엇인가요?

위의 정의는 믿기 어렵습니다. 이전에는 모든 언어가 신뢰성이나 성능이라는 측면 중 하나를 선택했기 때문에 비현실적인 진술처럼 보입니다.

빠른 속도의 눈에 띄는 대표자는 할당된 메모리, 원격 서버에 대한 잘못된 액세스로 인해 오류가 얼마나 자주 나타나는지 모두 알고 있으며 예측할 수 없는 작업 결과 출력에 대해 말할 것도 없습니다. 여러 쓰기 스레드로 인해 결과를 예측하기 어려운 경우가 많습니다.

신뢰성에 대한 편견은 언어로 가장 잘 드러납니다. 하스켈는 자연적으로 컴파일되어 높은 보안 성능을 제공합니다. 컴파일할 수 있는 모든 것이 제대로 작동합니다. 주요 단점- 성능이 낮기 때문에 빠른 속도를 요구하는 프로젝트는 상상하기 어렵습니다. 하스켈.

나머지는 또한 중립적 위치, 특정 균형을 차지합니다. 그들은 실용성에 중점을 둡니다.

녹최고의 특성을 담았습니다 C++그리고 하스켈, 또한 다른 경쟁사보다 충분한 실용성과 기능성을 유지할 수 있었습니다.

Rust 언어의 아름다움은 무엇입니까?

Rust의 마법 같은 기능은 컴파일 기본 사항과 소유자 엔터티 정보( 소유자), 일시적으로만 디버깅을 하거나 프로젝트를 인수한 프로그래머에 대해( 변경 가능한 빌림) 및 일반 시청자에 대한 정보 ( 불변의 빌림).

프로그래밍할 때 자바또는 C++, 데이터 유형이 다소 다르지만 이 정보를 메모리에 보관해야 합니다. 안에 녹이는 언어 구성을 사용하여 구현되며, 이 정보를 통해 컴파일러는 더 쉽게 ID를 설정하고 동작 모델을 올바르게 선택할 수 있습니다. 컴파일러를 사용하면 코드 실행 중에 잠재적이고 일반적인 문제를 제거할 수 있습니다.

이 언어에는 약간 다른 접근 방식이 필요합니다. 특이함에도 불구하고 알고리즘은 매우 명확하고 효과적입니다. 이제 우리는 공부를 시작할 때 막다른 골목으로 이어질 수 있는 언어의 기본을 정의할 것입니다.

1. 상속 시스템은 완전히 제거되었으며, 이를 대체하기 위해 특별한 구조와 능력이 사용되었으며, 더 자세한 특성이 있습니다.
2. 포인터는 추가 보호 대상이 아닌 코드, 즉 unsafe() 함수 내부에만 독점적으로 존재합니다. 이를 대체하기 위해 안전한 코드는 기존 개체에 대한 올바른 포인터를 제공하는 참조를 사용합니다.
3. 링크가 정적이고 특정 요소를 가리키는 경우(예: 불변 Borrow = &Object ) 링크가 종료될 때까지 어떤 사용자도 수정할 수 없습니다.
4. 변경 가능한 Borrow = &mut Object 링크가 있는 경우 링크의 전체 수명 동안 다른 사용자가 내용을 읽을 수 없습니다.
5. 개발자는 Mac 및 *nix 플랫폼에 중점을 두므로 시스템에서 작동합니다. 윈도우 GNU 환경에서만 가능합니다.

대상 청중은 매우 중요합니다. Rust 언어에는 상당히 활동적인 커뮤니티, 개발된 의사소통 및 교육 시스템이 있습니다. IRC 채널이나 Reddit을 방문하는 것이 좋습니다. 오늘날까지도 이미 작성되었으며 대부분은 여전히 ​​지속적으로 개발되고 있으며 해당 프로젝트는 GitHub에서 찾을 수 있습니다.

그래픽과 게임 제작의 길을 걸어온 개발자들 사이에서 가장 인기 있는 언어입니다. 본격적인 운영 체제를 만들기 위한 개발도 있지만 여전히 개발 중입니다. 가까운 미래에는 클라이언트 프로그램과 웹 서버를 작성할 가능성이 있습니다. 위의 모든 작업은 완전히 Rust의 기능 내에 있습니다.

가장 큰, 그리고 아마도 유일한 단점은 지나치게 활동적인 개발입니다. 새 버전이 출시되면 구문이 다소 변경되며, 새로운 기능에 적응하기 위해 주기적으로 동작 및 개발 논리를 변경해야 합니다. 이러한 상황은 Rust-1.0이 출시될 때까지 한동안 계속될 것입니다.

일반 칼럼 “ 이번 주 Rust에서"는 링크의 Rust "n Stuffs에서 찾을 수 있습니다. 이전 및 과거 변경 사항에 대한 정보는 물론 언어 개발에 대한 전망도 항상 있습니다.

2013년 Mozilla는 삼성과 함께 새로운 웹 브라우저 엔진인 Servo 개발을 발표했습니다. 모바일 장치의 멀티 코어 프로세서용으로 특별히 제작되었으며 작업을 병렬 스레드로 나누고 웹 페이지 로딩 시간을 크게 줄일 수 있습니다. Servo는 Mozilla가 모바일 애플리케이션 작성을 위해 자체 개발한 Rust 프로그래밍 언어로 완전히 작성되었습니다.

언어에 대하여

Rust는 다양한 코딩 스타일을 지원하는 절차적 프로그래밍 언어입니다. 개발자 Graydon Hoare는 2006년에 언어 개발을 시작했고 3년 후 Mozilla가 프로젝트에 합류했습니다. 2010년에 Rust는 Mozilla Summit 컨퍼런스에서 발표되었습니다. 같은 해에 개발은 Rust로 작성된 컴파일러로 이전되었습니다. 컴파일러는 범용 프로그램 분석 및 변환 시스템인 LLVM을 데이터베이스로 사용했습니다.

언어의 첫 번째 안정 버전은 2015년에 출시되었습니다. 알파 버전이 출시된 후 Rust는 변경되었습니다. 컴파일러 내부에는 변경되지 않는 기성 기능만 남았습니다. 다른 모든 것은 실험 섹션으로 옮겨졌습니다.

Graydon Hoare는 언어의 핵심으로 다음과 같은 개념을 제시했습니다.

• 안전. Rust에는 기본적으로 활성화되는 여러 가지 프로그래머 제한 사항이 포함되어 있습니다. 이를 비활성화하려면 블록과 기능에 "안전하지 않음" 레이블이 필요합니다.
• 속도. 이 언어는 프로그래머에게 확실한 이점을 제공하는 다른 프로그래밍 언어인 C++와 속도면에서 비슷합니다.
• 병행. 시스템은 여러 계산을 동시에 수행할 수 있으며 동시에 서로 상호 작용할 수 있습니다.
• 짧음. Rust의 첫 번째 키워드는 5자로 제한되었습니다. 그러나 나중에 이 제한이 해제되었습니다.

Rust의 첫 번째 코드 중 하나의 예

그러나 Rust에도 단점이 없는 것은 아니며, 그 중 가장 눈에 띄는 것은 다음과 같습니다.

• 코드 중복.
• 언어 학습을 위한 문헌이 부족합니다.
• 컴파일 매개변수 입력이 명확해졌습니다. 다른 언어에는 비슷한 규칙이 없기 때문에 숙련된 프로그래머에게 항상 적합한 것은 아닙니다.

그러나 언어는 정기적으로 현대화되고 확장됩니다. 업데이트는 6주마다 출시됩니다.

Rust와 C++ 비교

Rust의 창시자들은 이를 개발자가 C 언어에 대한 몇 가지 개선 사항을 고안했을 때 등장한 1980년대 초에 등장한 C++의 후속 버전으로 간주하므로 젊고 여전히 변화하는 언어와 오랜 테스트를 거친 언어를 비교할 가치가 있습니다.

• 원격 메모리에 액세스 중입니다. C++에서 변수를 삭제하면 여러 가지 문제가 발생할 수 있습니다. Rust에서는 메모리 삭제 명령이 없기 때문에 이러한 복잡함은 불가능합니다. 하위 컴파일러는 작성한 코드에 오류가 포함되어 있다고 보고하고, C++ 컴파일러는 문제를 보고하지도 않고 제거된 값 없이 결과를 출력합니다.
• 세미콜론. 코드에 세미콜론을 추가하면 C++에서는 오류가 발생하지만 Rust에서는 루프 본문이 중괄호로 묶여 있습니다.
• 안전하지 않은 코드. Rust에는 안전하지 않은 코드로부터 메인 코드를 분리하는 "안전하지 않은" 라벨이 있습니다. 나중에 코드를 검토할 때 이를 통해 취약점 검색 범위를 좁힐 수 있습니다.

Firefox가 구현된 것은 C++였습니다. 이 변덕스러운 언어는 세부 사항에 더 많은 주의를 기울여야 했습니다. 그렇지 않으면 오류가 심각한 취약점으로 변했습니다. Rust는 이 문제를 해결하기 위해 설계되었습니다.

전망

2018년 3분기 RedMonk 순위에서 Mozilla 프로그래밍 언어는 지속적으로 23위를 차지했습니다. 전문가들은 그의 지위가 개선될 위험은 없다고 믿는다. 그럼에도 불구하고 2018년 8월에 제작자들은 업데이트된 Rust 1.28을 출시했습니다.

Stack Overflow에 따르면 2015년 Rust가 출시된 후 개발자 중 74%가 Rust에 대해 알아보고 싶어했습니다. 그러나 이미 2016년에 1위로 올라섰습니다. 사용자의 79%가 Rust를 자신이 가장 좋아하는 프로그래밍 언어로 꼽았고 계속해서 사용하고 싶다는 의사를 밝혔습니다. Rust는 2018년에 이 매개변수에서 1위를 차지했습니다.

스택 오버플로(Stack Overflow)는 2008년에 개발된 인기 있는 프로그래밍 질문 및 답변 시스템입니다.

Rust의 인기는 개발에 이를 사용하는 회사의 수를 통해 확인됩니다. 현재 이 목록에는 105개 조직이 포함되어 있습니다.

안녕하세요, 독자 여러분!

인생은 가만히 있지 않습니다. 그리고 O"Reilly는 Rust 프로그래밍 언어에 관한 최초의 기본 책을 출판하는 것에 대해 생각했습니다.

이 주제에 관심을 가지게 된 우리는 2014년 12월에 출판된 Rust 언어에 관한 리뷰 기사의 번역을 논의하기로 결정했습니다. 일부 구절이 이미 오래되었기 때문에 기사가 약간 단축되었지만 저자는 기존 대안의 맥락에서 이 언어를 잘 살펴보고 이 언어의 (무조건적인) 장점과 (조건부) 단점을 강조합니다.

그러나 더 흥미롭게 만들기 위해 이 기사의 댓글에 우리가 가장 좋아하는 러시아어 프로그래밍 블로그 중 하나에 게시된 Rust에 관한 다른 기사에 대한 링크를 남겨 두겠습니다. 우선 고양이로 가십시오.

면책조항: 프로그래밍 언어에 대한 취향은 이 게시물처럼 매우 주관적인 문제입니다. 건전한 회의론을 갖고 받아들이세요.

최근 몇 가지 새로운 프로그래밍 언어가 등장했습니다. 그 중에서도 저는 특히 Rust에 관심이 많았습니다. 아래에서는 Rust에 대한 나의 인상을 공유하고 이를 다른 여러 프로그래밍 언어와 비교해 보겠습니다.

Rust 학습의 장벽

나는 처음 시도했을 때 Rust에 대해 알지 못했습니다. 이 언어를 배우는 데에는 다음과 같은 몇 가지 장벽이 있습니다.

1. 언어는 빠르게 변하고 있다. Rust에는 "종신에 대한 온건한 독재자"가 없습니다. 언어는 핵심 팀 구성원과 커뮤니티의 기여를 통해 발전합니다.
2. 첫 번째 점을 고려하면, Rust 튜토리얼은 매우 드물다. 매뉴얼, 기타 공식 문서, Rust by 예제 사이트가 훌륭한 리소스입니다. 그러나 Rust는 훨씬 더 복잡합니다. 필요한 정보를 찾기 위해 RFC, 블로그, Github의 댓글까지 샅샅이 뒤져야 하는 경우가 종종 있으며, 이 정보가 바로 어제 나타났더라도 여전히 완전히 확신할 수는 없습니다. 비록 내용이 길겠지만, 나는 Rust에 관한 훌륭하고 권위 있는 책을 기대하고 있습니다.
3. Rust의 소유권 시스템과 차용 확인 메커니즘은 초보자에게 혼란스러울 수 있습니다.. 가비지 수집 없이 메모리 안전을 보장하기 위해 Rust는 복잡한 차용 및 소유권 시스템을 사용합니다. 그녀는 종종 초보자를 두려워합니다.
4. Rust 컴파일러는 매우 엄격합니다.. 나는 Rust를 규율 언어라고 부릅니다. Rust 컴파일러에 완전히 명확하지 않은 것은 모두 직접 지정해야 하며, 일부 의도는 처음에는 인식하지 못할 수도 있습니다. 이러한 학습 장벽은 다른 모든 장벽과 함께 종종 Rust에 대한 실망스러운 첫인상을 가져옵니다.

장점

Rust에는 많은 장점이 있습니다. 그들 중 일부는 독특합니다.

가비지 수집 없는 메모리 안전성

이것은 아마도 Rust의 가장 중요한 성과일 것입니다. 직접적인 메모리 조작을 허용하는 저수준 프로그래밍 언어에서는 use-after-free 또는 런타임 시 메모리 누수와 같은 오류가 상당히 비쌉니다. 최신 C++에서는 이러한 문제를 처리하는 능력이 향상되었지만 엄격한 기술 규율이 필요합니다(읽기: 프로그래머는 안전하지 않은 작업을 계속 수행함). 따라서 내 생각에는 일반적으로 C++에서는 이 문제를 근본적이고 안정적으로 해결할 수 없습니다.

Rust 프로그래머가 안전하지 않은 블록에 안전하지 않은 코드를 작성할 수 있다는 것은 사실이지만 (1) 이는 의도적으로 수행되며 (2) 안전하지 않은 블록은 전체 코드 기반의 아주 작은 부분만을 구성할 수 있지만 엄격하게 제어됩니다.
가비지 수집기는 가장 일반적인 메모리 안전 도구입니다. GC와 잘 지내면 몇 가지 옵션이 있습니다. 그러나 Rust의 소유권 시스템은 메모리 보안뿐만 아니라 데이터 및 리소스 보안도 보장합니다(아래 참조).

RAII 및 리소스

RAII(자원획득은 초기화)라는 말은 생소한 용어지만 그 의미를 잘 전달하고 있습니다. Wikipedia에서 우리는 RAII가 스택에 할당된 객체와 함께 작동한다는 것을 읽었습니다. Rust의 소유권 시스템에서는 이 원칙을 힙 할당 객체에도 적용할 수 있습니다. 이를 통해 메모리, 파일, 소켓과 같은 리소스의 자동 해제가 고도로 예측 가능하고 컴파일 타임에 보장됩니다.
Python이나 Ruby와 같은 동적 언어는 비슷한 기능을 가지고 있지만 Rust IMO의 성능에는 미치지 못합니다.

데이터 경쟁 없는 경쟁력

Rust는 동시 프로그래밍 중에 데이터 보안을 보장합니다. 즉, 주어진 시간에 많은 판독기 또는 한 명의 "작성기"만 데이터에 액세스할 수 있도록 보장합니다.

대수 데이터 유형

일반 유형(튜플 및 구조체) 외에도 Rust는 열거 유형(여기서는 "합계 유형" 또는 "변형 유형"이라고 함)과 패턴 일치도 제공합니다. 시스템 프로그래밍 언어에 이렇게 발전된 유형 시스템이 있다는 것은 놀라운 일입니다.

상속보다 구성

Rust는 분명히 상속보다 유형 구성을 선호합니다. 나는 이 사실이 승리라고 여겨지는 캠프에 있습니다. Rust가 제네릭 유형을 지원할 때 특성은 중요한 역할을 합니다.

단점(조건부)

모든 것이 매우 명확해야합니다

Rust는 훈련된 언어입니다. 컴파일러는 모든 것을 매우 명확하게 전달해야 합니다. 그렇지 않으면 불분명한 점이 더 이상 남지 않을 때까지 맹세합니다. 이는 일반적으로 코드 품질에 도움이 되지만 신속한 프로토타이핑이나 일회성 작업의 경우 과잉이 될 수 있습니다.

결과적으로 당신은 Rust로 더 훌륭하고 명확한 코드를 작성해야 합니다. 이것을 이해하면 거친 가장자리가 어느 정도 사라질 수 있습니다.

가비지 수집은 보조적입니다.

Rust에는 매우 기본적인 가비지 수집기가 있습니다. 즉, 참조 계산인 Rc와 라운드 로빈 감지가 없는 원자 참조 계산인 Arc가 있습니다. 그러나 이러한 기능은 기본적으로 언어에서 작동하지 않으며 Rust의 표준 메모리 관리 메커니즘(Stack, & 및 Box)을 더 자주 사용해야 합니다. 애플리케이션의 메모리 문제가 심각하지 않다면 가비지 수집을 사용하지 않는 Rust의 메모리 안전 모델을 허용해야 합니다.

표현력은 그 자체로 목적이 아니다

Rust 언어는 표현력이나 코드의 아름다움에 대해 걱정하지 않습니다. 그런 점에서 확실히 나쁘지는 않지만 원하는 만큼 훌륭하지는 않습니다.

상대적으로 진입장벽이 높음

원칙적으로 Rust는 몇 주 안에 전문적인 코드를 빠르게 익히고 작성할 수 있는 언어 중 하나가 아닙니다. Rust는 아마도 C++보다 더 컴팩트하지만 많은 프로그래밍 언어보다 확실히 더 큽니다. 다른 언어에 비해 접근성이 매우 높다고 할 수는 없습니다. 언어 습득 속도를 최우선으로 생각한다면 문제가 될 수 있습니다.

Rust 및 기타 언어

동적 언어

동적(스크립팅) 언어는 Rust와 프로그래밍 언어 스펙트럼의 반대쪽에 있습니다. Rust에 비해 동적 언어로 코드를 작성하는 것이 일반적으로 더 빠르고 쉽습니다. 나는 다음과 같은 상황에서 동적 언어가 Rust를 능가한다고 생각합니다.

• 신속한 프로토타이핑 또는 일회성 작업
• 코드가 프로덕션용이 아니거나 런타임 시 오류가 작은 문제인 경우
• 자체(개인) 프로젝트
• 반자동 작업(예: 로그 구문 분석/분석, 일괄 텍스트 처리)

이런 경우에는 모든 일을 완벽하게 하려고 해서는 안 됩니다. 반대로 내 생각에는 Rust가 다음과 같은 경우에 더 적합합니다.

• 중간 규모 또는 대규모 팀에서 작업
• 프로덕션에서 장기간 사용하기 위한 코드 지향
• 장기간 사용될 코드에는 정기적인 유지 관리 및/또는 리팩토링이 필요합니다.
• 안전을 보장하기 위해 많은 단위 테스트를 작성하는 코드

일반적으로 코드 품질이 중요한 경우. 동적 언어는 초기 단계에서 코드를 더 빠르게 작성하는 데 도움이 되지만 나중에는 작업 속도가 느려집니다. 더 많은 테스트를 작성해야 하고, 개발 라인이 중단되거나 심지어 생산 중단이 발생하기도 합니다. Rust 컴파일러는 버그를 식별하고 수정하는 데 비용이 적게 드는 컴파일 타임에 많은 작업을 올바르게 수행하도록 강제합니다.

가다

이 두 언어를 비교하는 것은 논쟁의 여지가 있지만 한동안 공부해 왔기 때문에 주관적인 인상을 여기서 공유하겠습니다. Rust에 비해 제가 Go에서 좋아하는 점은 다음과 같습니다.

• 경량 - 언어가 작습니다(간단하지만 매우 강력함).
• gofmt 유틸리티 - 프로그래밍할 때 정신적 부담을 크게 줄여줍니다.
• 고루틴/채널
• 즉석 컴파일

내가 Go를 그만둔 이유:

• 너무 미니멀해요. 유형 시스템과 언어 자체는 확장성이 좋지 않습니다.
• Go 프로그래밍은 나에게 약간 건조한 것 같습니다. Java로 프로그래밍하던 시절이 생각납니다. 엔터프라이즈 개발에 적합하고 기계적이고...별로 흥미롭지 않습니다(알림: 취향에 대한 논쟁은 없습니다).
• Google의 지원 덕분에 Go의 인기는 계속되고 있지만, 그 점은 조금 회의적입니다. 지역사회와 회사의 이익이 일치하지 않을 경우 전자가 희생될 수 있습니다. 물론 모든 회사는 주로 자신의 이익을 추구합니다. 아무 문제가 없다. 그냥... 조금 짜증나네요. (기업에서 홍보하는 많은 언어와 프레임워크가 비슷한 문제에 직면해 있습니다. 적어도 Mozilla는 주가에 의존하지 않습니다.)

님

Nim(이전에는 Nimrod라고 불림)은 매우 흥미로운 언어입니다. C로 컴파일되므로 성능이 상당히 좋습니다. 겉보기에는 제가 늘 프로그래밍을 좋아했던 언어인 Python과 비슷합니다. 가비지 수집 언어이지만 소프트 실시간 지원을 제공하고 가비지 수집기 자체의 동작을 더 예측하기 쉽습니다. 흥미로운 효과 시스템이 있습니다. 원칙적으로 저는 이 언어를 정말 좋아합니다.

그의 경우 가장 큰 문제는 생태계의 미성숙이다. 언어 자체는 잘 구축되어 있고 상대적으로 안정적이지만 현재로서는 프로그래밍 언어가 성공하기에는 충분하지 않습니다. 문서화, 표준 라이브러리, 패키지 저장소, 지원 프레임워크, 커뮤니티 및 제3자 참여 등 모든 것을 프로덕션에 준비하는 것은 쉽지 않습니다.

풀타임으로 언어를 완성할 전문가가 없으면 이 마지막 단계는 매우 힘들 수 있습니다. 새로운 프로그래밍 언어 중에서 Nim은 아직 심각한 지원을 자랑할 수 없습니다.
즉, 나는 그의 성공을 기원하고 계속해서 그를 따라갑니다.

기타

Julia나 . Julia는 좋은 성능과 부드러운 C 스타일 호출을 갖춘 동적 언어입니다.(동적 언어와 REPL을 좋아한다면 주목하세요) Julia는 수치 및 과학 분야 덕분에 모든 사람의 주목을 받았습니다. 범용 언어가 될 가능성이 있는 반면, 제가 보기에는 언어의 발전은 그 창시자들의 공동체에 의해 큰 영향을 받는 것 같습니다.

D는 적어도 처음에는 "C++이지만 더 나은"을 만들려는 시도였습니다. 버전 1.0이 2007년에 출시되었으므로 이 언어는 그다지 새로운 언어는 아닙니다. 이것은 좋은 언어이지만 객관적인 이유로 아직 뿌리를 내리지 못했습니다. 그 이유는 초기 단계에서 Phobos/Tango로 분할되고 주로 가비지 수집을 통해 메모리 안전성을 제공하고 초기에 C++.

내가 Rust의 가능성이 상당히 높다고 생각하는 이유

요즘 새로운 프로그래밍 언어가 참 많이 나오네요. 제 생각에는 Rust가 그 중에서 눈에 띄는 이유는 무엇입니까? 나는 다음과 같은 주장을 펼칠 것이다:

시스템 프로그래밍을 위한 실제 언어

삽입은 쉬운 일이 아닙니다. 아마도 이 문제는 문자 그대로 여러 언어로 해결될 수도 있고 C와 C++ 두 가지 언어로 해결될 수도 있습니다. (이것이 Skylight가 Ruby용 확장 프로그램을 개발하기 위해 Rust를 선택한 이유일 수 있습니다. 매우 위험함에도 불구하고 말이죠.) Rust가 런타임 오버헤드를 얼마나 잘 제거했는지는 놀랍습니다. 이는 Rust에 대한 독특한 관점을 열어줍니다.

Null 없이

Null 개체/포인터(소위 "10억 달러 버그")는 런타임 오류의 일반적인 원인입니다. null이 없는 프로그래밍 언어는 소수에 불과하며 대부분 기능적 언어입니다. 요점은 null을 제거하려면 매우 고급 유형 시스템이 필요하다는 것입니다. 일반적으로 언어의 구문 수준에서 이를 처리하려면 대수적 데이터 유형과 패턴 일치가 필요합니다.

고급 고급 구조를 갖춘 저급 언어

핵심(적어도 이론상으로는)까지 "베어 메탈 언어"인 Rust는 대수 데이터 유형, 패턴 일치, 특성, 유형 추론 등을 포함하여 상대적으로 높은 수준의 많은 기능도 제공합니다.

강력한 커뮤니티와 실질적인 관련성

Rust 커뮤니티는 매우 친절하고 활동적입니다. (물론 주관적인 감상입니다.) 또한 Rust는 일부 심각한 실제 프로젝트, 특히 Rust 컴파일러, Servo, Skylight 등에서 사용되었습니다. 아직은 언어 발달 단계입니다.

현재까지는 큰 오류는 없습니다

때때로 회사 내에서 수행되는 언어나 프레임워크의 개발이 우연히 막다른 골목에 도달할 수 있습니다. 운 좋게도 핵심 Rust 팀은 지금까지 훌륭한 일을 해내고 있습니다. 계속 힘내세요, 러스트!

웹 개발을 위한 Rust

Rust가 시스템 프로그래밍 언어라면 웹 개발에 적합할까요? 이 질문에 대한 답도 찾고 있습니다.

라이브러리 및 프레임워크

우선, 일부 HTTP 라이브러리가 이에 대비해야 합니다. (이 내용은 “Are we web Yet” 웹사이트에 설명되어 있습니다.) 첫 번째 Rust-http 라이브러리는 이미 구식입니다. 그녀의 잠재적 후계자 Teepee는 사실상 정지된 애니메이션 상태입니다. 다행히도 Hyper가 좋은 후보인 것 같습니다. 이는 이미 Rust의 공생 프로젝트인 Servo에 채택되었으며, Rust용 HTTP 라이브러리가 된 것은 축복이라고 생각합니다.

Rust 표준 라이브러리는 아직 비동기 I/O를 지원하지 않습니다. 이를 위해 비차단 소켓 I/O를 제공하는 외부 mio 라이브러리를 사용할 수 있습니다. I/O 단순화의 일부로 녹색 스레드 지원이 제거되었습니다.

Iron 및nickel.rs를 포함하여 Rust를 위한 여러 웹 프레임워크가 활발히 개발되고 있습니다. 그들과의 상황이 진정되기까지는 시간이 걸릴 수 있습니다.

Rust는 웹용 언어인가요?

언젠가는 라이브러리와 프레임워크가 준비될 것입니다. 문제는 Rust 자체가 웹 개발에 적합한가입니다. Rust의 저수준 메모리 관리 및 보안 기능이 너무 복잡합니까?

결국 모든 것은 당신이 프로젝트에서 기대하는 바에 달려 있다고 생각합니다. 위에서 단기 프로젝트에서 Rust를 동적 언어와 비교할 때 그러한 경우 Rust의 복잡성이 정당화되지 않을 수 있다고 언급했습니다. 그러나 제품이 오랫동안 지속될 것으로 예상한다면(예: 6개월 이상) Rust가 좋은 선택일 수 있습니다.

Rust가 웹 스타트업에 좋은가요?

스타트업은 어떻습니까? 신속한 프로토타입 제작과 개발 주기가 필요합니다. 이것은 더 논란의 여지가 있는 질문이지만 저는 제 의견을 지지합니다. 장기 프로젝트를 검토하고 있다면 올바른 프로그래밍 언어를 선택하는 것이 중요하며 Rust는 특별한 주의를 기울일 가치가 있습니다. 비즈니스 관점에서 신속한 프로토타이핑을 가능하게 하는 언어는 상당한 이점을 제공하는 반면, 리팩토링 및 병목 현상 제거는 항상 나중을 위해 남겨둘 수 있습니다. 엔지니어링 현실은 일반적으로 리팩토링 작업 비용이 생각보다 높으며, 시스템의 많은 요소를 흔들어도 오래 전에 작성된 코드가 여전히 어딘가에 남아 있다는 것입니다. 몇 년 동안.

러스트를 사용해 보세요!

사이트 개발을 위해 일부 자금을 돕고 이체할 수 있습니다.

녹 Mozilla가 개발 중인 새로운 실험적 프로그래밍 언어입니다. 이 언어는 컴파일되고 다중 패러다임으로 구성되어 있으며 C/C++의 대안으로 자리잡고 있습니다. 이는 경쟁 상대가 많지 않기 때문에 그 자체로 흥미롭습니다. Walter Bright의 D 또는 Google의 Go를 기억하실 수 있습니다.
Rust는 기능적, 병렬적, 절차적, 객체 지향 프로그래밍을 지원합니다. 응용 프로그램 프로그래밍에 실제로 사용되는 패러다임의 거의 전체 범위입니다.

내 목표는 문서를 번역하는 것이 아니라(게다가 아직 공식 언어가 출시되지 않았기 때문에 문서가 매우 드물고 끊임없이 변경되고 있습니다) 대신 언어의 가장 흥미로운 기능을 강조하고 싶습니다. 정보는 공식 문서와 인터넷에서 해당 언어에 대한 극소수의 언급을 통해 수집되었습니다.

첫 인상

약간 더 복잡한 예 - 계승 계산 함수:

Fn fac(n: int) -> int ( 결과 = 1, i = 1; while i<= n { result *= i; i += 1; } ret result; }

예제에서 볼 수 있듯이 함수는 "기능적" 스타일로 선언됩니다(이 스타일은 전통적인 "int fac(int n)"에 비해 몇 가지 장점이 있습니다). 우리는보다 자동 유형 추론(let 키워드), while 인수에 괄호가 없습니다(Go와 동일). 즉시 눈에 띄는 또 다른 점은 키워드의 간결함입니다. Rust의 제작자는 모든 키워드를 가능한 한 짧게 유지하는 것을 강조했으며, 솔직히 말해서 저는 그것이 마음에 듭니다.

작지만 흥미로운 구문 기능

• 숫자 상수에 밑줄을 삽입할 수 있습니다. 이것은 편리한 기능이며 현재 많은 새로운 언어에 이 기능이 추가되고 있습니다.
  0xffff_ffff_ffff_ffff_ffff_ffff
• 이진 상수. 물론 실제 프로그래머는 머리 속에서 bin을 hex로 변환해야 하지만 이렇게 하는 것이 더 편리합니다! 0b1111_1111_1001_0000
• 모든 명령문의 본문(단일 표현식으로 구성된 명령문이라도)은 중괄호로 묶어야 합니다. 예를 들어 C에서는 if(x>0) foo(); , Rust에서는 foo() 주위에 중괄호를 넣어야 합니다.
• 그러나 if, while 및 유사한 연산자의 인수는 괄호로 묶을 필요가 없습니다.
• 대부분의 경우 코드 블록은 표현식으로 간주될 수 있습니다. 특히 다음이 가능합니다.
  x = if the_stars_align() ( 4 ) else if Something_else() ( 3 ) else ( 0 );
• 함수 선언 구문 - 먼저 fn 키워드, 인수 목록, 이름 뒤에 인수 유형이 표시되고 함수가 값을 반환하는 경우 화살표 "->" 및 반환 값 유형이 표시됩니다.
• 변수는 동일한 방식으로 선언됩니다. 키워드 let, 변수 이름, 변수 뒤의 콜론을 통해 유형을 지정한 다음 초기 값을 할당할 수 있습니다.
  카운트하자: int = 5;
• 기본적으로 모든 변수는 변경할 수 없습니다. mutable 키워드는 가변 변수를 선언하는 데 사용됩니다.
• 기본 유형의 이름은 내가 본 것 중에서 가장 간결합니다: i8, i16, i32, i64, u8, u16, u32, u64,f32, f64
• 위에서 언급한 것처럼 자동 유형 추론이 지원됩니다.

데이터 유형

대조적으로, C, C++, C# 및 Java에서 채택된 명목적 유형 지정은 그러한 구성을 허용하지 않습니다. 명목 유형 지정의 경우 각 구조는 기본적으로 다른 유형과 호환되지 않는 고유한 유형입니다.

Rust의 구조는 "레코드"라고 불립니다. 튜플도 있습니다. 이는 동일한 레코드이지만 이름이 없는 필드가 있습니다. 레코드의 요소와 달리 튜플의 요소는 변경할 수 없습니다.

벡터가 있습니다. 어떤 면에서는 일반 배열과 유사하고 어떤 면에서는 stl의 std::Vector 유형과 유사합니다. 목록으로 초기화할 때 C/C++처럼 중괄호가 아닌 대괄호를 사용합니다.

myvec = ;

그러나 벡터는 동적 데이터 구조이므로 특히 벡터는 연결을 지원합니다.

v: 변경 가능 = ; v += ;

템플릿이 있습니다. 이들 구문은 C++의 "템플릿"이 복잡하지 않고 매우 논리적입니다. 함수 및 데이터 유형 템플릿이 지원됩니다.

Fn for_rev (v: [T], act: block(T)) ( let i = std::vec::len(v); while i > 0u ( i -= 1u; act(v[i]); ) ) 유형 원형_buf = (시작: 단위, 끝: 단위, buf: );

언어는 소위를 지원합니다 태그. 이는 추가 필드(사용된 변형의 코드, 즉 공용체와 열거형 사이의 공통점)가 있는 C의 공용체에 지나지 않습니다. 또는 이론적 관점에서 볼 때 대수적 데이터 유형입니다.

태그 모양 ( 원(점, 부동 소수점); 직사각형(점, 점); )

가장 간단한 경우 태그는 열거형과 동일합니다.

동물 태그( 개; 고양이; ) a: 동물 = 개; a = 고양이;
더 복잡한 경우에는 "열거형"의 각 요소가 자체 "생성자"를 갖는 독립적인 구조입니다.
또 다른 흥미로운 예는 "목록" 유형의 객체를 정의하는 데 사용되는 재귀 구조입니다.
태그 목록 ( 없음; 단점(T, @list ); ) 하자: 목록 = 단점(10, @cons(12, @nil));
태그는 매우 복잡할 수 있는 패턴 일치 표현식에 참여할 수 있습니다.
alt x ( cons(a, @cons(b, _)) ( process_pair(a,b); ) cons(10, _) ( process_ten(); ) _ ( 실패; ) )

패턴 매칭

포인터.일반적인 "C" 포인터 외에도 Rust는 참조 계산이 내장된 특별한 "스마트" 포인터(공유(공유 상자) 및 고유(고유 상자))를 지원합니다. 이는 C++의 shared_ptr 및 Unique_ptr과 다소 유사합니다. 공유에는 @, 고유에는 ~라는 고유한 구문이 있습니다. 고유 포인터의 경우 복사 대신 이동이라는 특수 작업이 있습니다.
x = ~10이라고 하자; 하자<- x;
이러한 이동 후에는 x 포인터가 초기화 해제됩니다.

클로저, 부분 적용, 반복자

1. 키워드 람다중첩 함수 또는 함수형 데이터 유형을 선언하는 데 사용됩니다.

Fn make_plus_function(x: int) -> 람다(int) -> int ( 람다(y: int) -> int ( x + y ) ) let plus_two = make_plus_function(2); 주장 plus_two(3) == 5;

이 예에는 int 유형의 "x" 인수 하나를 취하고 "int->int" 유형의 함수를 반환하는 make_plus_function 함수가 있습니다(여기서는 람다가 키워드임). 함수 본문은 바로 이 함수를 설명합니다. "return" 연산자가 없다는 점은 약간 혼란스럽습니다. 하지만 이는 FP에서 흔히 발생하는 현상입니다.

2. 키워드 차단하다함수 유형을 선언하는 데 사용됩니다. 함수 인수는 일반 코드 블록과 유사한 것으로 대체될 수 있습니다.
fn map_int(f: block(int) -> int, vec: ) -> ( let result = ; for i in vec ( result += ; ) ret result; ) map_int((|x| x + 1 ), );

여기에 입력이 블록인 함수가 있습니다. 기본적으로 "int->int" 유형의 람다 함수와 int 유형의 벡터입니다(벡터 구문에 대해서는 나중에 자세히 설명합니다). "블록" 자체는 호출 코드에서 다소 특이한 구문(|x| x + 1)을 사용하여 작성됩니다. 개인적으로 저는 C#에서 | 기호인 람다를 선호합니다. 지속적으로 비트별 OR로 인식됩니다(그런데 이는 모든 기존 C 기반 연산과 마찬가지로 Rust에도 존재합니다).

3. 부분 적용이란 다른 함수의 일부 인수 값을 지정하여 더 많은 인수를 가진 다른 함수를 기반으로 하는 함수를 생성하는 것입니다. 이에 사용된 키워드는 묶다자리 표시자 문자 "_":

daynum = std::vec::position(_, ["mo", "tu", "we", "do", "fr", "sa", "su"]) 바인딩

더 명확하게 하기 위해 다음과 같은 간단한 래퍼를 만들어 일반 C에서 이 작업을 수행할 수 있다고 바로 말씀드리겠습니다.
const char* daynum (int i) ( const char *s =("mo", "tu", "we", "do", "fr", "sa", "su"); return s[i]; )

그러나 부분 적용은 절차적 스타일이 아닌 기능적 스타일입니다. (그런데 주어진 예제에서는 인수 없이 함수를 얻기 위해 부분 적용을 수행하는 방법이 명확하지 않습니다.)

또 다른 예: add 함수는 두 개의 int 인수로 선언되어 int를 반환합니다. 다음으로, 하나의 인수 int를 갖고 int를 반환하는 함수형 Single_param_fn이 선언됩니다. 바인드를 사용하면 부분적으로 지정된 인수가 있는 add 함수를 기반으로 구축된 두 개의 함수 개체 add4 및 add5가 선언됩니다.

Fn add(x: int, y: int) -> int ( ret x + y; ) 유형 Single_param_fn = fn(int) -> int; let add4: Single_param_fn = 바인딩 add(4, _); let add5: Single_param_fn = 바인딩 add(_, 5);

함수 객체는 일반 함수와 같은 방식으로 호출할 수 있습니다.
주장(add(4,5) == add4(5)); 주장(add(4,5) == add5(4));

4. 순수 함수와 술어
순수 함수는 부작용이 없는 함수입니다(순수 함수 외에 다른 함수를 호출하지 않는 함수 포함). 이러한 기능은 pure 키워드로 식별됩니다.
순수 fn lt_42(x: int) -> bool ( ret (x< 42); }
조건자는 bool 유형을 반환하는 순수 함수입니다. 이러한 함수는 typestate 시스템(아래 참조)에서 사용할 수 있습니다. 즉, 다양한 정적 검사를 위해 컴파일 단계에서 호출됩니다.

구문 매크로
계획된 기능이지만 매우 유용합니다. Rust에서는 아직 초기 개발 단계입니다.
std::io::println(#fmt("%s는 %d입니다", "답변", 42));
C의 printf와 유사하지만 컴파일 타임에 실행되는 표현식입니다(따라서 모든 인수 오류는 컴파일 단계에서 감지됩니다). 불행하게도 구문 매크로에 대한 자료는 거의 없으며 자체적으로 개발 중이지만 Nemerle 매크로와 같은 것이 나올 것이라는 희망이 있습니다.
그건 그렇고, Nemerle과 달리 # 기호를 사용하여 구문적으로 매크로를 강조하기로 한 결정은 매우 현명하다고 생각합니다. 매크로는 기능과 매우 다른 엔터티이므로 한눈에 어디에 있는지 확인하는 것이 중요하다고 생각합니다. 코드 함수가 호출되고 매크로가 호출됩니다.

속성

병렬 컴퓨팅

작업은 인수가 없는 하나 이상의 함수로 구성됩니다. 작업은 생성 기능을 사용하여 시작됩니다. 각 작업에는 정보를 다른 작업으로 전송하는 채널이 있을 수 있습니다. 채널은 채널 데이터 유형에 의해 매개변수화되는 특수 템플릿 유형 chan입니다. 예를 들어 chan은 부호 없는 바이트를 전송하는 채널입니다.
채널로 보내려면 send 함수를 사용하세요. 첫 번째 인수는 채널이고 두 번째 인수는 보낼 값입니다. 이 함수는 실제로 값을 채널의 내부 버퍼에 배치합니다.
포트는 데이터를 수신하는 데 사용됩니다. 포트는 포트 데이터 유형으로 매개변수화되는 일반 포트 유형입니다. 포트는 부호 없는 바이트를 수신하기 위한 포트입니다.
포트에서 읽으려면 인수가 포트이고 반환 값이 포트의 데이터인 recv 함수를 사용합니다. 독서는 작업을 차단합니다. 포트가 비어 있으면 다른 작업이 포트와 연결된 채널로 데이터를 보낼 때까지 작업은 대기 상태로 들어갑니다.
채널을 포트와 연결하는 것은 매우 간단합니다. chan 키워드를 사용하여 포트로 채널을 초기화하면 됩니다.
reqport = 포트()를 보자;
let reqchan = chan(reqport);
여러 채널을 하나의 포트에 연결할 수 있지만 그 반대는 불가능합니다. 한 채널을 여러 포트에 동시에 연결할 수는 없습니다.

유형상태

예를 들어, "file" 유형의 객체가 있는 경우 "closed" 및 "open" 상태를 가질 수 있습니다. 그리고 파일이 닫혀 있으면 파일 읽기 작업이 허용되지 않습니다. 현대 언어에서는 읽기 함수가 예외를 발생시키거나 오류 코드를 반환하는 것이 일반적입니다. 유형 상태 시스템은 컴파일 타임에 이러한 오류를 감지할 수 있습니다. 컴파일러가 가능한 쓰기 작업 전에 변수에 대한 읽기 작업이 발생하는지 결정하는 것처럼 "파일 열기" 상태에서 유효한 "Read" 메서드를 결정할 수 있습니다. 는 객체를 이 상태로 전환하는 "Open" 메서드 이전에 호출됩니다.

Rust에는 부작용이 없고 bool 유형을 반환하는 특수 함수인 "술어"라는 개념이 있습니다. 이러한 함수는 특정 조건의 정적 검사를 위해 컴파일 단계에서 호출되도록 컴파일러에서 사용할 수 있습니다.

제약 조건은 컴파일 타임에 수행할 수 있는 특별한 검사입니다. 이를 위해 check 키워드가 사용됩니다.
순수 fn is_less_than(int a, int b) -< bool { ret a < b; } fn test() { let x: int = 10; let y: int = 20; check is_less_than(x,y); }
다음과 같은 방식으로 함수의 입력 매개변수에 술어를 "걸" 수 있습니다.
fn 테스트(int x, int y) : is_less_than(x,y) ( ... )

typestate에 대한 정보가 거의 없어 아직 불분명한 부분이 많지만, 어쨌든 개념은 흥미롭습니다.

그게 다야. 여전히 몇 가지 흥미로운 점을 놓쳤을 가능성이 있지만 기사는 이미 부풀려졌습니다. 원한다면 이제 Rust 컴파일러를 구축하고 다양한 예제를 시험해 볼 수 있습니다. 조립 정보는 다음에서 제공됩니다.