âu lắm mới có hứng nói về vấn đề kỹ thuật, lần này mạnh dạn đưa ra một nhận định: async/await là một trò bịp lớn trong các ngôn ngữ lập trình – async/await is just a big scam in programming languages! Mọi người chờ 5, 10 năm nữa xem nhận định này đúng không nhé! Lâu về trước có làm một chút với async/await trên C# và JavaScript, là đã thấy nó không được đúng lắm! Gần đây làm với async/await trên Swift lại thấy càng không đúng! Những cái về threading – process – synchronization – tiến trình, tiểu trình và đồng bộ hóa là phải đọc giữa các dòng chữ – read between the lines! Còn cái mindset của những người làm ra async/await nó giống kiểu bắt chết vào ngôn từ hình thức, họ chấp vào ngôn từ bề mặt!

Async/await chỉ là vấn đề, và cũng chỉ là giải pháp của… riêng JavaScript! Khởi thuỷ xa xưa, JavaScript chỉ được phép có đúng một thread, nên để không block thread này thì họ đã tìm cách offload các hàm sang thread background của hệ thống, và vì làm việc này theo kiểu tuỳ tiện nên phải sinh ra cái async/await để “đánh dấu”, thuận tiện hơn cho việc đồng bộ hoá! Vấn đề này đơn giản là của riêng JavaScript, các ngôn ngữ khác… không thấy có! Async/await khi đem một cách khiên cưỡng sang những ngôn ngữ khác không tạo ra lợi ích nào đáng kể, ngược lại làm phức tạp hoá vấn đề và hiệu suất – performance… rất tệ! Những newbie chưa hiểu sự phức tạp của hệ thống mới thần thánh hoá và cho rằng async/await là cái gì đó siêu việt!

Async/await nó mang cái mindset 2 threads: foreground & background, xuất phát từ hạn chế chỉ được phép có một thread của JavaScript! Với những ngôn ngữ như C, C++, Obj-C, etc… thì bản thân cái không gian tính toán nó đã là n-thread, từ ngàn xưa là đã dã man, phức tạp và đa năng rồi! Chuyện với async/await không biết phải nói làm sao… nó giống như câu: “màn hình cong (curved monitor) có rất nhiều vấn đề, mà vấn đề đầu tiên là nó… cong”! 🙂 Tương tự vậy, async/await không đúng đầu tiên là ở chính 2 từ khoá đó, một kiểu chấp niệm vào hình thức khi cho rằng nếu tôi là sync, thì những code viết ra trước đây là async! Đây là kiểu chấp niệm, thực ra code block bản thân nó không sync, cũng chẳng async, là do cách xài mà thôi!

Tại sao nói async/await là vấn đề của riêng JavaScript!? Với các ngôn ngữ khác, tuyệt đại đa số các lời gọi hàm hệ thống là sync về mặt bản chất, điều này nhằm giúp cho coder hiểu rõ cái cost – chi phí gọi hàm! Chỉ một số ít hàm hệ thống là async, và coder phải hiểu rõ điều đó khi sử dụng! Trong trường hợp có nhu cầu không block main thread thì họ sẽ chạy code block trong một thread khác, chuyện này y hệt như vai trò của Task vậy! Nên async/await không đưa ra được một điều gì mới, càng không phải là cách giải quyết vấn đề mới! Nó đơn giản là cách vá lỗi lầm cũ của quá khứ, bằng cách đặt ra một cú pháp, và cú pháp này… rất thừa thải trong nhiều ngôn ngữ khác ngoài JavaScript, thêm phức tạp mà không giải quyết được chuyện gì!

Nên async/await là vấn đề của riêng JavaScript, thứ mà một lập trình viên nghiêm chỉnh còn… chưa xem là ngôn ngữ lập trình! Khi đem sang các ngôn ngữ khác, bản thân người thiết kế tính năng này chắc chắn là không hiểu được cơ bản về điều phối tiến trình, tiểu trình, đặt ra một thứ hoàn toàn không cần thiết! Async/wait hoàn toàn không phải là công cụ dùng để điều phối tiểu trình, tuyệt đối không có tính năng thay thế mutex, semaphore, critical sections, locks, etc… và do đó không thể dùng để giải các bài toán đồng bộ phức tạp như Producer/Consumer, Dining Philosophers, Sleeping Barber, etc… Đừng nhầm lẫn giữa một cú pháp “lảm nhảm” với các bài toán đồng bộ vốn rất phức tạp, và nên đầu tư thời gian học về căn bản!