진짜 핵심은 Rust보다 TypeScript가 아니라, O(N²)에서 O(N) 으로 줄인 스트리밍 알고리즘 수정임
문(statement) 단위 캐싱으로 이뤄진 이 변경만으로도 3.3배 향상이 있었음
언어 선택과는 별개로, 사용자 입장에서 느끼는 지연(latency) 개선의 주된 요인은 이 부분임
제목이 이런 흥미로운 엔지니어링 포인트를 과소평가한 느낌임
uv 프로젝트도 마찬가지임. 사람들은 “rust rulez!”만 외치지만, 실제 이득은 언어가 아니라 알고리즘 개선에서 나옴
클릭베이트를 뚫고 본질을 짚어줘서 고마움
글 자체는 흥미롭지만, 요즘엔 과도한 클릭 유도형 제목에 지쳐 있음
n² 표현은 다소 과장된 듯함
각 호출 시간을 측정하고 중앙값(median) 을 쓰는 방식인데, 브라우저 환경에서 타이밍 공격 방어 로직이 있는 JS 엔진이라 정확도에 의문이 있음
결국 오해를 부르는 제목에 가깝다고 생각함
“언어 L에서 M으로 코드를 다시 썼더니 빨라졌다”는 말은 당연한 결과임
얽히고 잘못된 결정을 바로잡고, 새로 생긴 더 나은 접근법을 적용할 기회였기 때문임
사실 L=M이어도 마찬가지로, 속도 향상은 언어가 아니라 리라이트와 재설계 과정에서 나오는 것임
이제 제3자가 원본을 모르는 상태에서 TypeScript 버전을 Rust로 다시 리라이트하면 또 성능이 오를지도 모름
같은 언어로 다시 써도 개선 효과가 생기는 걸 자주 봄
Rust와 JS 경계에서 객체 직렬화 성능을 개선하려고 더 깊이 파봤음
serde의 접근 방식이 성능상 좋지 않아 보였고, 이를 개선한 시도를 내 블로그 글에 정리했음
Open UI가 WASM 관련 작업을 안 하는 이유가 궁금했음
그런데 이번 새 회사가 Open UI라는 이름을 써서 혼란스러웠음
원래 Open UI W3C Community Group은 5년 넘게 HTML의 popover, 커스터마이즈 가능한 select, invoker command, accordion 같은 표준을 만드는 그룹임
그들은 정말 훌륭한 일을 하고 있음
“JSON 왕복을 건너뛰자”는 시도에서 serde-wasm-bindgen을 통합했다는데, 결국 바이너리 형태의 JSON 재발명처럼 보임
요즘 V8의 JSON은 이미 매우 최적화되어 있고, simdjson 같은 구현은 초당 기가바이트 단위로 처리 가능함
JSON이 병목일 가능성은 낮다고 봄
그 블로그의 디자인이 정말 마음에 들었음
스크롤 위치에 따라 헤딩을 하이라이트하는 ‘scrollspy’ 사이드바가 특히 좋았음
Claude가 알려준 바로는 fumadocs.dev로 만든 것 같음
흥미로움. 나도 곧 좋은 문서 사이트를 만들어야겠다고 생각함
Rust WASM 파서의 목적이 잘 이해되지 않았음
글에서 그 부분이 명확하지 않아 더 설명이 필요함
LLM이 생성한 UI 컴포넌트를 정의하는 전용 언어를 사용한다고 함
이는 프롬프트 인젝션으로 인한 정보 유출을 막기 위한 것으로 보임
파서는 LLM에서 스트리밍되는 청크를 컴파일해 실시간 UI를 구성함
이전에는 청크마다 파서를 처음부터 다시 시작했는데, 이를 점진적 처리 방식으로 바꾸면서 (Rust→TypeScript 포팅 중) 성능이 크게 향상되었음
TypeScript가 요즘 Golang 기반으로 돌아가는 게 아닌가 하는 의문이 있었음
TypeScript 컴파일러를 Go로 다시 쓰는 프로젝트가 진행 중인데, 그걸 말하는 것 같음
Hacker News 의견들
진짜 핵심은 Rust보다 TypeScript가 아니라, O(N²)에서 O(N) 으로 줄인 스트리밍 알고리즘 수정임
문(statement) 단위 캐싱으로 이뤄진 이 변경만으로도 3.3배 향상이 있었음
언어 선택과는 별개로, 사용자 입장에서 느끼는 지연(latency) 개선의 주된 요인은 이 부분임
제목이 이런 흥미로운 엔지니어링 포인트를 과소평가한 느낌임
글 자체는 흥미롭지만, 요즘엔 과도한 클릭 유도형 제목에 지쳐 있음
각 호출 시간을 측정하고 중앙값(median) 을 쓰는 방식인데, 브라우저 환경에서 타이밍 공격 방어 로직이 있는 JS 엔진이라 정확도에 의문이 있음
“언어 L에서 M으로 코드를 다시 썼더니 빨라졌다”는 말은 당연한 결과임
얽히고 잘못된 결정을 바로잡고, 새로 생긴 더 나은 접근법을 적용할 기회였기 때문임
사실 L=M이어도 마찬가지로, 속도 향상은 언어가 아니라 리라이트와 재설계 과정에서 나오는 것임
Rust와 JS 경계에서 객체 직렬화 성능을 개선하려고 더 깊이 파봤음
serde의 접근 방식이 성능상 좋지 않아 보였고, 이를 개선한 시도를 내 블로그 글에 정리했음
Open UI가 WASM 관련 작업을 안 하는 이유가 궁금했음
그런데 이번 새 회사가 Open UI라는 이름을 써서 혼란스러웠음
원래 Open UI W3C Community Group은 5년 넘게 HTML의 popover, 커스터마이즈 가능한 select, invoker command, accordion 같은 표준을 만드는 그룹임
그들은 정말 훌륭한 일을 하고 있음
“JSON 왕복을 건너뛰자”는 시도에서 serde-wasm-bindgen을 통합했다는데, 결국 바이너리 형태의 JSON 재발명처럼 보임
요즘 V8의 JSON은 이미 매우 최적화되어 있고, simdjson 같은 구현은 초당 기가바이트 단위로 처리 가능함
JSON이 병목일 가능성은 낮다고 봄
그 블로그의 디자인이 정말 마음에 들었음
스크롤 위치에 따라 헤딩을 하이라이트하는 ‘scrollspy’ 사이드바가 특히 좋았음
Claude가 알려준 바로는 fumadocs.dev로 만든 것 같음
Rust WASM 파서의 목적이 잘 이해되지 않았음
글에서 그 부분이 명확하지 않아 더 설명이 필요함
이는 프롬프트 인젝션으로 인한 정보 유출을 막기 위한 것으로 보임
파서는 LLM에서 스트리밍되는 청크를 컴파일해 실시간 UI를 구성함
이전에는 청크마다 파서를 처음부터 다시 시작했는데, 이를 점진적 처리 방식으로 바꾸면서 (Rust→TypeScript 포팅 중) 성능이 크게 향상되었음
TypeScript가 요즘 Golang 기반으로 돌아가는 게 아닌가 하는 의문이 있었음
농담이지만, 다시 Rust로 리라이트하면 또 3배 성능 향상이 있을지도 모르겠음 /s