asyncio hiện tại được thiết kế với GIL là tiền đề, nói theo một cách nào đó thì nó là chiến lược né tránh GIL, nên GIL không trực tiếp tương tác với asyncio.
Nhưng nếu nhìn từ góc độ toàn bộ lập trình đồng thời vận hành dựa trên asyncio, thì tôi nghĩ cách nói rằng GIL không liên quan sẽ thành ra giống như kiểu “vì là Python nên không làm được cũng là chuyện đương nhiên.”
Tôi đồng ý rằng không thể kỳ vọng định hướng hiện tại đối với GIL sẽ trở thành một lựa chọn không hề kém cạnh ngay cả khi so với "các phương án thay thế khác"
nhưng tôi nghĩ lập luận rằng nên chọn một phương án khác ngoài Python không nên dẫn đến giọng điệu cho rằng không có vấn đề gì, mà phải dẫn đến giọng điệu thừa nhận rằng có vấn đề chứ?
Lần này tôi đã thử làm web chỉ vì hứng thú cá nhân, một lĩnh vực hoàn toàn không liên quan đến mảng tôi vốn phát triển. Tôi làm một bảng tin bằng next.js v15 app router, nhưng mỗi khi đọc những bài như thế này thì cảm giác như động lực muốn thử cái mới ở phía web lại mất đi. Sao hệ sinh thái lại bất ổn đến vậy nhỉ. Rồi lỡ lại có thứ mới xuất hiện thì mọi người lại ào ào chạy theo, dùng một thời gian, vừa chê vừa đi tìm thứ khác sao. Mảng phát triển web đúng là chắc khó thật.
Quyền lực và tiền bạc đúng là động lực để duy trì một dự án.
Mỗi lần thấy những trang web không hoạt động bình thường nếu không dùng Chromium thì lại không khỏi thở dài.
Thành thật mà nói... ngoài Google thì có lẽ không có công ty nào đủ sức duy trì Chrome ở mức này. Hơn nữa, dù không đến mức như chất bán dẫn, nhưng sức chi phối thị trường trình duyệt web cũng là điều mà Mỹ không muốn đánh mất.... Có lẽ từ nay về sau họ vẫn sẽ chấp nhận một mức độ độc quyền nhất định.
Dù trong bài không nói rõ ràng, nhưng liệu có thể hiểu rằng khi dùng AI để viết code, vì không quen thuộc như code do con người tự tay viết nên nó có thể trở thành một khoản nợ hay không?
Ủa, tôi cũng là người dùng trả phí mà haha
Tìm lại lịch sử trên App Store thì thấy từ bản 1.51 nó đã trở thành miễn phí.
Với tôi đây là công cụ thiết yếu vì thiết lập màn hình trên MacBook thay đổi theo từng nơi sử dụng.
Có vẻ như GIL được nhắc đến hơi đột ngột thì phải.. ngay cả khi GIL bị loại bỏ
nếu muốn dùng multithread cho cả tác vụ I/O bound lẫn CPU bound
thì có lẽ nên chọn một phương án thay thế khác thay vì Python..
Dường như asyncio khá bị những người đào sâu Python không thích.
Tôi cũng thường nghe ý kiến rằng lẽ ra gevent mới nên trở thành dòng chính.
Mọi người dùng asyncio khá nhiều đấy.. dùng ổn.. có một giới hạn là việc hủy tác vụ được thiết kế theo kiểu edge-triggered (không phải level-triggered), nhưng thực ra cũng không mấy khi phải viết code vừa nhận biết việc hủy tác vụ vừa xử lý graceful cho lắm, và vấn đề lớn hơn là event loop chỉ giữ weak reference tới task nên nó có thể biến mất do GC.. nhưng chuyện đó được giải quyết bằng structured concurrency.
Với hầu hết các tác vụ I/O chính thì không có vấn đề gì khi tìm thư viện hỗ trợ asyncio..
Còn GIL? Thật ra không liên quan nhiều đâu.. ngay từ cách tiếp cận dùng asyncio để chạy song song các tác vụ CPU intensive đã hơi kỳ rồi.. nếu GIL được cải thiện thì nó sẽ hữu ích cho multithreading CPU intensive.. còn async là để vận hành hiệu quả nhất có thể ở những đoạn nghẽn I/O...
Dù sao thì kết luận là.. tuy có một số vấn đề trong thiết kế, nhưng để đạt được mục tiêu thì tôi vẫn dùng tốt trong production mà không gặp vấn đề gì đáng kể.
Tất nhiên, lý do lớn hơn có thể là vì do GIL nên lợi ích có thể thu được ngay từ đầu vốn đã ít hơn so với các môi trường khác.
Tôi cho rằng cách nói rằng nếu không có GIL thì có thể tạo ra hiệp lực là gần như mang tính ngụy biện. Với một vận động viên chạy bộ bị mất một chân, nếu gắn cho họ một chân giả dù còn nhiều bất tiện, thì đó có gọi là "hiệp lực" không?
Vấn đề của Asyncio không nằm ở độ khó của lập trình bất đồng bộ vốn đã khó, mà là ở chất lượng kém. Một thiết kế vứt bỏ tính nhất quán và tính phổ quát thì trong Python cũng chẳng phải chuyện hiếm, nhưng những thứ như ProactorEventLoop thì đến cả lỗi gây gián đoạn dịch vụ đã được báo cáo từ 5 năm trước vẫn còn chưa được xử lý.
Với những người ở thế buộc phải dùng nó, kiểu bài viết như thế này thật sự rất khó để chỉ cười cho qua.
Khó mà khái quát hóa, nhưng nhìn chung có khá nhiều anh/chị PO, PM và designer có quan điểm rằng sự phát triển của AI đã mở ra nhiều cơ hội hơn cho những người làm PO, PM.
Ngược lại, có vẻ cũng có nhiều lập trình viên kỳ vọng rằng nhờ sự phát triển của AI, họ sẽ có thể tự mình phát triển sản phẩm tốt hơn mà không nhất thiết cần PO, PM hay designer.
asynciohiện tại được thiết kế với GIL là tiền đề, nói theo một cách nào đó thì nó là chiến lược né tránh GIL, nên GIL không trực tiếp tương tác vớiasyncio.Nhưng nếu nhìn từ góc độ toàn bộ lập trình đồng thời vận hành dựa trên
asyncio, thì tôi nghĩ cách nói rằng GIL không liên quan sẽ thành ra giống như kiểu “vì là Python nên không làm được cũng là chuyện đương nhiên.”Tôi đồng ý rằng không thể kỳ vọng định hướng hiện tại đối với GIL sẽ trở thành một lựa chọn không hề kém cạnh ngay cả khi so với "các phương án thay thế khác"
nhưng tôi nghĩ lập luận rằng nên chọn một phương án khác ngoài Python không nên dẫn đến giọng điệu cho rằng không có vấn đề gì, mà phải dẫn đến giọng điệu thừa nhận rằng có vấn đề chứ?
Lần này tôi đã thử làm web chỉ vì hứng thú cá nhân, một lĩnh vực hoàn toàn không liên quan đến mảng tôi vốn phát triển. Tôi làm một bảng tin bằng next.js v15 app router, nhưng mỗi khi đọc những bài như thế này thì cảm giác như động lực muốn thử cái mới ở phía web lại mất đi. Sao hệ sinh thái lại bất ổn đến vậy nhỉ. Rồi lỡ lại có thứ mới xuất hiện thì mọi người lại ào ào chạy theo, dùng một thời gian, vừa chê vừa đi tìm thứ khác sao. Mảng phát triển web đúng là chắc khó thật.
Quyền lực và tiền bạc đúng là động lực để duy trì một dự án.
Mỗi lần thấy những trang web không hoạt động bình thường nếu không dùng Chromium thì lại không khỏi thở dài.
Thành thật mà nói... ngoài Google thì có lẽ không có công ty nào đủ sức duy trì Chrome ở mức này. Hơn nữa, dù không đến mức như chất bán dẫn, nhưng sức chi phối thị trường trình duyệt web cũng là điều mà Mỹ không muốn đánh mất.... Có lẽ từ nay về sau họ vẫn sẽ chấp nhận một mức độ độc quyền nhất định.
Dù thấy bất tiện, nhưng dùng một thời gian thì chẳng phải sẽ nhanh quen thôi sao?
Con người là loài động vật có khả năng thích nghi.
Dù trong bài không nói rõ ràng, nhưng liệu có thể hiểu rằng khi dùng AI để viết code, vì không quen thuộc như code do con người tự tay viết nên nó có thể trở thành một khoản nợ hay không?
Ủa, tôi cũng là người dùng trả phí mà haha
Tìm lại lịch sử trên App Store thì thấy từ bản 1.51 nó đã trở thành miễn phí.
Với tôi đây là công cụ thiết yếu vì thiết lập màn hình trên MacBook thay đổi theo từng nơi sử dụng.
Đâu phải đang viết luận văn đâu mà...
Có vẻ như GIL được nhắc đến hơi đột ngột thì phải.. ngay cả khi GIL bị loại bỏ
nếu muốn dùng multithread cho cả tác vụ I/O bound lẫn CPU bound
thì có lẽ nên chọn một phương án thay thế khác thay vì Python..
Dường như
asynciokhá bị những người đào sâu Python không thích.Tôi cũng thường nghe ý kiến rằng lẽ ra
geventmới nên trở thành dòng chính.Cảm ơn bạn đã giới thiệu ứng dụng hay.
Tôi đã viết thêm.
Mọi người dùng
asynciokhá nhiều đấy.. dùng ổn.. có một giới hạn là việc hủy tác vụ được thiết kế theo kiểu edge-triggered (không phải level-triggered), nhưng thực ra cũng không mấy khi phải viết code vừa nhận biết việc hủy tác vụ vừa xử lý graceful cho lắm, và vấn đề lớn hơn là event loop chỉ giữ weak reference tới task nên nó có thể biến mất do GC.. nhưng chuyện đó được giải quyết bằng structured concurrency.Với hầu hết các tác vụ I/O chính thì không có vấn đề gì khi tìm thư viện hỗ trợ
asyncio..Còn GIL? Thật ra không liên quan nhiều đâu.. ngay từ cách tiếp cận dùng
asynciođể chạy song song các tác vụ CPU intensive đã hơi kỳ rồi.. nếu GIL được cải thiện thì nó sẽ hữu ích cho multithreading CPU intensive.. còn async là để vận hành hiệu quả nhất có thể ở những đoạn nghẽn I/O...Dù sao thì kết luận là.. tuy có một số vấn đề trong thiết kế, nhưng để đạt được mục tiêu thì tôi vẫn dùng tốt trong production mà không gặp vấn đề gì đáng kể.
Dù là tấn công MITM đi nữa thì họ đã giải được giao tiếp HTTPS bằng cách nào vậy? Có phải chỉ mình tôi không biết không?
So với Biome thì tốc độ sẽ như thế nào nhỉ?
Tôi cứ dùng joblib thôi
Tất nhiên, lý do lớn hơn có thể là vì do GIL nên lợi ích có thể thu được ngay từ đầu vốn đã ít hơn so với các môi trường khác.
Tôi cho rằng cách nói rằng nếu không có GIL thì có thể tạo ra hiệp lực là gần như mang tính ngụy biện. Với một vận động viên chạy bộ bị mất một chân, nếu gắn cho họ một chân giả dù còn nhiều bất tiện, thì đó có gọi là "hiệp lực" không?
Trong số những nơi mô tả nội dung liên quan, đây là tài liệu được sắp xếp tốt nhất.
Vấn đề của Asyncio không nằm ở độ khó của lập trình bất đồng bộ vốn đã khó, mà là ở chất lượng kém. Một thiết kế vứt bỏ tính nhất quán và tính phổ quát thì trong Python cũng chẳng phải chuyện hiếm, nhưng những thứ như ProactorEventLoop thì đến cả lỗi gây gián đoạn dịch vụ đã được báo cáo từ 5 năm trước vẫn còn chưa được xử lý.
Với những người ở thế buộc phải dùng nó, kiểu bài viết như thế này thật sự rất khó để chỉ cười cho qua.
Khó mà khái quát hóa, nhưng nhìn chung có khá nhiều anh/chị PO, PM và designer có quan điểm rằng sự phát triển của AI đã mở ra nhiều cơ hội hơn cho những người làm PO, PM.
Ngược lại, có vẻ cũng có nhiều lập trình viên kỳ vọng rằng nhờ sự phát triển của AI, họ sẽ có thể tự mình phát triển sản phẩm tốt hơn mà không nhất thiết cần PO, PM hay designer.
Tương lai sẽ ra sao thì cứ chờ xem vậy nhé haha