- Với phát triển có AI hỗ trợ, tiêu chí chọn ngôn ngữ chuyển từ tốc độ con người viết sang khả năng AI sửa đổi và hiệu năng runtime
- Đến năm 2026, Claude Opus 4.7, GPT-5.5, Gemini 3.1, DeepSeek V4 đều vượt 80% SWE-bench Verified
- Rust có vòng phản hồi từ compiler giúp AI tự sửa lỗi, còn Go và Swift cũng có lợi cho agent nhờ kiểm tra kiểu nhanh
- Các cuộc chuyển đổi lớn đã thực sự diễn ra, như trình biên dịch TypeScript được port sang Go, trình biên dịch C viết bằng Rust, Rue, và việc port engine JavaScript của Ladybird
- Hệ sinh thái Python·JavaScript cũng ngày càng phụ thuộc vào công cụ và wrapper viết bằng Rust, dù vẫn còn ngoại lệ như Prisma, PyTorch và các ngôn ngữ quy mô nhỏ
Tiêu chí chọn ngôn ngữ đã thay đổi vì phát triển có AI hỗ trợ
- Mặc định cho dự án mới trong thời gian dài là Python hoặc TypeScript
- Vì hệ sinh thái lớn, nguồn tuyển dụng rộng, và có thể làm demo rất nhanh
- Rust, Go, C++ có thể cho hiệu năng cao hơn 10~100 lần, nhưng thời gian học, thị trường nhân lực nhỏ và hệ thống build khó nhằn lại trở thành chi phí
- Vì vậy người ta thường ra mắt bản Python trước rồi nói “sẽ tối ưu hiệu năng sau”, nhưng trên thực tế nhiều trường hợp cứ giữ nguyên như vậy
- Thỏa hiệp đó bắt đầu lung lay khi AI có thể xử lý các ngôn ngữ khó
- Trong việc chọn ngôn ngữ, trọng tâm chuyển từ “con người có viết nhanh không” sang “AI có viết và sửa tốt không” cùng với hiệu năng runtime
Ngôn ngữ khó lại trở nên dễ với AI trước
- Hai năm trước, GPT-4 khi viết hàm Rust còn ở mức bịa ra tên crate không tồn tại
- Đến tháng 4/2026, Claude Opus 4.7, GPT-5.5, Gemini 3.1, DeepSeek V4 lần lượt vượt mốc 80% trên SWE-bench Verified chỉ trong vài tuần
- Các phòng nghiên cứu đang tối ưu hóa rõ ràng cho công việc hệ thống
- lỗi đồng thời
- race condition
- lỗi kiến trúc được phát hiện từ giai đoạn lập kế hoạch
- CtrlAltDwayne cho rằng lý do Rust mạnh trong năm 2026 không nằm ở an toàn bộ nhớ hay hiệu năng mà ở vòng phản hồi từ compiler
- AI viết Rust tốt hơn C++
- Thông báo lỗi từ compiler của Rust trở thành tín hiệu giúp mô hình tự sửa theo thời gian thực
- Rust vận hành như một ngôn ngữ “vô tình được thiết kế sớm hơn 10 năm” để phù hợp với phát triển có AI hỗ trợ
- Lý do tương tự cũng áp dụng, dù mức độ khác nhau, với Go và Swift
- Hệ thống kiểu mạnh và vòng lặp compile/kiểm tra nhanh cung cấp cho agent chu kỳ lặp dày đặc
- Những ngôn ngữ hệ thống từng khó với con người có thể lại là mục tiêu dễ hơn đối với agent
Những trường hợp đã thực sự được phát hành
-
Microsoft port trình biên dịch TypeScript sang Go
- Microsoft phát hành TypeScript 7.0 beta và port codebase TypeScript 10 năm tuổi sang Go
- TypeScript 7.0 beta nhanh hơn khoảng 10 lần so với 6.0
- Theo đánh giá của Anders Hejlsberg, Go mang lại phần lớn lợi ích hiệu năng với chỉ một phần chi phí kỹ thuật
- Ngay cả một trong những tổ chức JS/TS lớn nhất cũng đã sẵn sàng chọn ngôn ngữ nhanh hơn và khó hơn cho công cụ cốt lõi, cho thấy phép tính giữa công sức và hiệu quả đã đổi khác
-
Trình biên dịch C viết bằng Rust tạo ra bởi 16 agent Claude
- Nhà nghiên cứu Nicholas Carlini của Anthropic đã điều phối song song 16 agent Claude để viết trình biên dịch C production bằng Rust
- Quy mô là 100.000 dòng và có thể boot Linux 6.9 trên x86·ARM·RISC-V
- Nó biên dịch được QEMU, FFmpeg, SQLite, PostgreSQL, Redis và còn chạy được Doom
- Tổng chi phí chưa đến 20.000 USD qua gần 2.000 phiên Claude Code
- Một trình biên dịch C viết bằng Rust trước đây là đề tài cỡ luận văn cao học, nhưng giờ không còn là việc chỉ xuất hiện như ngoại lệ nữa
-
Rue của Steve Klabnik
- Steve Klabnik, đồng tác giả The Rust Programming Language và là người có 13 năm kinh nghiệm với Rust, đã cùng Claude tạo ra một ngôn ngữ hệ thống mới tên Rue chỉ trong 2 tuần
- Kết quả là khoảng 70.000 dòng Rust
- Ông cho biết 2 tuần lần này đã đi xa hơn những nỗ lực trước đây từng mất một đến hai tháng
-
Port engine JavaScript của Ladybird sang Rust
- Andreas Kling, nhà sáng lập trình duyệt Ladybird và kỹ sư C++, đã đưa hàng trăm prompt nhỏ cho Claude Code và Codex để port engine JavaScript của Ladybird từ C++ sang Rust trong 2 tuần
- Kết quả là khoảng 25.000 dòng Rust, đạt tương đương từng byte với bản C++ gốc
- Không có hồi quy nào trên hơn 65.000 bài test khi gộp test262 và test của Ladybird
- Ông nói nếu làm thủ công thì cùng công việc đó sẽ mất nhiều tháng
Lập luận “hệ sinh thái” đang suy yếu
- Lập luận mạnh nhất của Python và JavaScript vốn nằm ở hệ sinh thái hơn là bản thân ngôn ngữ
- Có nền tảng như FastAPI, Django, PyTorch, React, Next.js và 4 triệu package trên npm
- Lý do các đội có thể phát hành tính năng chỉ trong vài ngày là vì hệ sinh thái đã giải quyết sẵn 90% vấn đề
- Lợi thế này mang tính quyết định trong 10 năm qua, nhưng đang yếu đi trong 2 năm gần đây
- Ngay bên trong hệ sinh thái Python cũng ngày càng phụ thuộc vào thành phần viết bằng Rust
- Toàn bộ lõi xác thực của
pydantic là thư viện Rust
- Polars, lựa chọn thay thế cho pandas, được viết bằng Rust
- Hugging Face tokenizers và orjson cũng là Rust
- Theo khảo sát Python 2025 của JetBrains, tỷ lệ dùng Rust trong extension nhị phân của Python tăng từ 27% lên 33% chỉ trong một năm
- Nền tảng công cụ phát triển cũng đang đi theo hướng này
- Astral, do Charlie Marsh thành lập năm 2022, đã phát hành ruff, uv, ty viết bằng Rust, và số lượt tải hằng tháng của cả ba công cụ đã tăng từ 0 lên hàng trăm triệu
- Ngày 19/3/2026 OpenAI mua lại Astral và cho rằng uv giúp tiết kiệm khoảng 1 triệu phút compute time mỗi tuần cho Codex
- 10 tuần trước đó, Anthropic đã mua lại Bun
- Bun đạt 7 triệu lượt tải mỗi tháng, 89.000 sao GitHub và được gọi là “hạ tầng thiết yếu cho kỹ nghệ phần mềm do AI dẫn dắt”
- VoidZero của Evan You đã phát hành Rolldown-Vite
- Bundler Rust này giảm thời gian build 2,5 phút của GitLab xuống còn 40 giây và hạ mức dùng bộ nhớ xuống còn 1/100
- Lee Robinson, Phó chủ tịch mảng sản phẩm của Vercel, nói rằng “JS đã chạm đỉnh tối ưu hóa”
- Những package mang về dùng trong Python và JavaScript ngày càng trở thành wrapper cho code viết bằng các ngôn ngữ từng bị xem là khó tự phát hành trực tiếp
- Nếu giờ có thể phát hành trực tiếp bằng chính các ngôn ngữ đó, wrapper bắt đầu trông giống như một lớp overhead
Khi port trở nên dễ hơn vá lỗi
- Vòng lặp tích cực của hệ sinh thái mã nguồn mở trước đây xoay quanh patch
- Chọn Python vì dễ
- Phát hiện lỗi trong dependency
- Sửa rồi đẩy upstream
- Hệ sinh thái trở nên lành mạnh hơn
- Agent đang chuyển đơn vị đóng góp từ patch sang port
- Armin Ronacher, người tạo ra Flask, đã dùng agent trong tháng 1 để port thư viện Rust MiniJinja sang Go
- Tổng thời gian chạy là 10 giờ
- Trong đó 3 giờ có giám sát và 7 giờ chạy không người trông
- Thời gian thực sự của con người chỉ là 45 phút
- Chi phí API là 60 USD
- Khi việc port thư viện giữa các ngôn ngữ trở thành công việc 45 phút, lập luận về việc gửi sửa đổi lên thư viện của người khác sẽ yếu đi
- Không còn là “vá được thì sao không fork”, mà là “fork được thì sao còn vá”
- Armin Ronacher cho rằng giá trị đang chuyển từ code sang test và tài liệu
- Một bộ test tốt có thể có giá trị hơn bản thân code
- Vòng lặp đã tạo ra PyPI và npm vẫn còn hoạt động, nhưng chưa rõ đến năm 2028 nó có còn vận hành theo cùng cách hay không
Những ngoại lệ vẫn còn tồn tại
- Không phải mọi thay đổi đều chảy theo một hướng duy nhất
- Trong một số trường hợp, lựa chọn cũ vẫn đúng
- Prisma đã loại bỏ Rust query engine và chuyển sang lõi TypeScript/WASM
- Kích thước bundle giảm 85% và truy vấn nhanh hơn tới 3,4 lần
- Binary Rust native bất lợi trong môi trường serverless runtime
- PyTorch vẫn chiếm khoảng 85% nghiên cứu deep learning
- Vì trọng số mô hình không bị ảnh hưởng bởi ngôn ngữ dùng để bọc bên ngoài, vị thế này sẽ không dễ đổi
- AI cũng không xử lý mọi ngôn ngữ hệ thống tốt như nhau
- Các ngôn ngữ nhỏ hơn như Zig, Haskell, Gleam hiện chưa có chất lượng sinh mã ngang với Rust hay Go
- Dữ liệu huấn luyện quyết định phạm vi mà mô hình có thể hỗ trợ
- Rust và Go có lợi thế vì xuất hiện đủ nhiều trên GitHub
- Zig, Haskell, Gleam vẫn đang ở phía bất lợi của đường cong đó
Vì sao thay đổi này có thể kéo dài
- Lập luận phòng thủ truyền thống của Python và TypeScript thực chất là lập luận về trải nghiệm lập trình viên
- Chúng được chọn vì giảm tối đa ma sát giữa ý tưởng của con người và sản phẩm phát hành
- Rust không phải là ngôn ngữ chậm ở runtime, mà là ngôn ngữ chậm khi bạn phải phát hành lúc 2 giờ sáng
- Giờ đây agent bắt đầu đảm nhận phần khó
- Vai trò của con người chuyển từ “viết code” sang “thiết kế hệ thống và rà soát đầu ra”
- Trong dòng chảy này, sự tiện lợi cú pháp của Python trở nên kém quan trọng hơn ở mỗi nhánh quyết định
- Lợi thế runtime của những ngôn ngữ khó hơn sẽ tích lũy mỗi ngày khi dịch vụ chạy production
- Trong bài viết tháng 2 A Language For Agents, Armin Ronacher cho rằng chi phí viết code đang giảm mạnh và độ rộng của hệ sinh thái trở nên bớt quan trọng
- Các lựa chọn ngôn ngữ suốt 20 năm qua được hình thành quanh ràng buộc “con người viết code, và con người chậm khi làm việc với ngôn ngữ cấp thấp”
- Ràng buộc đó đang bắt đầu biến mất
- Trong khảo sát Stack Overflow 2025, Rust là ngôn ngữ được ngưỡng mộ nhất 10 năm liên tiếp với 72%
- Gleam là 70%
- Elixir là 66%
- Zig là 64%
- Sở thích đã tồn tại từ trước, và giờ công cụ đang bắt kịp sở thích đó
Bước tiếp theo: hướng tới ngôn ngữ dễ cho agent
- Karpathy nói vào tháng 2 rằng LLM đang thay đổi toàn bộ địa hình ràng buộc của phần mềm
- Ông cho rằng xu hướng port từ C sang Rust là dấu hiệu của điều đó
- Ông cũng nói ngay cả Rust cũng chưa phải thứ gần tối ưu cho vai trò ngôn ngữ đích của LLM
- Những kẻ chiến thắng hiện tại chỉ là điểm khởi đầu, và hình thái cuối cùng có thể còn ở xa hơn
- @RealRichomie nói vào 24/4 rằng tương lai của lập trình sẽ không đi về ngôn ngữ dễ nhất cho con người mà là ngôn ngữ dễ nhất cho agent
- Các kỹ sư đã phát hành ứng dụng Mac dù trước đó hoàn toàn không biết Rust hay Tauri
- Kết quả có kích thước chỉ khoảng 1/10 so với bản Electron và hiệu năng runtime cao hơn
- Con người không cần học Rust mà vẫn đạt được kết quả đó
- Dự án tiếp theo không nhất thiết phải mặc định chọn Python nữa
1 bình luận
Ý kiến từ Hacker News
Nếu đồng ý với lập luận rằng công cụ coding dùng LLM giống như một trình biên dịch không xác định, thì việc chọn một ngôn ngữ có hiệu năng tốt nhất có thể là khá hợp lý
Tất nhiên có rất nhiều ngoại lệ như thư viện hay lợi thế native riêng của từng ngôn ngữ, nhưng sau khoảng một tháng làm việc với C++, thứ duy nhất bị chậm đi vì lựa chọn ngôn ngữ chỉ là thời gian biên dịch
Tôi ngạc nhiên là đọc các bình luận đầu tiên mà vẫn chưa thấy ai nói về dữ liệu huấn luyện. Python có quá nhiều mã trong tập dữ liệu huấn luyện
AI có thể viết cả Brainfuck, nhưng tôi không nghĩ kết quả sẽ giống như khi dùng Python
Câu hỏi tiếp theo là: giờ đã có AI rồi, vậy tại sao phải bận tâm đến ngôn ngữ trước khi thực sự cần?
Tôi để Claude Code viết phần lớn, và Claude xử lý Perl cực kỳ tốt. Tôi bảo nó đừng đụng đến CPAN mà chỉ dùng thư viện chuẩn của Perl, vậy mà nó vẫn có đủ HTTP client, TLS, JSON tích hợp sẵn, và có thể thay thế những gì bình thường tôi sẽ làm bằng shell script theo cách rất ổn định và dễ dàng
Vì Perl không thay đổi quá nhiều và cũng có nhiều dữ liệu huấn luyện, nên có vẻ Claude dùng Perl khá tốt trong những tình huống khiến người ta nghĩ đến shell script
Dữ liệu ở đây: https://gertlabs.com/rankings?mode=agentic_coding
Tôi đã tạo một codebase Python lớn bằng AI, và LLM liên tục đoán sai tham số hoặc cấu trúc dictionary. Unit test hay các công cụ như pydantic có giúp được phần nào, nhưng tốt hơn là tránh hẳn kiểu lỗi runtime đó
Tôi đã thấy kết quả rất tốt cả ở những ngôn ngữ có tương đối ít mã nguồn công khai. Trở ngại lớn hơn là LLM hay sao chép các thành ngữ quen thuộc của ngôn ngữ đích, và với các ngôn ngữ “mang hơi hướng enterprise” như Java hay C#, mã boilerplate vô ích có thể tăng vọt ngay lập tức. Khi đó nguy cơ sản phẩm đầu ra vượt quá kích thước cửa sổ ngữ cảnh khả dụng và chất lượng giảm đi sẽ cao hơn nhiều
Nhưng nếu agent tạo mã, thử biên dịch, xem thông báo lỗi chi tiết, rồi tinh chỉnh mã dựa trên các thông báo đó thì kết quả sẽ chất lượng hơn. Chẩn đoán của rustc rất tốt, và dù Python hay JavaScript/TypeScript có nhiều hơn hẳn, giờ trên mạng cũng đã có đủ mã Rust
Lý do là vì tôi đã dùng Python hơn 10 năm, biết cách debug, và có thể ngửi ra trong vòng 10 giây xem agent có đang làm điều gì dễ dẫn tới thảm họa lớn hay không
Với các ngôn ngữ khác thì tôi không làm được như vậy và sẽ phải học lại khá nhiều. Dù AI có thể tuôn mã rất nhanh, tôi vẫn thích Python vì còn cảm giác mình đang kiểm soát được phần nào. Nếu làm bằng Go hay Rust thì nó sẽ giống “vibe coding” kiểu YOLO cho cả sản phẩm hơn là lập trình có AI hỗ trợ
Phần an toàn bộ nhớ thì tôi phải học vì chưa biết cái gì là “đúng”, nhưng ngoài ra mọi thứ đều khá suôn sẻ
Cú pháp dần lùi vào nền và bạn sẽ tập trung vào những thứ cấp cao hơn, khám phá những lối đi mới. Nếu thử một lần, bạn có thể sẽ ngạc nhiên thú vị vì có quá nhiều kinh nghiệm được chuyển giao
Nếu AI viết giúp thì tại sao còn phải dùng não?
/s
Tại sao dừng ở việc bắt AI dùng Rust? Nếu mọi thứ đều là vibe coding và cũng chẳng còn review code nữa, thì cứ để LLM thiết kế một ngôn ngữ siêu ngắn gọn, siêu đặc, chỉ tối ưu cho mức dùng token thấp nhất và tốc độ
Cuối bình luận này có gắn /s nhưng chỉ mang tính nửa đùa nửa thật
Hơi lạc đề một chút, nhưng tôi thực sự không hiểu tại sao mọi người vẫn đăng bài lên Medium
Trải nghiệm đọc quá tệ. Popup toàn màn hình che đúng nghĩa đen câu tôi đang đọc nên tôi còn không đọc hết bài này nổi
Có động lực nào mà tôi không thấy không?
Không có thứ gì đọc trong trình duyệt mà có thể mang lại cho tất cả mọi người cùng một trải nghiệm đọc tối thượng và vượt trội như nhau. Bản thân mô hình web hiện đại đã xung đột với điều đó
Một trang HTML đơn giản không CSS gần như là trải nghiệm đọc hoàn hảo. Vấn đề là hầu như chẳng ai phát hành như vậy cả. Web đã trở thành một nền tảng xuất bản nơi các tác giả quan tâm và cạnh tranh lẫn nhau. Các giao thức văn bản thuần túy nằm dưới quyền kiểm soát của người dùng gần hơn với “trải nghiệm đọc tốt nhất cho mọi người”. Web cũng có thể như thế, nhưng phần lớn thì không
Tôi đã thôi cố đọc bài dài trong trình duyệt. Tôi có thể dễ dàng trích xuất văn bản thuần liên quan, thậm chí cả văn bản có cấu trúc, rồi đọc trong editor của mình, vậy tại sao phải đọc trong trình duyệt? Tôi có thể tự kiểm soát font, màu sắc, điều hướng, v.v. Trình duyệt là phương tiện vận chuyển chứ không phải môi trường đọc. Xem nó như môi trường đọc là thói quen, không phải điều bắt buộc
Từ lâu rồi tôi cũng không viết gì dài hơn ba từ ở ngoài editor. Kiểm tra chính tả, từ điển đồng nghĩa, tra từ nguyên, dịch thuật, truy cập toàn bộ ghi chú của tôi, tích hợp LLM, mọi thứ tôi cần đều đã có sẵn ở đó. Một ngày nào đó bạn nên thử, cảm giác giải phóng sẽ rất lớn. Rồi bạn cũng có thể thôi đọc bài dài trong trình duyệt
Medium đã có những nỗ lực khá nghiêm túc để trả tiền cho người viết. Mô hình khác với Substack, nhưng đó là lý do
Tôi nhìn nó giống cách nhìn paywall của báo chí. Không thích nhưng hiểu vì sao nó tồn tại
Phỏng đoán hợp lý nhất là quán tính. Có những người cực kỳ trung thành với thương hiệu và cần hành động theo cách người khác đang làm
Thực ra đăng ở đâu không quan trọng, chỉ cần đưa URL là được, nhưng không phải ai cũng hành xử như vậy
Nó trông như phiên bản tiến hóa mới nhất của nền tảng blog thân thiện với người viết. Dễ đóng gói thành bản tin hơn WordPress, và cũng dễ kiếm tiền hơn bằng gói trả phí
Dùng Scribe, frontend thay thế cho Medium, sẽ dễ chịu hơn nhiều:
https://scribe.rawbit.ninja/@NMitchem/if-ai-writes-your-code...
https://sr.ht/~edwardloveall/Scribe/
https://libredirect.github.io/
Python có hệ sinh thái trưởng thành hơn Rust rất nhiều, đặc biệt là ở mảng AI/machine learning
Tôi từng gặp một crate Rust tuyên bố triển khai một thuật toán machine learning cụ thể nhưng thực tế lại không hoạt động đúng. Dù vậy, tôi vẫn có thể nhờ Claude viết một bản triển khai thay thế
Khi làm việc cùng AI, tôi nghĩ việc cưỡng chế tính đúng đắn ở cấp độ hệ thống kiểu là một ý hay, nên tôi thường chọn những ngôn ngữ như C# hay Rust hơn là Python. Tuy vậy, với một số việc thì Python rõ ràng vẫn là công cụ phù hợp
Tôi cũng có thể dùng Rust, nhưng nếu kết quả tốt thì người khác sẽ nhận được giá trị lớn hơn từ việc dùng một toolchain duy nhất, nên tôi thấy Go là hợp lý
Lý do cốt lõi là khi cần thì người khác phải đọc được nó. Và hệ sinh thái tiếp nhận cũng có ngôn ngữ mà họ kỳ vọng. Việc một số cộng đồng khoa học dữ liệu chọn R, MatLab, Julia, Python hay Mojo không phụ thuộc vào chuyện cái nào vượt trội hơn về mặt kỹ thuật, mà phụ thuộc vào chuyện đồng nghiệp của họ đang dùng gì
Đây chỉ là phỏng đoán, nhưng các ngôn ngữ có kiểu thường có language server nhanh hơn và tốt hơn, nên có thể sửa mã hiệu quả hơn bằng công cụ
Khi con người phải trực tiếp can thiệp để điều tra hoặc chỉnh sửa mã, kiểu mạnh cũng giúp định hướng dễ hơn nhiều trong đống mã spaghetti
Khi đó bạn sẽ có lợi ích của garbage collection cùng kiểu mạnh
Hiện tại thì lý do dùng Python vẫn hoàn toàn giống khi con người tự viết mã. Có nhiều người biết Python hơn các ngôn ngữ như Zig, nên con người sẽ đọc và chỉnh sửa mã dễ hơn
Tôi hiểu ý bài viết, nhưng tôi không nghĩ chúng ta đã đến mức đó
“Một ứng dụng được phát hành bằng ngôn ngữ mà không ai trong nhóm biết” nghe hay đấy. Chúng ta sẽ còn nhìn lại chuyện này trong một tương lai không xa
Câu “nhà nghiên cứu Anthropic Nicholas Carlini đã điều phối 16 agent Claude song song để viết một trình biên dịch C production bằng Rust” là không đúng sự thật
Trình biên dịch đó tạo ra mã kém xa gcc/clang, nên về cơ bản là vô dụng