# 러스트 재작성

> Clean Markdown view of GeekNews topic #16953. Use the original source for factual precision when an external source URL is present.

## Metadata

- GeekNews HTML: [https://news.hada.io/topic?id=16953](https://news.hada.io/topic?id=16953)
- GeekNews Markdown: [https://news.hada.io/topic/16953.md](https://news.hada.io/topic/16953.md)
- Type: GN+
- Author: [neo](https://news.hada.io/@neo)
- Published: 2024-09-27T09:49:53+09:00
- Updated: 2024-09-27T09:49:53+09:00
- Original source: [josephg.com](https://josephg.com/blog/rewriting-rust/)
- Points: 1
- Comments: 1

## Topic Body

#### Rust 재작성

- Rust 프로그래밍 언어는 첫 번째 세대 제품처럼 느껴짐
- Rust의 초기 매력: 대수적 타입, 메모리 안전성, 성능 저하 없음, 현대적 패키지 관리자
- 4년간 사용 후, Rust는 항상 완벽하지 않음
- 언어의 발전이 매우 느려짐
- 많은 불안정한 기능이 안정적인 Rust에 포함되지 않음

#### 환상적인 언어

- Rust 컴파일러를 포크하고 새로운 "seph" 에디션을 만들고 싶음
- Rust의 기존 기능을 유지하면서 새로운 기능 추가 가능

##### 함수 트레이트 (효과)

- Rust는 구조체에 트레이트를 정의하지만 함수에도 트레이트를 정의할 필요가 있음
- 함수의 다양한 특성을 나타낼 수 있음
  - 함수가 패닉을 일으키는지 여부
  - 고정된 스택 크기를 가지는지 여부
  - 함수가 끝까지 실행되는지 아니면 중간에 대기하는지 여부
  - 함수가 순수한지 여부
  - 함수가 안전하지 않은 코드를 실행하는지 여부
  - 함수가 종료를 보장하는지 여부

##### 컴파일 타임 기능

- 많은 Rust 프로젝트가 많은 서드파티 크레이트를 사용함
- 이러한 크레이트는 공급망 위험을 증가시킴
- 보안에 민감한 함수 호출을 명시적으로 허용하도록 하는 기능 추가 제안
- `fs_write`와 같은 기능을 호출하려면 명시적으로 허용해야 함

##### Pin, Move 및 구조체 대여

- `Pin`은 Rust의 대여 검사기 문제를 해결하기 위한 복잡한 해킹
- `Pin` 대신 `Move` 마커 트레이트를 사용하는 것이 더 합리적
- 구조체 필드를 대여 상태로 표시할 수 있는 구문 추가 제안
- `Move` 마커 트레이트와 `Mover` 트레이트 도입 제안

##### 컴파일 타임

- Zig의 `comptime` 기능을 도입하여 Rust 매크로 언어를 대체
- 컴파일 타임에 코드를 실행할 수 있는 작은 인터프리터 추가
- Rust의 매크로 언어 대신 Rust 자체를 사용

##### 작은 수정 사항

- `impl<T: Copy> for Range<T>` 수정
- 연관 타입을 가진 `derive` 수정
- `if-let` 표현식에서 논리 AND 지원
- 원시 포인터의 사용성을 개선
- 모든 내장 컬렉션 타입에 `Allocator` 인자를 추가

#### 마무리 생각

- 비동기 기능도 개선이 필요하지만 별도의 포스트가 필요함
- 대부분의 변경 사항은 기존 Rust와 호환되지 않음
- 새로운 Rust 에디션이 필요할 수 있음
- GitHub RFC 프로세스에 지치지 않고 직접 컴파일러를 포크하는 것을 고려 중

#### GN⁺의 정리

- Rust는 초기 매력에도 불구하고 완벽하지 않음
- 언어 발전이 느려지고 많은 불안정한 기능이 안정적인 Rust에 포함되지 않음
- 함수 트레이트, 컴파일 타임 기능, Pin 및 Move 개선 등 다양한 제안이 있음
- 이러한 제안은 Rust의 사용성을 크게 개선할 수 있음
- 비슷한 기능을 가진 다른 언어로는 Zig가 있음

## Comments



### Comment 29261

- Author: neo
- Created: 2024-09-27T09:49:53+09:00
- Points: 1

###### [Hacker News 의견](https://news.ycombinator.com/item?id=41654871) 
- **Rust RFC 프로세스에 대한 의견**
  - Rust 핵심 팀이 새로운 기능 추가를 어렵게 만드는 것은 언어의 일관성과 예측 가능성을 유지하기 위해 옳은 결정임
  - Swift의 경우, 많은 새로운 기능 도입으로 인해 복잡해져서 결국 Swift를 포기하게 되었음
  - Rust는 가능한 한 간결하게 유지하는 것이 중요함

- **Rust의 의존성 문제**
  - Cargo-watch crate의 예를 들어, 간단한 파일 감시 앱이지만 의존성으로 인해 코드 라인이 400만 줄에 달함

- **Rust의 현재 상태**
  - Rust는 이제 "광범위한 채택을 위한 작업" 단계에 있음
  - 느린 기능 개발은 자연스럽고 건강한 현상이며, 잘못된 설계 선택이 더 큰 해를 끼칠 수 있음
  - Rust의 매력은 새로운 기능보다는 메모리 안전성과 GC가 없는 생산 준비된 언어라는 점에 있음

- **Rust의 재작성에 대한 의견**
  - Rust를 Rust로 재작성하는 것은 메타-풍자적 농담으로 보였음

- **Rust의 결정 과정에 대한 불만**
  - 느린 결정 과정에 대한 불만이 있지만, 이는 기술적 문제보다는 사람과 시간의 문제임
  - 일부 오래된 기능은 정체되어 있지만, 많은 기능은 안정화되지 않을 예정임

- **Josh Triplett의 댓글**
  - 특정 예시가 잘못되었음을 지적하며, 관련 링크를 공유함

- **Rust의 복잡성에 대한 의견**
  - Rust는 이미 많은 기능을 가지고 있지만, 더 많은 기능을 요구하는 사람들이 있음
  - Zig는 더 간단하고 빠르며, 커뮤니티의 드라마가 적음

- **Rust의 속도에 대한 의견**
  - 프로젝트가 성숙해지면서 기존 기능을 다듬는 데 많은 노력이 필요함
  - 팀 간의 협력이 어려워졌으며, 이를 개선하기 위한 프로젝트 목표가 있음

- **Mutex 개선에 대한 의견**
  - Rust의 동기화 원시 기능을 개선하기 위해 많은 노력이 있었음
  - 비동기 함수와 같은 기능이 추가되었으며, 이는 더 복잡한 기능을 구현하기 위한 기반이 됨

- **Rust의 기능 개발 속도에 대한 의견**
  - 언어가 너무 빠르게 또는 너무 느리게 발전한다고 불평하는 사람들이 있음
  - 특정 기능은 더디게 진행되지만, 많은 활동이 진행 중임

- **Rust의 기능 설계에 대한 의견**
  - 함수 트레이트와 같은 기능은 최근에 큰 설계 탐구가 있었음
  - 컴파일 타임 기능은 언어 수준에서 해결할 수 없으며, WebAssembly와 같은 솔루션이 더 가능성이 있음

- **Rust의 빌림 검사기 문제**
  - 자기 참조 구조를 이해하는 것은 매우 어려운 문제임
  - 부분 빌림을 지원하는 방법은 이미 알고 있지만, 이를 타입 시스템에 노출하는 것이 문제임

- **Rust의 컴파일 타임 기능**
  - 매크로 규칙을 더 강력하게 만들기 위한 RFC가 작성되었음
  - 프로그램적 구문 분석을 위한 더 많은 작업이 필요함

- **Rust의 불안정한 기능**
  - 많은 불안정한 기능이 있으며, 이를 정리하는 것이 필요함

- **Rust의 발전 속도에 대한 의견**
  - Mozilla의 이탈로 인해 프로젝트가 느려졌지만, 잘못된 길로 가는 것보다는 나음