TIL: esbuild의 처리 방식

swc의 변수 처리 패스를 병렬화하려고 고민하다가, esbuild에 좋은 구현체가 있을 것 같아서 그걸 참고하려고 소스코드를 봤다.

근데 보다보니까 뭔가 모듈 개수가 너무 적었다. 그리고 transform에 관련된 것처럼 보이는 모듈이 하나도 없었다.

swc 모듈은 이렇게 많은데 말이다.

그래서 대충 훑어보니 JsFeature이라는 타입이 있었다. 그 타입으로 검색하면 관련 모듈들이 나올테니 그걸로 검색해봤는데, 역시 transform에 관련된 모듈이 없었다. 그러면 파서나 렉서에서 처리한다는 것일거고, 마침 검색 결과에 파서도 있길래 봤다.

보니까 파서에서 최신 문법을 처리하고 있었다. 솔직히 이걸 보고 좀 실망했다. 실망한 이유는 최근에 내가 러스트의 가성비가 안좋다는 생각을 하고있었기 때문인데, 구체적으로 말하자면

제약에 비하면 최적화가 잘 안되는 것 아닌가

go로 swc를 짰으면 훨씬 더 빠르지 않았을까

이런 생각들이었다. 두번째는 &mut 두 개 못 만드는 제약이 너무 빡세서 러스트로 짜다보면 병렬화가 제한받는 경우가 많은데 그런 경우에 차라리 다른 언어로 병렬 처리를 하는 게 낫지 않았을까하는 소리다.

근데 절대 아니라는 걸 깨달았고, 그게 실망한 이유이다.

swc나 타입스크립트 타입 체커는 '러스트라서' 구현하기 어려웠다. 그래서 좀 쉬운 go 같은 언어로 다시 짜는 게 낫지 않을까하는 일말의 희망? 같은 게 있었다. 그런데 절대 아니다. 내 성격에 제너릭도 없는 언어에서 esbuild처럼 파서에서 신규 문법을 처리하진 않았을 것이고, 당연히 지금보다 훨씬 느렸을 것이다.