# Rust를 약 10년 동안 사용하며 (그리고 사랑하며) 느낀 실망스러운 점들

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

## Metadata

- GeekNews HTML: [https://news.hada.io/topic?id=16000](https://news.hada.io/topic?id=16000)
- GeekNews Markdown: [https://news.hada.io/topic/16000.md](https://news.hada.io/topic/16000.md)
- Type: news
- Author: [tsboard](https://news.hada.io/@tsboard)
- Published: 2024-07-24T17:24:40+09:00
- Updated: 2024-07-24T17:24:40+09:00
- Original source: [reddit.com](https://www.reddit.com/r/rust/comments/1e978l7/ive_used_and_loved_rust_for_10_years_here_are_the/)
- Points: 21
- Comments: 5

## Summary

Rust의 오류 처리 방식과 모듈 시스템의 과도한 유연성, 그리고 긴 컴파일 시간과 느린 IDE 도구의 문제점을 지적합니다. 특히, Result<T, E>의 오류 처리 방식이 번거롭고, 모듈 시스템이 실수를 유발할 수 있으며, 대규모 프로젝트에서 컴파일 시간과 IDE 응답 속도가 비효율적이라는 점을 강조합니다.

## Topic Body

Rust를 사용한 지 대략 10년이 되었고, 이 언어를 정말 사랑합니다. 하지만 몇 가지 실망스러운 점들도 존재합니다. 아래는 그 목록입니다.  
  
##### 1. Result<T, E>의 문제  
Rust의 오류 처리가 명확하고 강제적이라는 점은 훌륭합니다. 그러나 실제로 사용하다 보면 불편함이 많습니다.  
  
- **라이브러리 작성자의 어려움**: 새로운 오류 타입을 만들고 변환하는 과정이 번거롭습니다. 종속성을 추가할 때마다 각 함수의 오류 타입을 래퍼 오류 타입에 추가하는 작업은 특히 귀찮습니다.  
- **애플리케이션 코드의 번거로움**: 함수가 왜 실패했는지보다는 오류를 상위로 전파하고 사용자에게 결과를 보여주는 것이 중요합니다. Java와 달리 Rust는 전파 과정에서 백트레이스를 제공하지 않아 문제의 원인을 파악하기 어렵습니다.  
  
##### 2. 모듈 시스템의 유연성  
Rust의 모듈 시스템은 너무 유연하여 오히려 불편할 때가 많습니다.  
  
- **과도한 유연성**: 타입을 재수출하거나 접근 수준을 세밀하게 조정할 수 있지만, 이는 실수로 원하지 않는 타입을 노출시키는 결과를 초래할 수 있습니다.  
- **고아 규칙의 문제**: 프로젝트를 여러 크레이트로 나누는 것이 권장되지만, 고아 규칙이 때때로 방해가 됩니다.  
  
##### 3. 컴파일 시간과 IDE 도구  
Rust의 컴파일 시간과 IDE 도구의 에러 체크가 너무 느립니다.  
  
- **긴 컴파일 시간**: 대규모 프로젝트에서는 한 함수를 수정하면 전체 크레이트가 다시 컴파일되며, 이는 매우 비효율적입니다.  
- **느린 IDE 응답 속도**: Rust analyzer는 타이핑할 때마다 프로젝트를 다시 인덱싱하는 것처럼 느껴지며, 이는 대규모 프로젝트에서 특히 문제가 됩니다.  
  
##### 결론  
Rust는 제가 가장 좋아하는 언어이지만, 이러한 실망스러운 점들도 존재합니다. 다른 사용자들도 같은 문제를 겪고 있는지 궁금합니다.

## Comments



### Comment 27615

- Author: ranolp
- Created: 2024-07-28T10:17:32+09:00
- Points: 2

에러 처리의 경우 라이브러리는 snafu/thiserror, 애플리케이션은 eyre/anyhow를 설치해 쓰면 편리해집니다

### Comment 27581

- Author: y15un
- Created: 2024-07-26T13:22:15+09:00
- Points: 1

> **라이브러리 작성자의 어려움**: [..snip..] 종속성을 추가할 때마다 각 함수의 오류 타입을 래퍼 오류 타입에 추가하는 작업은 특히 귀찮습니다.  
  
이 부분은 정말 뼈저리게 느껴집니다. 크레이트 전용 에러 `enum`을 만들고 의존성에서 당겨오는 에러 타입을 위해 매번 `impl From&lt;ExtError&gt; for Error`를 적으면서 '귀찮아 죽겠네'라고 생각한 적이 한두 번이 아니라서요...

### Comment 27576

- Author: eususu
- Created: 2024-07-26T11:25:09+09:00
- Points: 1

아직 제대로 시작을 못해서 그런가, 이런 실망을 느껴보고 싶군요.  
좋은 글 감사합니다~

### Comment 27544

- Author: undercat
- Created: 2024-07-25T11:05:05+09:00
- Points: 1

좋은 글 감사합니다!

### Comment 27529

- Author: tsboard
- Created: 2024-07-24T17:28:07+09:00
- Points: 5

긴 컴파일 시간에 대해서는 아래의 댓글이 도움이 되실 것 같아 추가합니다: (by pr4wl)  
  
Rust analyzer가 매번 변경할 때마다 긴 재컴파일을 수행한다면, 이는 아마도 애플리케이션을 빌드할 때 사용하는 기능이나 환경 변수가 다르기 때문일 것입니다. 기본적으로 RA는 빌드 아티팩트를 저장하기 위해 cargo build와 동일한 타겟 디렉토리를 사용하며, 서로 호환되지 않는 빌드를 수행하면 계속해서 전체 빌드를 수행하게 됩니다.  
  
이 문제는 특히 Bevy에서 bevy/dynamic_linking 기능을 빌드에 사용하고 있지만 Rust analyzer에는 사용하지 않는 경우에 흔히 발생할 수 있습니다.  
  
가장 간단한 해결 방법은 RA에 다른 타겟 디렉토리를 사용하도록 지시하는 것입니다. 이와 관련된 자세한 내용은 rust-analyzer.cargo.targetDir에서 확인할 수 있습니다.  
  
또 다른 해결 방법은 모든 기능과 환경 변수가 동일하도록 설정하여 서로의 빌드 아티팩트를 재사용할 수 있도록 하는 것입니다. 하지만 이는 까다로울 수 있습니다.