Tôi lo ngại về Bun

(wwj.dev)

4 điểm bởi GN⁺ 7 giờ trước | 3 bình luận | Chia sẻ qua WhatsApp

Bun là một runtime JavaScript nhanh và cũng là công cụ giúp làm việc với TypeScript thuận tiện hơn, nhưng sau thương vụ Anthropic mua lại vào tháng 12 năm 2025, ngày càng xuất hiện nhiều lo ngại rằng nó có thể bị ảnh hưởng bởi chính sách sản phẩm và cách vận hành
Trong thông báo mua lại, phía công ty cho biết Bun sẽ tiếp tục giữ tính mã nguồn mở và giấy phép MIT, cùng một đội ngũ sẽ tiếp tục phát triển; đồng thời vì Claude Code được phát hành dưới dạng tệp thực thi Bun nên Anthropic có động lực trực tiếp để duy trì Bun ổn định
Từ sau tháng 4 năm 2026, Claude Code bị nêu ra các vấn đề như chất lượng suy giảm, hành vi bị giới hạn, hạn chế với harness bên thứ ba, tính phí gây bối rối và giao tiếp chậm; engineering postmortem của Anthropic xem các vấn đề ở lớp sản phẩm như giảm giá trị nỗ lực suy luận mặc định và thay đổi prompt là nguyên nhân
Theo các bài viết của TechCrunch và Gigazine, Claude Code có thể yêu cầu trả thêm phí để hỗ trợ harness bên thứ ba như OpenClaw, hoặc chỉ cần có nhắc đến OpenClaw trong lịch sử git cũng có thể khiến yêu cầu bị từ chối hoặc phát sinh tính phí bổ sung, cho thấy hành vi ngoài dự đoán
Mối bất an không nằm ở bản thân Bun hay chất lượng của đội ngũ Bun, mà ở khả năng chính sách của Anthropic có thể thấm vào Bun; vì thế một số dự án đã chuyển sang dùng pnpm cho việc quản lý gói và cũng bắt đầu khuyến nghị pnpm cho các dự án JavaScript·TypeScript mới

Bối cảnh khiến lo ngại về Bun gia tăng

Bun là một runtime JavaScript nhanh và thực dụng, giúp việc làm với TypeScript trở nên thuận tiện trong các script nhỏ, ứng dụng, bài test và công cụ
Nhờ cài đặt nhanh, chạy test nhanh, bundling tốt hơn và giảm gánh nặng chuỗi công cụ, đây là công cụ được kỳ vọng sẽ thành công như một phương án thay thế Node.js
Trọng tâm của lo ngại không phải là chất lượng của Bun, mà là việc sau khi Bun đi vào bên trong Anthropic, nó có thể bị ảnh hưởng bởi chính sách sản phẩm và cách vận hành

Thương vụ Anthropic mua lại và kỳ vọng ban đầu

Anthropic đã mua lại Bun vào tháng 12 năm 2025
Theo thông báo mua lại, Bun sẽ tiếp tục giữ tính mã nguồn mở và giấy phép MIT, cùng một đội ngũ sẽ tiếp tục phát triển, còn lộ trình vẫn tập trung vào các công cụ JavaScript hiệu năng cao và khả năng tương thích Node.js
Thông báo có câu: “Claude Code ships as a Bun executable to millions of users. If Bun breaks, Claude Code breaks. Anthropic has direct incentive to keep Bun excellent.”
Khi đó, có thể xem việc Claude Code chạy trên Bun là lý do trực tiếp khiến Anthropic có động lực giữ Bun nhanh và ổn định
Lập luận đó đến nay vẫn hợp lý, nhưng đã xuất hiện nỗi lo rằng cách Anthropic vận hành sản phẩm phần mềm bắt đầu lộ ra những vết nứt

Sự thay đổi trong đánh giá về Claude Code

Chất lượng mô hình của Anthropic tự nó không phải là mối lo cốt lõi
Dòng mô hình được cho là Claude Opus 4.6 vẫn được đánh giá là tốt cho lập trình, viết lách, suy luận và các công việc phát triển nói chung
Vấn đề nằm ở lớp sản phẩm xung quanh mô hình, và nhận định cốt lõi là khả năng sử dụng Claude Code hiện đã giảm đi đáng kể
Khoảng một năm trước, Claude Code tạo cảm giác như một công cụ có thể đọc dự án, tạo ra các chỉnh sửa tập trung, chạy lệnh, sửa sai và tiếp tục tiến lên
Khi đó, Claude Code là một trong những công cụ lập trình AI đầu tiên khiến người ta tin rằng quy trình làm việc của lập trình viên có thể chuyển từ trọng tâm tự động hoàn thành sang trọng tâm agent
Ngay cả vào tháng 12 năm 2025, Claude Code đã bắt đầu kém đi nhưng vẫn còn dùng được, và việc mua lại Bun vẫn có thể hiểu được nếu nhìn từ góc độ Anthropic đang xây dựng tương lai của công cụ lập trình

Các vấn đề của Claude Code sau tháng 4 năm 2026

Từ tháng 4 năm 2026, các lập trình viên bắt đầu chỉ ra các vấn đề về chất lượng, hành vi giới hạn, hạn chế với harness bên thứ ba, cách tính phí gây rối và giao tiếp chậm của Claude Code
Anthropic đã công bố engineering postmortem, trong đó xem các vấn đề ở lớp sản phẩm như giảm giá trị nỗ lực suy luận mặc định, lỗi phiên cũ và thay đổi prompt làm hại chất lượng lập trình là nguyên nhân
Bản phân tích sau sự cố này được xem là tốt hơn việc cứ như không có chuyện gì xảy ra, và được đón nhận như một trong số ít trường hợp Anthropic thừa nhận trách nhiệm của mình
Theo bài viết của TechCrunch, Anthropic đã thông báo rằng người đăng ký Claude Code phải trả thêm phí để được hỗ trợ OpenClaw và các harness bên thứ ba khác
Theo bài viết của Gigazine, chỉ cần trong lịch sử git có OpenClaw thì Claude Code cũng có thể từ chối yêu cầu hoặc kích hoạt tính phí bổ sung
Bài viết đó trích lời Theo cho biết chỉ cần OpenClaw được nhắc đến trong commit gần đây bên trong một JSON blob thì ngay cả khi gọi trực tiếp claude -p "hi" trong một repository trống, hành vi này vẫn có thể bị kích hoạt
Cảnh liên quan cũng có thể được xác nhận qua đoạn video
Những hành vi như vậy khiến sản phẩm trông như thể các thay đổi được tung ra mà chưa thực sự được dùng thử đầy đủ trong trải nghiệm sử dụng ở cấp độ mã nguồn
Nhìn từ bên ngoài, Claude Code dường như đang đi sai hướng với nhiều giới hạn hơn, cách tính phí kỳ lạ hơn và các hành vi ngoài dự đoán thay đổi theo văn bản commit
Xu hướng này được mô tả là enshittification

Nỗi bất an lan sang Bun

Bun hiện được tích hợp sâu trong Claude Code, và vì Claude Code có vẻ đang xuống cấp nên xuất hiện lo ngại rằng Bun cũng có thể đi theo cùng hướng
Điều đó không có nghĩa Bun tệ đi hay đội ngũ Bun đã mất quan tâm
Vấn đề là Bun và đội ngũ Bun càng được tích hợp sâu vào Anthropic thì chính sách của Anthropic cũng có thể đi kèm theo
Nếu những chính sách dường như đã làm hỏng Claude Code cũng ảnh hưởng đến Bun, thì ở Bun cũng có thể xuất hiện những vấn đề khiến đội ngũ trông như không thực sự dùng chính sản phẩm của mình
Chỉ riêng khả năng đó thôi cũng đã khiến người ta khó có thể chắc chắn về việc tiếp tục dùng Bun trong một số dự án

Tạm thời chuyển sang pnpm

Bun cung cấp nhiều tính năng hơn pnpm trong cùng một công cụ
Bun hỗ trợ TypeScript mà không cần bước build riêng, cung cấp bundler thay cho Vite, và cung cấp tính năng test thay cho vitest
Việc gói những khả năng đó vào một chuỗi công cụ duy nhất thực sự là một lợi thế lớn
pnpm không phải là phương án thay thế Node.js hay Bun; nó chỉ là một trình quản lý gói
Tuy vậy, nếu phần được dùng thường xuyên nhất của Bun trong công việc hằng ngày là quản lý gói, thì cả Bun và pnpm đều mang lại cài đặt nhanh, hỗ trợ monorepo tốt và mức sử dụng đĩa hợp lý
Vì thế, một số dự án hiện đang dùng Bun đã lựa chọn rời Bun để chuyển sang pnpm
Hiện tại, khi được hỏi nên khuyến nghị gì cho dự án JavaScript hay TypeScript, câu trả lời là pnpm

Đây không phải lời khuyên phải rời Bun

Dù đang chuyển một số dự án khỏi Bun, điều đó không cần được xem là đáp án đúng trong mọi trường hợp
Với dự án mới, pnpm là lựa chọn hợp lý
Còn với dự án hiện có, vẫn có thể chọn giữ Bun cho đến khi xuất hiện lý do đủ thuyết phục để rời đi

Khả năng còn lại và kết luận

Vẫn có hy vọng rằng Bun sẽ tiếp tục giữ được chất lượng xuất sắc, đội ngũ Bun tiếp tục tạo ra công việc tốt, và Anthropic trao đủ quyền tự chủ để họ có thể đưa ra các quyết định phù hợp với hệ sinh thái JavaScript
Anthropic có tiền, có sức phân phối, và có lý do thực tế để quan tâm đến hiệu năng cũng như độ ổn định của Bun
Bun vẫn có thể trở nên mạnh hơn sau khi đi qua giai đoạn này
Tuy vậy, mức độ tin tưởng vào tình hình hiện tại đã thấp hơn so với tháng 12 năm 2025
Claude Code trước đây từng trông như bằng chứng cho thấy Anthropic hiểu công cụ dành cho lập trình viên, nhưng giờ nó giống một cảnh báo rằng Anthropic có thể không hiểu điều gì cần thiết để duy trì và cải thiện sản phẩm trong dài hạn
Bun vẫn rất tuyệt, nhưng khó biết nó sẽ đi về đâu trong tương lai
Vì tình hình có thể hoàn toàn khác sau một năm nữa, tác giả dự định sẽ quay lại kiểm chứng xem dự đoán này có đúng hay không

3 bình luận

click 3 giờ trước

Tôi thừa nhận nhờ Bun mà Node cũng đã thay đổi khá nhiều, nhưng nhìn cảnh AI tự mở PR rồi tự tung hứng với nhau ngay trong repository thì tôi sợ sẽ dẫm phải những quả mìn hồi quy kiểu cái đang chạy được lại thành không chạy được.
Trước khi được Anthropic mua lại thì tôi từng dùng Bun làm chính, nhưng giờ lại quay về Node rồi.
Tôi vẫn nghĩ tính năng sfx là một killer feature, nhưng nếu không cần đến nó thì tôi cũng không rõ có lý do gì phải dùng Bun ngay bây giờ.

GN⁺ 7 giờ trước

Ý kiến trên Hacker News

Không đồng ý với toàn bộ tiền đề: ngay cả trước khi bị mua lại, Bun rồi cũng phải tìm cách kiếm tiền
Chỉ vì công ty mẹ thể hiện những thông lệ tệ với một phần mềm khác là Claude Code thì không có nghĩa Bun chắc chắn sẽ trở nên tệ hơn. Có thể hiểu được sự lo ngại, nhưng tôi vẫn còn lạc quan về Bun
Claude Code là sản phẩm cốt lõi của Anthropic và đang tăng trưởng cực nhanh, nên chỉ một thay đổi nhỏ cũng có thể dẫn tới vấn đề tính phí. Trong khi đó, Bun là một JavaScript runtime, có thể tập trung vào việc trở thành runtime tốt nhất, và không ảnh hưởng trực tiếp đến doanh thu hay lãi lỗ của Anthropic, nên cũng ít cần phải tung bản vá gấp vì lạm dụng như Claude Code
Vài năm tới sẽ ra sao thì vẫn chưa rõ, nhưng ngay lúc này, ngay sau thương vụ mua lại, tôi chưa quá lo
- Thật thú vị khi mọi người chấp nhận quá nhanh cách giải thích là do lạm dụng. Từ lâu người ta đã biết các phòng thí nghiệm AI lớn không thể kiếm lời về mặt tài chính từ những người dùng gói thuê bao dùng nhiều, bất kể họ dùng tác nhân hay công cụ thực thi nào. Mức giá công bằng có lợi nhuận phải là tính phí token theo mức sử dụng
  Các phòng thí nghiệm này muốn giết cạnh tranh vì các công cụ thực thi của bên thứ ba có nguy cơ biến mô hình ngôn ngữ lớn nền tảng thành hàng hóa phổ thông, đồng thời họ cũng đang chơi trò gà xem ai có thể chịu lỗ lâu hơn
  Cuối cùng họ vẫn phải định giá sản phẩm cho đúng, và cho tới lúc đó chỉ còn biết hy vọng họ đã giết được mọi cạnh tranh. Nhưng có vẻ họ đã thua cuộc chơi đó rồi. Các mô hình hữu ích ngày càng nhỏ hơn theo từng năm và chi phí chạy cũng thấp hơn, nên đã vượt qua ngưỡng để việc phát triển công cụ thực thi bên thứ ba có thể tiếp tục ngay cả khi không có tập người dùng thuê bao
  Cược cốt lõi là “AI hữu ích cần phần cứng cực kỳ đắt đỏ” đã thất bại, và canh bạc thứ hai là khóa người dùng vào hệ sinh thái rồi mới kiếm tiền sau cũng sẽ thất bại. Rốt cuộc họ sẽ phải cạnh tranh chỉ bằng năng lực thật của sản phẩm, mà điều đó thì lợi nhuận thấp hơn nhiều
- Tôi thấy chính cái tình huống “ngay cả trước khi bị mua lại, Bun rồi cũng phải tìm cách kiếm tiền” đã là vô lý. Việc mọi người lại đang phụ thuộc vào một JavaScript runtime rồi sẽ phải kiếm tiền lúc nào đó vốn đã kỳ lạ, và việc nó bị mua bởi một trong những công ty thua lỗ tiêu biểu nhất của lĩnh vực đang đốt tiền mạnh nhất ngành mà người ta vẫn còn hy vọng thì cũng rất lạ
- Có vẻ bạn đang đánh giá thấp tác động của chính sách và văn hóa doanh nghiệp lên sản phẩm
  Giờ có những đội ngũ cược tất cả vào AI và hành xử như thể chẳng cần trực tiếp nhìn vào code nữa. Tôi đã thấy tận mắt và kết quả đúng như có thể đoán trước. Nó vận hành ổn đến một mức nào đó, nhưng đặc biệt khi mỗi nhóm có thuật ngữ kỹ thuật và cách hiểu khác nhau, độ phức tạp tích tụ dần, sai sót cũng chồng chất, và cuối cùng chẳng còn cá nhân hay nhóm nào thực sự biết phần mềm hoạt động thế nào
  Cũng có xu hướng để AI điều khiển trình duyệt hay công cụ ngoài unit test và integration test, mà không có con người test hay đảm bảo chất lượng. Văn hóa của Anthropic có thể thay đổi cách đội Bun vận hành và tư duy
  Nếu kiểu văn hóa và tư duy này trở thành chuẩn mực thì либо mô hình sẽ phải tốt hơn rất nhiều, hoặc chất lượng phần mềm sẽ đi xuống
  Có một bài nói chuyện hay của Matt Pocock: https://youtu.be/v4F1gFy-hqg
  “Code không hề rẻ. Code tệ giờ đã đắt hơn bao giờ hết. Nếu bạn có một codebase khó thay đổi, bạn sẽ không thể tận dụng được sự sung túc mà AI có thể mang lại. Với codebase tốt, AI làm việc cực kỳ, cực kỳ hiệu quả.”
  Một khi code tệ bắt đầu tự tích tụ, việc thoát ra sẽ cực kỳ khó khăn
- Theo cùng logic đó, GitHub trước khi bị mua lại rồi cũng phải tìm cách kiếm tiền. Và việc công ty mẹ Microsoft từng có những thực hành tệ với Embrace, Extend, Extinguish hay MS Windows không có nghĩa GitHub sẽ tệ đi, nên bảo rằng hiểu lo ngại nhưng vẫn lạc quan về GitHub thì cũng chẳng khác mấy lập luận này
- Anthropic mua Bun không phải vì toàn bộ cộng đồng JavaScript, mà để bảo vệ và phát triển khoản đầu tư vào Claude Code. Điều này có vẻ hiển nhiên nhưng vẫn cần nhắc lại. Về dài hạn, kết quả sẽ đi theo các động cơ lợi ích
Tôi không hiểu vì sao mọi người lại dùng Deno hay Bun thay cho Node. Có đối thủ cạnh tranh với JavaScript runtime thì tốt, nhưng tôi không thấy rõ lợi ích khi rời Node
Bun không có REPL và JavaScript engine cũng kém hơn, còn Deno thì giống Node nhưng gắn thêm hệ thống quyền hạn chế và phiền phức, mà tôi tưởng cũng không có sqlite. Cả hai đều được nói là hiệu năng tốt, nhưng có vẻ chỉ trong các benchmark được chọn lọc, và với workload tôi tự thử khoảng một năm trước thì cả hai đều chậm hơn Node
Dù vậy, hồi từng giao một công cụ ERP nhỏ thì công cụ đóng gói dự án thành *.exe bên Bun là chắc tay nhất nên tôi đã dùng Bun. Toàn bộ vẫn làm bằng Node với JavaScript không phụ thuộc gì, chỉ dùng Bun để phát hành, và trải nghiệm đó đúng là tốt hơn Node
- Deno cũng có sqlite: https://docs.deno.com/examples/sqlite/
- Trải nghiệm lập trình viên của Bun tốt hơn Node rất nhiều, đặc biệt là với dự án TypeScript
- Deno tốt ở chỗ người dùng chỉ cần chạy luôn, không cần bước cài đặt riêng
Thật ra Bun vốn cũng chưa bao giờ được vận hành quá bài bản. Tính năng nào cũng đầy bug và lỗ hổng, mỗi lần sửa vài thứ trong một bản phát hành thì lại làm hỏng thứ khác
Chỉ một bản vá gần đây mà họ đã nhét vào số lượng tính năng lớn và thay đổi phá vỡ tương thích nhiều như phần lớn phần mềm trải qua trong hai major version
Ngay cả khi chỉ dùng nó làm trình chạy script và trình quản lý gói npm thì lượng công sức để tìm ra phiên bản “ổn” cũng đáng ngạc nhiên. Tôi từng nhiều lần bị treo đột ngột trong lúc cài đặt ở các patch version, và vì thế không thể nâng cấp trong một thời gian
Khoảng hai minor version trước, có vẻ họ đã làm hỏng hoàn toàn script postinstall cùng với trustedDependencies. Không thấy nhắc một chữ nào trong release note và có vẻ cũng chẳng ai báo trên GitHub issues. Cỡ bản 1.1 thì còn có thể khiến Bun build trustedDependency trong postinstall, nhưng từ đó trở đi thì không được nữa, và đã hỏng suốt nhiều tháng
- Có một GitHub issue về chuyện bị treo khi cài đặt. Trình quét bảo mật truyền toàn bộ danh sách dependency làm đối số dòng lệnh, nên trong các monorepo lớn trên Linux thì vượt quá ARG_MAX
  spawn bị treo im lặng không báo lỗi, và vì trình quét tách biệt với postinstall nên --ignore-scripts cũng không giúp được gì. Ít nhất là đã hỏng từ 1.3.5
Tôi đang làm việc tại Bun, và bài này hơi gây bối rối. Cá nhân tôi cũng như cả đội Bun đều tự dùng Bun mỗi ngày và đang cải thiện nó, thậm chí tốc độ phát triển còn nhanh hơn trước. Từ sau khi về với Anthropic, độ ổn định của Bun cũng đã tốt lên rõ rệt
Những thứ sẽ có trong phiên bản Bun tiếp theo gồm nhị phân Windows x64 giảm 17MB [0], nhị phân Linux giảm 8MB [1], cờ CLI --no-orphans để kết thúc đệ quy các child process còn sót lại [3], cache SSL context cho TCP client và Unix socket nhằm giảm mạnh mức dùng bộ nhớ của các database client như Mongoose/MongoDB [4], HTTP/3 và HTTP/2 client thử nghiệm cho fetch [5], hỗ trợ HTTP/3 thử nghiệm cho Bun.serve() [6], thư viện xử lý ảnh tích hợp Bun.Image [7], v.v.
Ngoài ra còn có các cải thiện về độ tin cậy cho node:fs, Worker, BroadcastChannel và MessagePort
Nhờ được Anthropic mua lại, Bun không còn cần phải trở thành một mảng kinh doanh tạo doanh thu nữa. Claude Code phụ thuộc vào Bun, và rất nhiều kỹ sư phần mềm phụ thuộc vào Claude Code để làm việc, nên có động lực rất mạnh để làm Bun tốt hơn
[0]: https://github.com/oven-sh/bun/pull/30219
[1]: https://github.com/oven-sh/bun/pull/30098
[2]: https://github.com/oven-sh/WebKit/pull/211
[3]: https://github.com/oven-sh/bun/pull/29930
[4]: https://github.com/oven-sh/bun/pull/29932
[5]: https://github.com/oven-sh/bun/pull/29863
[6]: https://github.com/oven-sh/bun/pull/30032
- Các vụ mua lại trong ngành này thường đi đến một kết cục ít nhiều mang tính tất yếu. Phần mềm bị mua lại sẽ xuống cấp khi đội ngũ ban đầu nhận thưởng rồi rời đi, và văn hóa cũ bị thay bằng văn hóa của chủ mới
  Bun có thể là ngoại lệ, nhưng cũng không thể nói lo ngại này là vô căn cứ
  CEO của Anthropic nhiều lần đưa ra các dự đoán bị thổi phồng như thể AI sắp gần thay thế lập trình viên con người, và Anthropic đang áp niềm tin đó vào Claude Code để biến nó thành một mớ spaghetti không thể bảo trì
- Tính năng tốt nhất mà Bun đưa ra gần đây là nhị phân di động. Người dùng thường chạy các bản phân phối Linux cũ, nên tính di động là rất quan trọng. Node và Deno thì yêu cầu Linux mới hơn, chính xác hơn là glibc mới hơn
- Cách nói “tôi làm ở Bun” là một cách nói cực kỳ giảm nhẹ. Dù có lo ngại về Anthropic, nếu Jarred còn dẫn dắt thì tôi không nghĩ Bun sẽ đi chệch hướng. Có vẻ họ đang tận dụng tốt sự ổn định và nguồn vốn từ một tổ chức lớn hơn
Tôi đã dành vài giờ chuyển backend của một website mài dao từ Bun sang Node, và cảm thấy rất vui vì tránh được hiệu ứng khóa chặt. Lúc đầu tôi khá nhiệt tình với Bun, nhưng dần dần bớt tin tưởng hơn
Những tính năng tôi sẽ nhớ là truy vấn sqlite bằng tagged template literal, Bun.password.verify dùng argon2 mặc định, import HTML, chuyển đổi JSX, và tự động nạp file .env
https://burlyburr.com gọi tới https://backend.burlyburr.com
- Node cũng hỗ trợ truy vấn sqlite bằng tagged template literal
  https://nodejs.org/api/sqlite.html#databasecreatetagstoremax...
- Có lẽ chỉ cần dùng một thư viện helper nhỏ để lấy lại các tính năng bạn nhớ. Ít nhất Node cũng đã có SQLite và Argon2, nên nếu vấn đề là giao diện thì sửa rất dễ
- Node cũng hỗ trợ tự động nạp .env và sqlite
Tôi không nghĩ Bun đã hoạt động tốt ngay cả trước khi bị mua lại. Tôi vẫn dùng nó cho các script nhỏ, nhưng sẽ không triển khai dịch vụ ở chỗ làm bằng Bun
Vì các vấn đề bộ nhớ và những chỗ không tương thích mãi không được sửa, tôi xem nó như một món đồ chơi khá ổn để cho thấy Node.js vẫn còn chỗ cần cải thiện
Ví dụ tôi đã theo dõi https://github.com/oven-sh/bun/issues/14102 một thời gian dài, rồi cuối cùng các thư viện bắt đầu thêm nhánh kiểu “nếu là Bun thì làm x”, mà như vậy là đi ngược lại tính tương thích
- Tôi đã thử dùng nó trong môi trường production ở vài dự án, nhưng cả hai đều phải quay lại từ Bun sang Node. Một cái thì đúng như đã nói, có rò rỉ bộ nhớ nghiêm trọng, còn cái kia thì lỗi vì khác biệt API ở những chỗ như TextDecoderStream. Tôi quyết định chưa thử lại cho tới Bun v2
Xu hướng ở Claude Code và Anthropic có vẻ là cố tình giấu điều gì đó khỏi người dùng. Chắc vẫn có người nhớ vụ náo loạn khi hành vi đọc xxx.yy bị đổi thành đọc một file hay hai file
Sau đó còn có thêm nhiều thay đổi như vậy, và hoặc là không thể cấu hình, hoặc rất khó cấu hình. Tôi hiểu động cơ kinh doanh: khiến người dùng dùng AI nhiều nhất có thể, đưa con người ra khỏi vòng lặp, thu được nhiều dữ liệu huấn luyện hơn và nhiều token usage hơn
Nhưng theo tôi, kết quả là Claude Code trở nên tệ hơn nhiều và kém đáng tin cậy hơn nhiều. Cảm giác như họ đang lén lấy tay lái khỏi tay người dùng. Nếu đi theo logic đó thì ngày càng nhiều thứ sẽ được hợp lý hóa
Hiện tại điều chủ yếu tăng lên là sự mất lòng tin
Tôi đồng ý với bài viết gốc, và cũng hiểu vì sao với một số người điều này vẫn có thể trông như phản ứng quá sớm
Chúng ta đang sống trong một thế giới rất khác trước đây, và mọi người ý thức hơn về các lo ngại đạo đức, đồng thời cũng quyết tâm hơn trong việc chống lại để không lặp lại sai lầm cũ
Theo tiêu chuẩn kỹ thuật thì có thể là phán xét sớm, nhưng theo tiêu chuẩn lo ngại đạo đức thì hoàn toàn có lý. Hành vi sai trái không còn dễ đảo ngược như trước, và để tránh tác động lớn từ những quyết định kiểu đó thì cần hành động phòng ngừa
- Tôi tò mò không biết cơ sở nào để nói rằng giờ mọi người ý thức hơn về lo ngại đạo đức. Tôi không thấy người ta có vẻ đạo đức hơn trước. Ví dụ tôi có thấy phía BDS đông hơn một chút, nhưng ngoài ra thì không rõ lắm
- Nhìn những lời phàn nàn về việc Firefox và Safari không áp dụng API nền tảng Chrome OS, hay thực tế Chrome được phát tán khắp nơi, tôi không nghĩ có thể nói mọi người đang kiên trì giữ cân nhắc đạo đức
Cuối bài, tác giả liệt kê những thứ họ thích ở Bun mà pnpm không có. Danh sách chủ yếu là hỗ trợ TS native, bundler kiểu Vite, và test runner kiểu Vitest/Jest
Trừ bundler ra thì Node giờ đã có hết. Cú pháp test runner có thể khác, nhưng TypeScript cũng đã “cứ thế mà chạy” theo mặc định và test runner tích hợp cũng đủ dùng. Tôi không chắc Bun có đáng để tiếc nuối đến vậy không
- Nói công bằng thì Node không có những thứ này cho tới khi bị Deno và Bun thách thức. Chỉ riêng Deno vì lý do nào đó không tạo ra thay đổi lớn, nhưng sự tồn tại của Bun đã thật sự tác động đến Ban chỉ đạo kỹ thuật Node
  Cũng có thể nói phần lớn động lực hiện tại đến từ hoạt động tiếp thị mạng xã hội rất khôn khéo của Jarred Sumner. Anh ấy khiến mọi người bàn tán, và nhờ thế Node cũng tốt hơn
  Ngoài ra, việc Bun thúc mạnh hỗ trợ càng nhiều Node API càng tốt cũng kéo Deno đi theo mức tương thích tương tự, nên giờ phần lớn code thực tế đã bớt bị khóa vào runtime hơn. Tôi không biết mình có dùng Bun trong production không, nhưng chỉ riêng việc Bun tồn tại đã khiến hệ sinh thái JavaScript tốt hơn nhiều, nên điều đó rất đáng mừng
- Node thêm TypeScript native từ khi nào? Có thể chạy thẳng node main.ts mà không cần phụ thuộc gì không?
- Nếu tính cả việc trình biên dịch TypeScript được viết lại thì mức độ liên quan của Bun còn giảm thêm nữa
Thành thật mà nói, tôi cũng không dùng Bun nhiều ngoài việc thỉnh thoảng test module. Hằng ngày tôi chủ yếu dùng Deno, và vài năm qua tôi cũng đã viết nhiều shell script bằng Deno
Trải nghiệm dùng gần đây khá hợp ý tôi, và cách tham chiếu trực tiếp module trong repository đặc biệt tiện cho shell script
Tuy vậy, tôi vẫn lo liệu họ có thể tạo đủ doanh thu mà vẫn giữ được tính mở của tính năng, hoặc ít nhất là để người khác có thể fork và sao chép hay không. Vì thế tôi cũng hiểu một phần các lo ngại này

jjpark78 3 giờ trước

https://github.com/oven-sh/bun/issues/17723

Chỉ cần sửa chỗ này thôi là có lẽ tôi sẽ thử chạy nó một lần ở backend...