울이

Love Code. Work. Sports.

7 분 소요

Script 소개: Rust처럼 실행되는 JavaScript

JavaScript 생태계에 또 하나의 “JavaScript 대체재”가 등장했다. 이번에는 좀 다르다. Script는 JavaScript 문법을 유지하면서 Rust 수준의 성능을 약속하는 새로운 언어다. Reddit r/programming에서 104점을 기록하며 개발자들 사이에서 뜨거운 논쟁을 불러일으키고 있다. 솔직히 말해서, 또 하나의 “X를 대체하겠다”는 프로젝트인가 싶었는데, 기술적 접근 방식이 꽤 흥미롭다.

Script가 해결하려는 문제

JavaScript의 가장 큰 약점은 명확하다: 런타임 성능과 타입 안정성. TypeScript가 타입 문제를 어느 정도 해결했지만, 결국 JavaScript로 컴파일되기 때문에 런타임 성능 향상은 없다. V8 엔진이 아무리 최적화되어도 가비지 컬렉션 오버헤드와 동적 타입 체크는 피할 수 없다.

Script는 이 문제를 근본적으로 다른 방식으로 접근한다. JavaScript 문법을 파싱해서 네이티브 바이너리로 AOT(Ahead-of-Time) 컴파일한다. TypeScript처럼 타입을 추가하는 게 아니라, JavaScript 코드 자체를 정적 분석해서 타입을 추론하고 최적화된 머신 코드를 생성한다.

// 일반 JavaScript 코드
function fibonacci(n) {
  if (n <= 1) return n;
  return fibonacci(n - 1) + fibonacci(n - 2);
}

// Script 컴파일러가 이 코드를 분석해서
// n이 항상 숫자라는 것을 추론하고
// 네이티브 바이너리로 컴파일

핵심 기술: 타입 추론과 AOT 컴파일

Script의 핵심은 flow-sensitive 타입 추론 시스템이다. 코드의 실행 흐름을 분석해서 각 변수의 타입을 추적한다. 이게 TypeScript의 타입 추론과 다른 점은, 런타임 동작까지 예측해서 최적화한다는 것이다.

// Script가 분석하는 방식
function process(data) {
  if (typeof data === 'string') {
    // 이 블록 안에서 data는 string으로 확정
    return data.toUpperCase();
  }
  if (Array.isArray(data)) {
    // 이 블록 안에서 data는 Array로 확정
    return data.map(x => x * 2);
  }
  return data;
}

컴파일러는 이런 타입 가드 패턴을 인식하고, 각 분기에 대해 별도로 최적화된 코드를 생성한다. 동적 디스패치 대신 정적 디스패치를 사용하기 때문에 함수 호출 오버헤드가 크게 줄어든다.

Rust의 LLVM 백엔드를 활용한다는 점도 주목할 만하다. LLVM의 수십 년간 축적된 최적화 패스를 그대로 활용할 수 있다. 인라이닝, 루프 언롤링, SIMD 벡터화 등이 자동으로 적용된다.

실제 성능 차이

벤치마크 결과를 보면 꽤 인상적이다. 피보나치 같은 순수 계산 작업에서는 Node.js 대비 10-50배 빠르다고 주장한다. 물론 이런 마이크로벤치마크는 항상 의심해야 한다. 실제 애플리케이션에서는 I/O 바운드 작업이 대부분이기 때문에 체감 성능 향상은 더 적을 것이다.

// CPU 집약적 작업에서 성능 차이가 극대화됨
function matrixMultiply(a, b) {
  const rows = a.length;
  const cols = b[0].length;
  const result = [];
  
  for (let i = 0; i < rows; i++) {
    result[i] = [];
    for (let j = 0; j < cols; j++) {
      let sum = 0;
      for (let k = 0; k < a[0].length; k++) {
        sum += a[i][k] * b[k][j];
      }
      result[i][j] = sum;
    }
  }
  return result;
}

이런 행렬 연산 코드에서는 차이가 극명하다. V8은 히든 클래스 최적화와 인라인 캐싱을 아무리 해도, 배열 바운드 체크와 타입 체크를 런타임에 수행해야 한다. Script는 컴파일 타임에 이 모든 것을 해결한다.

현실적인 한계점

솔직히 말해서, Script가 JavaScript를 완전히 대체할 가능성은 낮다. 몇 가지 근본적인 한계가 있다.

동적 기능 제한: eval(), new Function(), 동적 프로퍼티 접근 같은 JavaScript의 동적 기능은 제대로 지원하기 어렵다. 정적 분석이 불가능하기 때문이다.

// 이런 코드는 Script에서 문제가 될 수 있음
const methodName = getUserInput();
obj[methodName](); // 동적 메서드 호출

// 이것도 마찬가지
const code = fetchCodeFromServer();
eval(code);

생태계 호환성: npm 패키지 대부분은 Script를 고려하지 않고 작성됐다. 동적 기능을 많이 사용하는 라이브러리는 제대로 컴파일되지 않을 것이다.

디버깅 복잡성: 네이티브 바이너리 디버깅은 JavaScript 디버깅보다 훨씬 어렵다. 소스맵 지원이 있다고 해도 런타임 상태를 확인하기가 까다롭다.

어디에 쓸 수 있을까

Script가 빛을 발할 수 있는 영역은 명확하다:

  1. CLI 도구: 빠른 시작 시간과 낮은 메모리 사용량이 중요한 곳
  2. 데이터 처리 파이프라인: CPU 집약적 변환 작업
  3. 게임 로직: 프레임마다 실행되는 연산 코드
  4. 서버리스 함수: 콜드 스타트 시간 단축
// CLI 도구 예시 - 빠른 시작이 중요
#!/usr/bin/env script

const args = process.argv.slice(2);
const files = args.filter(f => f.endsWith('.json'));

files.forEach(file => {
  const data = JSON.parse(readFileSync(file));
  // 처리 로직...
  console.log(`Processed: ${file}`);
});

결론: 기대하되 현실적으로

Script는 흥미로운 실험이다. JavaScript 문법의 친숙함을 유지하면서 네이티브 성능을 얻을 수 있다는 아이디어는 매력적이다. 하지만 JavaScript의 동적 특성을 정적 언어로 컴파일하려는 시도는 항상 트레이드오프가 있다.

내 생각에 Script는 “JavaScript 킬러”가 아니라 “JavaScript 보완재”로 자리 잡을 가능성이 높다. 특정 성능 크리티컬한 부분만 Script로 작성하고, 나머지는 기존 JavaScript/TypeScript 생태계를 그대로 활용하는 하이브리드 접근이 현실적이다.

JavaScript 개발자라면 관심을 가지고 지켜볼 만하다. 당장 프로덕션에 도입하기보다는 사이드 프로젝트에서 실험해보는 것을 추천한다. 성능이 중요한 특정 모듈에서부터 시작해보자.

Introducing Script: JavaScript That Runs Like Rust

Another “JavaScript replacement” has emerged in the JavaScript ecosystem. This time, it’s different. Script is a new language that promises Rust-level performance while maintaining JavaScript syntax. It’s sparked heated debate among developers on Reddit r/programming with a score of 104. Honestly, I thought it was yet another “we’ll replace X” project, but the technical approach is quite interesting.

The Problem Script Tries to Solve

JavaScript’s biggest weaknesses are clear: runtime performance and type safety. TypeScript solved the type problem to some extent, but since it compiles to JavaScript anyway, there’s no runtime performance improvement. No matter how optimized V8 gets, garbage collection overhead and dynamic type checking are unavoidable.

Script takes a fundamentally different approach to this problem. It parses JavaScript syntax and AOT (Ahead-of-Time) compiles it to native binaries. Instead of adding types like TypeScript, it statically analyzes the JavaScript code itself to infer types and generate optimized machine code.

// Regular JavaScript code
function fibonacci(n) {
  if (n <= 1) return n;
  return fibonacci(n - 1) + fibonacci(n - 2);
}

// Script compiler analyzes this code,
// infers that n is always a number,
// and compiles to native binary

Core Technology: Type Inference and AOT Compilation

The core of Script is its flow-sensitive type inference system. It analyzes the execution flow of code to track the type of each variable. What differentiates this from TypeScript’s type inference is that it predicts runtime behavior for optimization.

// How Script analyzes code
function process(data) {
  if (typeof data === 'string') {
    // Inside this block, data is confirmed as string
    return data.toUpperCase();
  }
  if (Array.isArray(data)) {
    // Inside this block, data is confirmed as Array
    return data.map(x => x * 2);
  }
  return data;
}

The compiler recognizes these type guard patterns and generates separately optimized code for each branch. Because it uses static dispatch instead of dynamic dispatch, function call overhead is significantly reduced.

It’s also worth noting that it leverages Rust’s LLVM backend. This means it can utilize decades of accumulated LLVM optimization passes. Inlining, loop unrolling, SIMD vectorization are automatically applied.

Real Performance Differences

The benchmark results are quite impressive. For pure computational tasks like fibonacci, they claim 10-50x faster than Node.js. Of course, you should always be skeptical of such microbenchmarks. In real applications, most work is I/O bound, so perceived performance gains will be smaller.

// Performance difference maximized in CPU-intensive work
function matrixMultiply(a, b) {
  const rows = a.length;
  const cols = b[0].length;
  const result = [];
  
  for (let i = 0; i < rows; i++) {
    result[i] = [];
    for (let j = 0; j < cols; j++) {
      let sum = 0;
      for (let k = 0; k < a[0].length; k++) {
        sum += a[i][k] * b[k][j];
      }
      result[i][j] = sum;
    }
  }
  return result;
}

The difference is stark in matrix operations like this. V8, no matter how much hidden class optimization and inline caching it does, still has to perform array bounds checks and type checks at runtime. Script resolves all of this at compile time.

Realistic Limitations

Frankly speaking, the likelihood of Script completely replacing JavaScript is low. There are several fundamental limitations.

Dynamic Feature Restrictions: JavaScript’s dynamic features like eval(), new Function(), and dynamic property access are difficult to support properly. Static analysis is impossible for these.

// Code like this could be problematic in Script
const methodName = getUserInput();
obj[methodName](); // Dynamic method call

// This too
const code = fetchCodeFromServer();
eval(code);

Ecosystem Compatibility: Most npm packages were written without Script in mind. Libraries that heavily use dynamic features won’t compile properly.

Debugging Complexity: Native binary debugging is much harder than JavaScript debugging. Even with source map support, inspecting runtime state is tricky.

Where Can It Be Used

The areas where Script can shine are clear:

  1. CLI Tools: Where fast startup time and low memory usage matter
  2. Data Processing Pipelines: CPU-intensive transformation tasks
  3. Game Logic: Computation code that runs every frame
  4. Serverless Functions: Reducing cold start time
// CLI tool example - fast startup matters
#!/usr/bin/env script

const args = process.argv.slice(2);
const files = args.filter(f => f.endsWith('.json'));

files.forEach(file => {
  const data = JSON.parse(readFileSync(file));
  // Processing logic...
  console.log(`Processed: ${file}`);
});

Conclusion: Be Excited, But Realistic

Script is an interesting experiment. The idea of getting native performance while maintaining the familiarity of JavaScript syntax is attractive. However, attempts to compile JavaScript’s dynamic nature into a static language always come with tradeoffs.

In my opinion, Script is more likely to establish itself as a “JavaScript complement” rather than a “JavaScript killer.” A hybrid approach where you write only specific performance-critical parts in Script while using the existing JavaScript/TypeScript ecosystem for the rest is realistic.

If you’re a JavaScript developer, it’s worth keeping an eye on. Rather than adopting it in production immediately, I recommend experimenting with it in side projects. Start with specific modules where performance matters.

댓글남기기

참고