Nim vs Rust: 언어는 '일관성'의 문제이며, '성능'이 아니다

Source: Dev.to

Introduction

저는 한때 정식 검증 엔진의 기반으로 Rust와 Nim 중 어느 언어를 사용할지 오랫동안 논쟁했습니다.
두 언어를 비교할 때 대화는 보통 “Rust의 메모리 안전성 vs. Nim의 C‑호환성 및 생산성”으로 귀결됩니다.

AI가 코드를 생성하는 환경에서 가장 무서운 병목 현상은 컴파일 오류가 아니라 의미적 불투명성입니다.

“Rust는 메모리 손상을 방지하고, Nim은 의도 손상을 방지한다.”

Rust는 확실히 의미를 표현할 수 있습니다(예: Typestate나 Newtype 패턴 사용). 하지만 그 의도를 표현하기 위해서는 높은 인지 비용이 필요합니다. 반면 Nim은 일부 생태계 규모와 매크로 디버깅의 어려움을 포기하고 언어 수준에서 더 명확한 의도를 제공합니다.

Cognitive Load When Reviewing AI‑Generated Code

LLM이 생성한 코드를 검토할 때 우리의 인지 자원은 엄격히 제한됩니다.

Rust Example

fn explore(
    step: usize,
    trace: &'a BmcTrace,
    verdict: BmcVerdict,
    rule: &'a TransitionRule,
) -> BmcVerdict {
    // …
}

이 코드를 읽는 동안 리뷰어는 라이프타임('a), 참조 가변성, 그리고 빌림 검사기 제약을 추적해야 합니다. 질문은 도메인 로직이 잘못된 건가, 아니면 코드가 단지 빌림 검사기를 만족시키기 위해 구조화된 건가가 됩니다.

Nim Example

func explore(step: int; trace: BmcTrace;
             verdict: BmcVerdict;
             rule: TransitionRule): BmcVerdict {.raises: [].} =
  # …

여기서는 주변 문법보다 도메인 변수와 의미적 제약에 집중하게 됩니다. 로직의 인과관계가 바로 앞에 드러납니다.

Encoding Intent Directly in the Language

전선에서 가장 고통스러운 순간은 주석이나 커밋 메시지를 파헤쳐 왜 특정 방식으로 코드를 작성했는지를 찾아내는 일입니다. Nim은 그 “왜”를 언어 자체에 녹여 넣을 수 있게 해줍니다.

Distinct Types

type
  SessionId = distinct string
  OwnerId   = distinct string

distinct는 단순 별칭이 아니라 새로운 타입을 생성합니다. AI가 실수로 OwnerId를 SessionId가 기대되는 곳에 전달하면, 컴파일러가 즉시 오류를 잡아줍니다—런타임 테스트가 진행되기 훨씬 전에.

Contracts and Preconditions

func toSessionId*(raw: string): Result[SessionId, AxiomError] {.
  raises: [],
  requires: raw.len > 0,
  ensures: (not result.isOk()) or
           (sessionIdString(result.get()) == raw)
.}

이것은 단순한 문서 주석이 아니라 컴파일 타임에 강제되는 계약입니다. func 키워드는 모듈 수준에서 부작용이 없음을 보장해, 의도를 기본적으로 드러나게 합니다.

When to Choose Rust

성능이나 커뮤니티 규모가 가장 중요한 요소라면 Rust는 의심할 여지 없이 훌륭한 선택입니다. 메모리 안전성의 확실한 바닥을 제공하고 방대한 생태계를 갖추고 있습니다.

Why Nim Won for the Author

Axiom 검증 엔진을 구축하면서, AI‑보조 개발 시대에 가장 큰 위험은 안전하지 않은 코드가 아니라 코드의 의도를 실행해 보기 전까지 알 수 없는 코드라는 생각이 들었습니다. 질문은 다음과 같습니다:

코드 한 줄 한 줄을 읽지 않고도 저자의 의도를 구조적으로 파악할 수 있는가?

저는 그 점을 타협하고 싶지 않았습니다. Nim은 때때로 다소 거칠어 보일지라도 일관성의 한계를 넘어 “왜”라는 부분을 코드에 직접 드러내게 해줍니다. 그래서 저는 Nim을 선택했습니다.