내가 사용하는 M4 Max MacBook이 2009년 기준 TOP500 슈퍼컴퓨터 50위 안에 들었을 것이라는 주장에 대해 검증 시도함
2009년 TOP500에 들려면 75 TFlop/s 이상의 성능이 필요함
M4 Max는 FP32에서 18.4 TFlop/s이지만, TOP500은 FP64(LINPACK)을 사용함
M2 벤치마크 기준으로 FP64는 FP32의 1/4 수준이므로, 대략 9 TFlop/s 예상됨
그 정도론 2009년 TOP500에 못 들어감 2009년 TOP500 목록 참고
각 연결이 동시에 여러 I/O 작업을 하는 경우 수천 개의 연결로 곱셈해야 함
서버는 대략 전체 시간의 95%를 I/O 대기라고 들었지만, 실제로 전체 서버가 아닌 개별 스레드 기준임
실제 서버는 CPU 사용률이 70~80%까지 올라가는 경우가 많음(이 이상이면 tail latency가 급격히 나빠짐)
풀로드에서 CPU 5% 쓰면 병렬 프로세스 부족이나 메모리 부족 문제임
기술적으로 작은 디테일이지만, 이런 실수가 포스트 신뢰성을 떨어뜨릴 수 있음(Bun의 팬 입장에서 말함)
저 결론은 뭔가 LLM이 만들어낸 환각같다는 생각이 듦
결론 부분이 특히 LLM에서 뽑은 듯한 느낌이 있음
"벤치마크한 패키지 매니저들이 잘못된 게 아니라, 그 시절에 맞는 해법이었음을 이해함"
"Bun의 방식은 혁명적이라기보다, 현재 속도가 느려지는 원인을 냉철하게 바라본 결과라는 점이 강조됨"
"패키지 설치가 25배 빨라진 것은 마법이 아니라, 최신 하드웨어에 맞게 툴을 만들었기 때문에 자연스럽게 일어난 현상임"
복잡한 주제임에도 읽기 쉽고 단순하게 잘 설명되어서 너무 좋았음
아직도 열정적인 사람들이 현상 유지를 깨고 어려운 과제에 도전하는 것이 감탄스러움
매달 컴퓨터 하드웨어는 발전하는데 소프트웨어는 더 느려지는 현상이 비정상적으로 느껴짐
효율적인 코딩을 모두가 더 잘했으면 하는 바람임
bun이 Zig로 작성된지 몰랐음
Zig는 굉장히 새로운 언어인데, 실무에서 본격적으로 쓰이는 모습이 흥미로움
bun을 처음 써봤는데 매우 인상적이었음
내장 서버와 SQLite 덕분에 bun 하나만 설치하면 되어서 개발이 훨씬 편함
평소에 vanilla js만 쓰면서도 node 생태계를 별로 좋아하지 않았는데, 더 일찍 bun을 써봤어야 했다고 생각함
Bun을 여러 번 시도해봤는데 사용 경험이 매우 만족스러웠음
Node보다 더 좋게 느꼈음
하지만 항상 결정적인 문제에 부딪히게 되어 결국 Node로 돌아감
처음엔 crypto 모듈이 Nodejs와 호환 안 됐고(지금은 수정됨), 다음엔 Playwright가 Bun에서 작동하지 않았음
요즘 Node도 내장 서버와 SQLite 지원함
더 많은 기능이 필요하다면 Hono도 좋은 대안임
기사에서 리눅스의 하드링크와 MacOS의 clonefile이 동등하다고 설명한 부분이 잘 이해가 안 됨
하드링크의 경우 하나의 복사본을 수정하면 모든 프로젝트의 파일이 예상치 않게 바뀌는 것 아닌지 궁금함
기술적으로 꽤 복잡한 설명인데도 정말 읽기 쉽고 유쾌하게 작성됨에 감탄함
Lydia는 복잡한 개념을 쉽게 전달하는 데 매우 능숙함
그녀의 대부분 작업물과 영상을 봤는데, 깊이 있게 준비하는 게 느껴짐
시간이 된다면 그녀의 아티클과 YouTube 컨텐츠 적극 추천함
최근엔 아마 현 직장 때문에 활동이 줄어든 것 같음
Binary Manifest Caching 섹션에서 "npm (cached)"의 벤치마크 시간이 누락된 것 같음
bun, bun (cached), npm만 있고, 요약 통계도 제대로 안 맞는 것 같음
이 게시물의 문체가 너무 마음에 들었음
io_uring의 중요성을 설명하기에 이 글이 아주 좋은 사례로 리포지션 가능할 것 같음
Zig의 최근 v0.15 io 업데이트가 Bun의 성능에 추가적인 이점을 줄 수 있을지 궁금함
1년 넘게 bun을 기대해오고 있음
2025년이 bun의 대중화 원년이 될 거라 생각했는데, 의외로 아직 그렇게 인기 있지 않음
GitHub 상위 10만개 레포에서 2025년 기준 신규 레포는 npm이 35배, pnpm이 11배 더 많이 쓰임
Deno도 생각보다 인기가 그렇게 높지 않음
이유가 뭘까 궁금함
런타임은 패키지 매니저보다 호환성 맞추기가 더 어렵기 때문인지?
bun을 시도했다가 채택하지 않은 분들의 의견이 듣고 싶음 관련 참고 통계 관련 HN 댓글
Bun과 Deno 둘 다 좋아하고 싶어서 여러 번 시도했지만, 결국 결정적 결함을 만나서 더 이상 못 써본 경험임
최근 Bun에서 겪은 가장 큰 문제는 스트림이 조기에 닫히는 이슈였고 관련 이슈 링크
Deno에선 메모리 누수 문제를 만났음 관련 이슈 링크
결국 Node 생태계가 Bun/Deno의 장점들을 먼저 받아들일 것 같다는 생각임
Bun은 신규 벤처캐피털 자금이 들어간, 검증된 오픈소스 대세 제품(Node)과 경쟁하는 신예임
락인 유인이 있고, 결국 Node와 근본적으로 크게 다르지 않음
전략적인 강점이 뚜렷하지 않고, Node로 할 수 없는 뭔가 새로운 걸 제공하지 않음
실제로 진지하게 쓰는 사례는 못 봤고, 가볍게 쓰는 사례만 봤음
이슈 트래커를 보면 Zig라는 언어가 굉장히 안전하지 않아서 그런지 크래시가 자주 발생함
나는 Node에 남을 예정임
나도 다른 분 의견이 궁금함
내 생각엔 Node는 프로젝트로서 성숙하고, 민주적이며 커뮤니티 주도 느낌이 강함
io.js 포크 사태도 잘 극복했기 때문임
반면 bun이나 deno는 둘 다 VC 지원을 받는 프로젝트라서 민주적인 커뮤니티 주도라고 느껴지지 않음
나는 Bun의 열렬한 팬임
가능한 모든 프로젝트에 Bun을 쓰고, 각종 one-off 스크립트도 Bun/TS로 씀
다만 소수지만 걱정되는 이슈가 있어서 프로덕션 배포는 아직 망설여짐
예를 들어, 단순한 Express 웹서버를 Docker에서 띄웠을 때 bun으로 구동하면 멈추는 현상이 있었음
node로만 바꾸면 정상작동함
1년 전엔 Bun + Prisma 조합에서 메모리 누수로 서버가 죽는 현상도 있었음(아마 지금은 고쳐졌으리라 예상함)
그럼에도 Bun이 워낙 좋아서 이런 단점 감수해도 전체적으로 개발 시간을 줄여줌
트랜스파일, 모듈, 워크스페이스 등에서 오는 편의성이 엄청남
아직 npm만큼 대중화되지 않은 것도 충분히 이해함
이 글을 읽는 게 너무 즐거웠음
소프트웨어 개발에서 컴퓨터과학 원리가 실제로 얼마나 중요한지 잘 보여주는 사례임
Big O, 시간/공간 지역성, 알고리즘 복잡도, 유저/커널스페이스, 파일 시스템, copy-on-write 등
이런 저수준 패키지 개발에선 CS 프로그램에서 배우는 모든 개념이 실제로 활용됨
이건 사실 컴퓨터과학(CS)이 아니라 소프트웨어공학(SE)에 가까움
CS는 계산과 이론(프로그래밍 언어, 알고리즘, 암호화, 머신러닝 등)을 연구하고
SE는 확장성 있고 신뢰성 높은 소프트웨어를 구축하는 엔지니어링 원칙을 적용함
압축 파일을 다 읽고 나서 풀기를 기다리는 게 왜 유리한지 잘 이해가 안 됨
다운로드가 끝나기 전부터 압축 해제를 시작하는 게 메모리 재복사 횟수 늘어나는 불이익보다 도리어 더 이득이 있을 것이라고 추정함
Hacker News 의견
내가 사용하는 M4 Max MacBook이 2009년 기준 TOP500 슈퍼컴퓨터 50위 안에 들었을 것이라는 주장에 대해 검증 시도함
2009년 TOP500에 들려면 75 TFlop/s 이상의 성능이 필요함
M4 Max는 FP32에서 18.4 TFlop/s이지만, TOP500은 FP64(LINPACK)을 사용함
M2 벤치마크 기준으로 FP64는 FP32의 1/4 수준이므로, 대략 9 TFlop/s 예상됨
그 정도론 2009년 TOP500에 못 들어감
2009년 TOP500 목록 참고
각 연결이 동시에 여러 I/O 작업을 하는 경우 수천 개의 연결로 곱셈해야 함
서버는 대략 전체 시간의 95%를 I/O 대기라고 들었지만, 실제로 전체 서버가 아닌 개별 스레드 기준임
실제 서버는 CPU 사용률이 70~80%까지 올라가는 경우가 많음(이 이상이면 tail latency가 급격히 나빠짐)
풀로드에서 CPU 5% 쓰면 병렬 프로세스 부족이나 메모리 부족 문제임
기술적으로 작은 디테일이지만, 이런 실수가 포스트 신뢰성을 떨어뜨릴 수 있음(Bun의 팬 입장에서 말함)
저 결론은 뭔가 LLM이 만들어낸 환각같다는 생각이 듦
결론 부분이 특히 LLM에서 뽑은 듯한 느낌이 있음
"벤치마크한 패키지 매니저들이 잘못된 게 아니라, 그 시절에 맞는 해법이었음을 이해함"
"Bun의 방식은 혁명적이라기보다, 현재 속도가 느려지는 원인을 냉철하게 바라본 결과라는 점이 강조됨"
"패키지 설치가 25배 빨라진 것은 마법이 아니라, 최신 하드웨어에 맞게 툴을 만들었기 때문에 자연스럽게 일어난 현상임"
복잡한 주제임에도 읽기 쉽고 단순하게 잘 설명되어서 너무 좋았음
아직도 열정적인 사람들이 현상 유지를 깨고 어려운 과제에 도전하는 것이 감탄스러움
매달 컴퓨터 하드웨어는 발전하는데 소프트웨어는 더 느려지는 현상이 비정상적으로 느껴짐
효율적인 코딩을 모두가 더 잘했으면 하는 바람임
Zig는 굉장히 새로운 언어인데, 실무에서 본격적으로 쓰이는 모습이 흥미로움
bun을 처음 써봤는데 매우 인상적이었음
내장 서버와 SQLite 덕분에 bun 하나만 설치하면 되어서 개발이 훨씬 편함
평소에 vanilla js만 쓰면서도 node 생태계를 별로 좋아하지 않았는데, 더 일찍 bun을 써봤어야 했다고 생각함
Bun을 여러 번 시도해봤는데 사용 경험이 매우 만족스러웠음
Node보다 더 좋게 느꼈음
하지만 항상 결정적인 문제에 부딪히게 되어 결국 Node로 돌아감
처음엔 crypto 모듈이 Nodejs와 호환 안 됐고(지금은 수정됨), 다음엔 Playwright가 Bun에서 작동하지 않았음
요즘 Node도 내장 서버와 SQLite 지원함
더 많은 기능이 필요하다면 Hono도 좋은 대안임
기사에서 리눅스의 하드링크와 MacOS의 clonefile이 동등하다고 설명한 부분이 잘 이해가 안 됨
하드링크의 경우 하나의 복사본을 수정하면 모든 프로젝트의 파일이 예상치 않게 바뀌는 것 아닌지 궁금함
기술적으로 꽤 복잡한 설명인데도 정말 읽기 쉽고 유쾌하게 작성됨에 감탄함
그녀의 대부분 작업물과 영상을 봤는데, 깊이 있게 준비하는 게 느껴짐
시간이 된다면 그녀의 아티클과 YouTube 컨텐츠 적극 추천함
최근엔 아마 현 직장 때문에 활동이 줄어든 것 같음
Binary Manifest Caching 섹션에서 "npm (cached)"의 벤치마크 시간이 누락된 것 같음
bun, bun (cached), npm만 있고, 요약 통계도 제대로 안 맞는 것 같음
이 게시물의 문체가 너무 마음에 들었음
io_uring의 중요성을 설명하기에 이 글이 아주 좋은 사례로 리포지션 가능할 것 같음
Zig의 최근 v0.15 io 업데이트가 Bun의 성능에 추가적인 이점을 줄 수 있을지 궁금함
1년 넘게 bun을 기대해오고 있음
2025년이 bun의 대중화 원년이 될 거라 생각했는데, 의외로 아직 그렇게 인기 있지 않음
GitHub 상위 10만개 레포에서 2025년 기준 신규 레포는 npm이 35배, pnpm이 11배 더 많이 쓰임
Deno도 생각보다 인기가 그렇게 높지 않음
이유가 뭘까 궁금함
런타임은 패키지 매니저보다 호환성 맞추기가 더 어렵기 때문인지?
bun을 시도했다가 채택하지 않은 분들의 의견이 듣고 싶음
관련 참고 통계
관련 HN 댓글
Bun과 Deno 둘 다 좋아하고 싶어서 여러 번 시도했지만, 결국 결정적 결함을 만나서 더 이상 못 써본 경험임
최근 Bun에서 겪은 가장 큰 문제는 스트림이 조기에 닫히는 이슈였고
관련 이슈 링크
Deno에선 메모리 누수 문제를 만났음
관련 이슈 링크
결국 Node 생태계가 Bun/Deno의 장점들을 먼저 받아들일 것 같다는 생각임
Bun은 신규 벤처캐피털 자금이 들어간, 검증된 오픈소스 대세 제품(Node)과 경쟁하는 신예임
락인 유인이 있고, 결국 Node와 근본적으로 크게 다르지 않음
전략적인 강점이 뚜렷하지 않고, Node로 할 수 없는 뭔가 새로운 걸 제공하지 않음
실제로 진지하게 쓰는 사례는 못 봤고, 가볍게 쓰는 사례만 봤음
이슈 트래커를 보면 Zig라는 언어가 굉장히 안전하지 않아서 그런지 크래시가 자주 발생함
나는 Node에 남을 예정임
나도 다른 분 의견이 궁금함
내 생각엔 Node는 프로젝트로서 성숙하고, 민주적이며 커뮤니티 주도 느낌이 강함
io.js 포크 사태도 잘 극복했기 때문임
반면 bun이나 deno는 둘 다 VC 지원을 받는 프로젝트라서 민주적인 커뮤니티 주도라고 느껴지지 않음
나는 Bun의 열렬한 팬임
가능한 모든 프로젝트에 Bun을 쓰고, 각종 one-off 스크립트도 Bun/TS로 씀
다만 소수지만 걱정되는 이슈가 있어서 프로덕션 배포는 아직 망설여짐
예를 들어, 단순한 Express 웹서버를 Docker에서 띄웠을 때 bun으로 구동하면 멈추는 현상이 있었음
node로만 바꾸면 정상작동함
1년 전엔 Bun + Prisma 조합에서 메모리 누수로 서버가 죽는 현상도 있었음(아마 지금은 고쳐졌으리라 예상함)
그럼에도 Bun이 워낙 좋아서 이런 단점 감수해도 전체적으로 개발 시간을 줄여줌
트랜스파일, 모듈, 워크스페이스 등에서 오는 편의성이 엄청남
아직 npm만큼 대중화되지 않은 것도 충분히 이해함
이 글을 읽는 게 너무 즐거웠음
소프트웨어 개발에서 컴퓨터과학 원리가 실제로 얼마나 중요한지 잘 보여주는 사례임
Big O, 시간/공간 지역성, 알고리즘 복잡도, 유저/커널스페이스, 파일 시스템, copy-on-write 등
이런 저수준 패키지 개발에선 CS 프로그램에서 배우는 모든 개념이 실제로 활용됨
CS는 계산과 이론(프로그래밍 언어, 알고리즘, 암호화, 머신러닝 등)을 연구하고
SE는 확장성 있고 신뢰성 높은 소프트웨어를 구축하는 엔지니어링 원칙을 적용함
압축 파일을 다 읽고 나서 풀기를 기다리는 게 왜 유리한지 잘 이해가 안 됨
다운로드가 끝나기 전부터 압축 해제를 시작하는 게 메모리 재복사 횟수 늘어나는 불이익보다 도리어 더 이득이 있을 것이라고 추정함