Mời bạn thưởng thức Newsletter #136.

Fast and Hard Code

Theo Armin Ronacher, dù meme “lập trình đã được giải quyết” đúng tới đâu, thì việc làm quen với một ngôn ngữ không còn quan trọng, vì ma sát với con người không cản trở agent. Vì vậy, LLM khiến lựa chọn ngôn ngữ ít hệ trọng hơn nhiều so với trước. Không thích thì viết lại bằng ngôn ngữ khác, kể cả ngôn ngữ mình chưa từng biết. Hệ quả là người ta chọn ngôn ngữ dựa nhiều hơn vào hình ảnh và marketing của nó. Ông thấy nhiều người giờ ship code Rust dù trước đây sẽ không chọn nó. Ông cho rằng một phần nguyên nhân đến từ hai xu hướng gần đây: người ta nói nhiều hơn về phần mềm nhanh, và về việc LLM rất giỏi tối ưu code mà không làm thay đổi hành vi.

Những người vốn ám ảnh với hiệu năng như Mitchell Hashimoto, Charlie Marsh, Jarred Sumner, Daniel Lemire đều cởi mở với việc agent viết code, và với công cụ kiểu autoresearch, người khác cũng chỉ cần giao việc tối ưu cho agent. Ngày càng nhiều dự án muốn nhanh và nhỏ chọn “ngôn ngữ khó”. Không chỉ Rust, ngay cả Zig cũng hưởng lợi, dù cộng đồng cốt lõi khá tiêu cực với AI: dịch vụ Artifacts của Cloudflare dùng engine Git protocol viết hoàn toàn bằng Zig biên dịch ra WebAssembly khoảng 100 KB, còn Vercel ra mắt fx, một coding agent bằng Zig. Người ta cũng làm được những thứ ấn tượng với DWARF, eBPF, network driver tự viết, crypto và phần cứng rất cũ, những lĩnh vực từng ngoài tầm với. Có thể thế giới sẽ nhiều “slop” hơn, nhưng cũng sẽ có thêm những lập trình viên muốn phần mềm nhanh và nhỏ.

Shipping Video Calling on Facebook

Philip Su nhớ lại 16 năm trước, khi ông là kỹ sư thứ hai của văn phòng Facebook Seattle, sau mười hai năm làm ở Microsoft. Khi đó Facebook chỉ có khoảng 500 kỹ sư, tương lai còn chưa chắc chắn, và ông chọn làm kỹ sư toàn thời gian duy nhất cho tính năng video calling đầu tiên, sau này có thêm những người như Denise Noyes và Vijaye Raji. Team nhỏ tới mức review sản phẩm trực tiếp với Mark Zuckerberg. Thời đó WebRTC chưa phổ biến, nên Facebook ký hợp đồng với Skype để dùng binary phía client, người dùng phải cài trước khi gọi. Su thẳng thắn chê code Skype rất tệ: tỷ lệ thiết lập cuộc gọi thành công chỉ 82%, và khi ông hỏi số liệu của chính họ, câu trả lời là “chúng tôi không có số đó”, vì họ chỉ tin vào mức hài lòng do người dùng báo cáo. Ngược lại, việc dùng kênh dữ liệu của Messenger để thiết lập cuộc gọi cũng phơi bày tỷ lệ tin nhắn thất lạc của chính Facebook, buộc công ty cải thiện hạ tầng.

Sáu tuần sau khi ra mắt là quãng thời gian làm việc cật lực nhất trong sự nghiệp của ông: hotfix nối tiếp hotfix, làm từ 8 giờ sáng tới nửa đêm mỗi ngày, ăn toàn đồ ăn vặt, vậy mà vẫn sụt hơn 10 pound. Một chi tiết thú vị là nhạc chuông cuộc gọi chính là các nốt F-A-C-E. Kết thúc giai đoạn đó, sản phẩm kết nối ổn định hơn, và đó cũng là lần đầu ông nói chuyện video với bố mẹ. Giờ đây, sau COVID và nhờ WebRTC, video calling đã thành chuyện thường ngày.

AI is removing the middle class of software engineering

Florian Herrengt mở đầu bằng một kịch bản quen thuộc năm 2026: sáng thứ Hai, senior engineer mở máy và thấy bảy PR cần review, cái đầu tiên dài hơn 24 nghìn dòng kèm mô tả do AI viết. Khi một bug lạ xuất hiện lần thứ tư, người viết tính năng không giải thích được dữ liệu đến từ đâu, chỉ biết hỏi lại Claude. Theo tác giả, AI đã gỡ bỏ giới hạn tốc độ: dự án có văn hóa kỹ thuật yếu giờ thất bại nhanh hơn nhiều, và điều bi kịch là với con mắt thiếu kinh nghiệm, mọi thứ trông vẫn chạy. Sửa một quyết định tồi rất khó, chẳng hạn LLM thêm bảng vào database chỉ mất mười phút, nhưng gỡ ra khi đã có dữ liệu thật đòi hỏi kế hoạch migration cẩn thận.

Kỹ sư tồi luôn tồn tại, nhưng khác biệt nằm ở tốc độ, như đâm xe ở 30 km/h so với 200 km/h. Code review, test và CI vẫn còn đó, chỉ là chúng được thiết kế cho thế giới mà tạo ra lượng thay đổi khổng lồ là điều không thể. Người tạo mười PR một ngày có thể chỉ đang đẩy công việc sang những người khó thay thế nhất trong team. Tác giả dự đoán AI sẽ kéo giãn khoảng cách lương: kỹ sư giỏi đáng giá hơn vì AI giúp họ đi nhanh hơn, còn người thiếu óc phán đoán để đánh giá đề xuất của LLM sẽ khó được tuyển. Ông dùng AI mỗi ngày, nhưng vấn đề nằm ở việc dùng AI thay cho hiểu biết thay vì để xây dựng hiểu biết.

The fastest double-to-string algorithm you’ve never heard of

Victor Zverovich, tác giả thư viện Żmij, giới thiệu một trong những thuật toán dtoa, tức đổi số double thành chuỗi, nhanh nhất hiện nay nhưng gần như vô danh. Nó nằm trong file yy_double.c của thư viện JSON yyjson do ibireme viết, không có paper, không có tên riêng ngoài tên file, nên tác giả gọi tắt là “yy”. Bản thân Żmij ban đầu là một bản port tối ưu của Schubfach, sau đó đã chuyển phần lõi sang yy. Thuật toán thuộc họ Schubfach: tìm số thập phân ngắn nhất mà khi đọc ngược lại vẫn ra đúng giá trị float ban đầu, bằng cách chọn lưới thập phân thô nhất có điểm nằm trong khoảng làm tròn.

Điểm khác biệt chính là yy chỉ cần một phép nhân với lũy thừa của 10 đã tính sẵn, trong khi Schubfach cổ điển cần hai hoặc ba phép nhân 192-bit. Với mỗi số, yy chọn số mũ thập phân bằng xấp xỉ fixed-point của log10(2), rồi xét bốn ứng viên, hai trên lưới mịn và hai trên lưới thô gồm các bội của 10. Ba predicate quyết định kết quả, ưu tiên ứng viên lưới thô ngắn hơn nếu round-trip được. Độ rộng nửa ulp được suy ra bằng phép dịch bit thay vì nhân thêm, còn trường hợp hòa được xử lý theo round-half-to-even bằng cách kiểm tra bit thấp của significand. Bài viết kèm một công cụ tương tác trên float 8-bit E4M3 để minh họa các trường hợp biên, chẳng hạn giá trị 192 được in thành “2e2” thay vì “19e1” nhờ một số hạng hiệu chỉnh. Tác giả kết luận rằng những thuật toán sống trong thư viện JSON hiếm khi nhận được sự ghi nhận như các thuật toán có paper.

Quake Shareware, a CD-ROM just a little too full

Fabien Sanglard kể lại câu chuyện chiếc CD shareware của Quake năm 1996. Giữa thập niên 90, CD-ROM 640 MiB có dung lượng vượt xa lượng asset mà nhà phát triển game làm ra được. Bản shareware Quake chỉ dùng 22 MiB, nên id Software nảy ra ý tưởng tận dụng phần còn lại: nhét thêm bản mã hóa của toàn bộ game trong danh mục id. Người chơi mua CD giá 9,95 USD, gọi số 1-800-ID-GAMES, đọc một mã CHALLENGE cho nhân viên, trả tiền rồi nhận về mã SERIAL để mở khóa. CHALLENGE thay đổi mỗi lần chạy để chống replay attack. Công cụ khóa do TestDrive Corp cung cấp, “biến tính” file EXE bằng cách ghi đè 32 KiB đầu và mã hóa phần header gốc thành file riêng. Thế nhưng chỉ 39 ngày sau khi CD lên kệ, nhóm hacker GNOMON tung ra QCRACK.EXE, tự sinh SERIAL từ CHALLENGE cho mọi game trên đĩa. Theo cuốn Masters of Doom, id bị kẹt lại với gần 150 nghìn đĩa CD trong kho.

Lỗ hổng nằm ở chỗ SERIAL không chứa bí mật nào, nó chỉ là bằng chứng đã trả tiền. Chương trình mở khóa FLOW.EXE trên đĩa tự sinh được SERIAL từ CHALLENGE và chỉ so sánh với giá trị người dùng nhập, nên toàn bộ cơ chế bảo vệ dựa vào security by obscurity. Ông còn tìm ra nhiều sơ suất khác: Final DOOM không thể mở khóa qua tổng đài vì lỗi chính tả “Final” viết hoa trong file SKU.17, file mã hóa này lại có sẵn bản plain-text SKU.TXT ngay trên đĩa. Ông lý giải bằng “Fab’s Razor”: đừng quy cho sự ngu ngốc những gì có thể quy cho áp lực thời gian.

How Instacart Built a Modern Search Infrastructure on Postgres

Đội ngũ Instacart kể lại hành trình xây hạ tầng search cho catalog hàng tỷ sản phẩm từ hàng nghìn nhà bán lẻ, với hàng triệu lượt tìm kiếm và hàng tỷ lượt ghi mỗi ngày do giá, tồn kho, khuyến mãi thay đổi liên tục. Ban đầu full-text search chạy trên Elasticsearch, nhưng data model phi chuẩn hóa cùng lượng partial update khổng lồ khiến cluster quá tải, sửa dữ liệu sai có khi mất nhiều ngày. Họ chuyển sang các instance Postgres được shard, dữ liệu chuẩn hóa cao, dùng GIN index và phiên bản tùy biến của ts_rank. Kết quả là khối lượng ghi giảm 10 lần, có thể index hàng trăm GB feature ML trong các bảng riêng rồi join bằng SQL, và search nhanh gấp đôi nhờ đẩy tính toán xuống gần dữ liệu trên NVMe thay vì kéo dữ liệu lên tầng ứng dụng.

Năm 2021, họ thêm semantic search bằng một service ANN riêng dùng FAISS với embedding từ mô hình MiniLM, kết quả hai nguồn được trộn ở tầng ứng dụng. Kiến trúc này buộc phải overfetch rồi lọc sau, khó tối ưu cách kết hợp hai cơ chế retrieval, và tốn công giữ hai hệ thống đồng bộ. Giải pháp cuối cùng là hybrid search ngay trong Postgres với pgvector, dùng thông tin tồn kho thời gian thực làm pre-filter. Họ thay hàng trăm index HNSW theo từng retailer bằng các index gộp theo đặc điểm retailer, tăng số parallel worker và lưu embedding inline thay vì TOAST. pgvector chậm hơn FAISS chút ít với retailer lớn nhưng recall tốt hơn. A/B test cho thấy số lượt tìm kiếm không có kết quả giảm 6%, kéo theo doanh thu tăng đáng kể.

curl performance

Daniel Stenberg kể chuyện curl cuối cùng cũng có bộ test hiệu năng công khai tại curl.se/perf, sau nhiều năm ý tưởng này bị gác lại vì quá khó và không ai nhận làm. Thấy Grafana quá phức tạp, ông quyết định không để sự hoàn hảo cản trở điều tốt và bắt đầu bằng những gì mình đã biết. Hạ tầng cloud dùng chung không đủ ổn định cho test hiệu năng, nên ông chạy trên chính máy phát triển nhiều nhân của mình. Một shell script cập nhật source từ git, build và chạy test, chẳng hạn tốc độ tải file 100 GB từ localhost hay số lần và kích thước cấp phát bộ nhớ cho một HTTP download. Script thứ hai phân tích log và vẽ biểu đồ, script thứ ba chạy qua crontab mỗi hai mươi phút, rồi kết quả tự động được đẩy lên website. Chỉ vài giờ sau khi dữ liệu công khai, các developer đã gửi thay đổi để cải thiện số liệu, minh bạch thật sự giúp ích.

Mỗi commit được build nhiều lần, biểu đồ lưu giá trị lớn nhất, trung vị và nhỏ nhất. Vì điều kiện test như phần cứng hay phiên bản thư viện sẽ thay đổi, số liệu chủ yếu hữu ích trong ngắn hạn để phát hiện regression vô tình. Để theo dõi thay đổi chậm trong dài hạn, ông đặt các “stake”, ngưỡng đặt tay cho từng test, kết hợp thuật toán LTTB để downsample biểu đồ dài hạn và Mann-Kendall cùng Sen’s Slope để nhận diện xu hướng. Một bài học sớm là sự đánh đổi: giảm số lần cấp phát bộ nhớ lại khiến một struct chính phình to hơn mong muốn. Hiện có 24 test, mỗi vòng khoảng sáu phút.

Compression is prediction

Annie Sexton của ngrok dẫn dắt người đọc qua các khái niệm nén dữ liệu bằng một loạt demo tương tác, để đi tới kết luận: nén chính là dự đoán, và LLM là những bộ nén. Nén thật sự khai thác sự dư thừa, chẳng hạn run-length encoding thay chuỗi lặp bằng cặp ký tự và số lần. Một bộ nén gồm ba phần: transform chuẩn bị dữ liệu, model gán xác suất cho từng ký hiệu, và entropy coder biến xác suất thành dòng bit. Arithmetic coding thu hẹp dần khoảng từ 0 tới 1 theo xác suất của từng ký hiệu, nên cả thông điệp chỉ còn là một con số. Entropy, trung bình của −log₂ xác suất, là giới hạn lý thuyết cho nén lossless. Huffman coding, dùng trong gzip và Brotli, gán mã ngắn cho ký hiệu phổ biến nhưng phải làm tròn tới số bit nguyên.

Xác suất trở nên chính xác hơn khi xét ngữ cảnh: chữ “U” hiếm trong tiếng Anh, nhưng gần như chắc chắn xuất hiện sau “Q”. LLM cũng dự đoán phân phối xác suất cho token kế tiếp, nên mã hóa token thật tốn −log₂ xác suất bit: đoán đúng và tự tin thì rẻ, tự tin mà sai thì đắt. Với một đoạn văn của Dickens, model bậc một cần 24% kích thước gốc, còn GPT-2 kết hợp arithmetic coding chỉ cần 10%. LLM không được dùng để nén hằng ngày vì cả hai đầu cần hàng gigabyte trọng số. Nén lossless gần như đã được giải quyết, bài toán còn lại là xây dựng bộ dự đoán tốt hơn, và huấn luyện LLM để giảm cross-entropy cũng chính là xây dựng một bộ nén.

How Anthropic Builds And How Engineering Will Change Soon

Ryan Peterman trò chuyện với Thariq Shihipar, kỹ sư trong team Claude Code, về cách Anthropic khai thác model cho công việc kỹ thuật. Lời khuyên đầu tiên khi onboard là coi Claude như một người cùng suy nghĩ, cung cấp đủ ngữ cảnh, và tìm cách lên một tầng trừu tượng cao hơn: xây hệ thống tạo ra hệ thống thay vì chỉ xây sản phẩm. Thariq cho rằng harness ngày càng quan trọng chứ không bớt đi: model càng giỏi, chạy càng lâu thì càng cần những phần mềm phức tạp như Auto mode, sandbox hay Artifacts để làm việc an toàn và trình bày kết quả. Ông dùng Fable để lập kế hoạch, brainstorm và viết spec chi tiết, rồi dùng Claude Opus 5 để hiện thực. Loop engineering, tức dựng hệ thống tự prompt Claude, giúp team theo dõi những issue trước đây không xuể, nếu skill và khâu kiểm chứng tốt.

Về viết lách, quy tắc của ông là chỉ gửi output nếu sẵn sàng cho người khác xem prompt; báo cáo dữ liệu thì để Claude viết, còn các bài essay nội bộ đề xuất hướng đi gần như luôn do người viết. Về bảo trì code, naming và style bớt quan trọng, thay vào đó cần skill đơn giản hóa và lượng code kiểm thử nhiều hơn khoảng 100 lần trước đây. Để giảm sự cố, Anthropic hướng tới môi trường test lý tưởng có thể replay request và chaos test mọi thứ. Học code vẫn rất đáng: chỉ người hiểu kỹ thuật mới đánh giá được phần mềm tốt, và “coding đã được giải quyết” chỉ có nghĩa là lập trình không còn khó đoán như trước.

A faster way to convert a timestamp ➜ Hour, Min, Sec

Tiếp nối bài viết về cách tính thứ trong tuần, Ben Joffe giải bài toán tách số giây trong ngày (0 tới 86399) thành giờ, phút, giây. Theo ông, đa số thư viện date làm việc này mất khoảng 16 chu kỳ CPU, trong khi có thể chỉ tốn độ trễ cỡ hai phép nhân. Cách truyền thống chia lấy giờ, lấy phần dư rồi chia tiếp, tạo thành một chuỗi phụ thuộc dài. Cách thứ hai, được V8, Boost và musl dùng, tính từng trường độc lập. Cassio Neri (2020) dùng phép nhân 64-bit và tái sử dụng nửa cao, nửa thấp của tích, được chọn làm mốc so sánh. Biến thể V1 của ông phá chuỗi phụ thuộc bằng cách tính time / 60 và time / 3600 song song, rồi suy ra giây và phút bằng phép trừ.

V2 dùng số học fixed-point: nhân với 2³²/3600 + 1 để lấy giờ từ 32 bit cao, rồi nhân phần thấp với 60 để lấy phút; tương tự cho giây. V3 áp dụng mẹo modulo từ bài viết trước, tính giây bằng (time + 4*tmin) % 64, vì 60 = 64 − 4. Ngoài ra còn có phiên bản cho mili giây, leap second, ARM NEON SIMD và biến thể SWAR của Consroe. Trên Apple M4 Pro, V1, V2, V3 lần lượt tốn 0,65, 0,64 và 0,60 lần thời gian của Neri; trên Ryzen 9 9950X3D với Clang, V2 và V3 chỉ còn 0,49 lần. Kỹ thuật đã được thư viện Java ITU và Elixir áp dụng. Lưu ý là các biến thể nhanh chỉ đúng trong một miền giá trị giới hạn và kết quả phụ thuộc nền tảng. Ông khuyên V2 là lựa chọn toàn diện nhất cho đa số thư viện.

Bonus

Videos: Giải thích HTTP và HTTPS

Video của ByteByteGo so sánh HTTP và HTTPS, giải thích cách HTTPS dùng TLS để mã hóa dữ liệu và xác thực server, giúp kết nối giữa trình duyệt và website an toàn hơn.

Images: