Loại thuốc như thế này thỉnh thoảng cũng xuất hiện trên tin tức, nhưng nhìn chung dường như không vượt quá mức của thuốc làm giãn đồng tử.... Khi dùng lâu dài thì dường như chưa có bằng chứng về tính an toàn.
Có lẽ thuốc này cũng chỉ an toàn khi sử dụng khoảng một đến hai lần một tuần. Nếu dùng thường xuyên hơn và trong thời gian dài có thể gây ra nhiều vấn đề.
Vấn đề “import vòng lặp” của Python chẳng phải đã có hướng giải quyết khá rõ ràng rồi sao? Để xem đó là một vấn đề nghiêm trọng thì tôi thấy vẫn hơi gượng ép.
Cá nhân tôi thấy claude-code có vẻ tốt hơn cho việc refactoring.
Khi dùng cursor + GPT5 để làm các tác vụ refactoring như xóa các phương thức không cần thiết, claude-code tìm và xóa khá tốt, trong khi GPT5 cho tôi cảm giác là chưa nắm được toàn cảnh của dự án.
Niko Matsakis, ngoài rayon, còn ở vị thế gần như cha đẻ của Rust. Tất nhiên Graydon Hoare là người sáng lập, nhưng có thể nói Niko mới là người đóng góp nhiều nhất vào những phần quan trọng nhất của ngôn ngữ.
Trong dòng phát triển kinh nghiệm từ coder => lập trình viên thiết kế kiến trúc phát triển tính năng => kiến trúc lớn hơn (hệ thống, mạng, bảo mật) => hoạch định,
Có vẻ như cơ hội để coder học hỏi tại hiện trường sẽ ngày càng ít đi.
Nếu lập trình lấy ý tưởng làm trung tâm trở thành xu thế chủ đạo,
thì ít nhất cảm giác là coder có thể tự mình xử lý full-stack dựa trên AI sẽ trở thành tiêu chuẩn cơ bản thôi
Cũng có thể nghĩ như vậy. Theo kinh nghiệm của tôi, so với PyO3 thì python.h (đây cũng là lý do zig là một lựa chọn thay thế tốt) giúp đi xuống rồi quay lại ở mức OS hoặc vectorize dễ hơn nhiều, nhưng xét ở khía cạnh không phải lo về quản lý bộ nhớ thì từ một quy mô nhất định trở lên, phía Rust có thể đem lại năng suất dài hạn cao hơn.
Lý do C dễ là vì nó là nền tảng của các ngôn ngữ lớn hiện đại - Python/TS/Go/PHP/Java - hoặc có cú pháp tương tự, nên không chỉ là cú pháp đơn giản mà còn vì đó là ngôn ngữ mà rồi một lúc nào đó bạn sẽ gặp, hoặc là ngôn ngữ mà trước đây bạn đã từng gặp. Ngược lại, Rust đứng ở phía đối diện, nên dù giá trị của nó cao, để đưa vào trong một đội ngũ vẫn cần khá nhiều nỗ lực. Tôi nghĩ là vì đây là một ngôn ngữ mang tính cách tân hơn là một ngôn ngữ tiến hóa.
Có vẻ như bản dịch của tiêu đề có sai sót.
Nội dung có vẻ là về việc chỉnh sửa tình trạng tật viễn thị do lão thị gây ra.
Trong tiếng Hàn, khái niệm này chỉ trạng thái “chỉ nhìn rõ ở gần”, tức là near vision acuity.
Cụm từ "fix near vision" có nghĩa là đã khắc phục vấn đề về tầm nhìn gần (một phần trước đó chưa tốt),
nên đúng hơn là phải nói rằng đã hiệu chỉnh tật viễn thị do lão thị gây ra, hay nói cách khác là đã chỉnh thị lực gần.
Tôi muốn nói rằng lý do chuyển từ C sang Rust thực ra là vì năng suất. Hỗ trợ an toàn bộ nhớ cũng rất tốt, nhưng chỉ riêng cargo thôi cũng đã là lý do đủ để chuyển sang rồi.
Khi tạo mô-đun mở rộng cho Python, việc xử lý GIL luôn phức tạp bất kể ngôn ngữ nào. Phần này thì C/C++ cũng vậy; tất nhiên sẽ có ngoại lệ nếu dùng các thư viện hoặc công cụ hỗ trợ viết mô-đun mở rộng, nhưng Rust cũng có một crate tuyệt vời là PyO3.
Ngoài ra, từ góc nhìn của một lập trình viên C thì đương nhiên Zig rất dễ làm việc cùng. Về cơ bản, bản thân Zig cũng là một trình biên dịch C, đến mức có thể chỉ cần import trực tiếp các file header để sử dụng.
Tôi vẫn chưa thấy đủ lý do để chuyển từ C sang Rust cho mã hiệu năng cao. Những ngôn ngữ như Zig, với cú pháp ít nhiều còn đơn giản hơn, có vẻ phù hợp hơn cho phát triển end-to-end; còn các trường hợp khác thì dù sao cấu trúc cũng là sau khi profiling mới chỉ triển khai những phần được gọi từ ngôn ngữ cấp cao (tôi là người dùng Python). Nếu dùng Rust, chi phí phát triển cho việc tương tác với ngôn ngữ khác, như kiểm soát GIL chẳng hạn, lại cao hơn dự kiến khá nhiều. C thì vốn dĩ là thứ mà các ngôn ngữ khác đã trông đợi sẵn rồi.
Tôi đã gặp khá nhiều khó khăn, nên khi thấy PR đã được merge, tôi đã viết một bài blog. Vì “show” là nơi giới thiệu sản phẩm do mình tự phát triển nên có vẻ không phù hợp, nên tôi đăng bài này như một bản tin thông thường, mặc dù chưa chắc đã đúng.
Có vẻ đây là bài viết của người đã tạo ra crate rayon của Rust.
Python và TypeScript hiện giờ đúng là vẫn có vẻ là những ngôn ngữ trung tâm...
Rust thì vẫn chưa ở vị thế đến mức đó. Có lẽ là vì mọi người vẫn nghĩ nó khó.
Mong là LLM sẽ hạ thấp rào cản tiếp cận để Rust cũng vươn lên thành một ngôn ngữ trung tâm.
Loại thuốc như thế này thỉnh thoảng cũng xuất hiện trên tin tức, nhưng nhìn chung dường như không vượt quá mức của thuốc làm giãn đồng tử.... Khi dùng lâu dài thì dường như chưa có bằng chứng về tính an toàn.
Có lẽ thuốc này cũng chỉ an toàn khi sử dụng khoảng một đến hai lần một tuần. Nếu dùng thường xuyên hơn và trong thời gian dài có thể gây ra nhiều vấn đề.
Omarchy, bản phân phối Linux do DHH tạo ra
Khá giống với https://write.hada.io/ mà tôi đã làm từ khá lâu trước đây. Nếu bỏ phần hỗ trợ Markdown và task thì haha
Vấn đề “import vòng lặp” của Python chẳng phải đã có hướng giải quyết khá rõ ràng rồi sao? Để xem đó là một vấn đề nghiêm trọng thì tôi thấy vẫn hơi gượng ép.
Cá nhân tôi thấy
claude-codecó vẻ tốt hơn cho việc refactoring.Khi dùng cursor + GPT5 để làm các tác vụ refactoring như xóa các phương thức không cần thiết,
claude-codetìm và xóa khá tốt, trong khi GPT5 cho tôi cảm giác là chưa nắm được toàn cảnh của dự án.Có khá nhiều lỗi vặt (đặc biệt là liên quan đến thẻ tag), nhưng có vẻ đây vẫn là một công cụ có thể tiếp tục dùng trong lúc chờ cập nhật.
Niko Matsakis, ngoài
rayon, còn ở vị thế gần như cha đẻ của Rust. Tất nhiên Graydon Hoare là người sáng lập, nhưng có thể nói Niko mới là người đóng góp nhiều nhất vào những phần quan trọng nhất của ngôn ngữ.Chắc dùng passkey rồi mà làm mất thiết bị thì thật sự sẽ rất khó xử...
Nếu là nhà phát triển Rust thì chắc hẳn sẽ có phần thiên vị vì yêu thích hơn rồi! Cảm ơn bạn đã chia sẻ thông tin.
Tôi cũng đang dùng Claude Code rất hài lòng.
Giờ chắc tôi cũng đã dùng được khoảng 6 tuần rồi.
Phần lớn nội dung đều rất đồng cảm.
https://jeho.page/essay/2025/07/15/claude-code.html
Trong dòng phát triển kinh nghiệm từ coder => lập trình viên thiết kế kiến trúc phát triển tính năng => kiến trúc lớn hơn (hệ thống, mạng, bảo mật) => hoạch định,
Có vẻ như cơ hội để coder học hỏi tại hiện trường sẽ ngày càng ít đi.
Nếu lập trình lấy ý tưởng làm trung tâm trở thành xu thế chủ đạo,
thì ít nhất cảm giác là coder có thể tự mình xử lý full-stack dựa trên AI sẽ trở thành tiêu chuẩn cơ bản thôi
Bạn có tự chỉnh sửa tiêu đề rồi đăng lên không?
Tôi muốn biết các bạn chọn bài và đăng như thế nào, rồi dịch cả bình luận nữa rất mượt mà. :D
Không điều trị được loạn thị à? :(
Cũng có thể nghĩ như vậy. Theo kinh nghiệm của tôi, so với PyO3 thì
python.h(đây cũng là lý do zig là một lựa chọn thay thế tốt) giúp đi xuống rồi quay lại ở mức OS hoặc vectorize dễ hơn nhiều, nhưng xét ở khía cạnh không phải lo về quản lý bộ nhớ thì từ một quy mô nhất định trở lên, phía Rust có thể đem lại năng suất dài hạn cao hơn.Lý do C dễ là vì nó là nền tảng của các ngôn ngữ lớn hiện đại - Python/TS/Go/PHP/Java - hoặc có cú pháp tương tự, nên không chỉ là cú pháp đơn giản mà còn vì đó là ngôn ngữ mà rồi một lúc nào đó bạn sẽ gặp, hoặc là ngôn ngữ mà trước đây bạn đã từng gặp. Ngược lại, Rust đứng ở phía đối diện, nên dù giá trị của nó cao, để đưa vào trong một đội ngũ vẫn cần khá nhiều nỗ lực. Tôi nghĩ là vì đây là một ngôn ngữ mang tính cách tân hơn là một ngôn ngữ tiến hóa.
À, khi tôi rút gọn tiêu đề AI, tôi đã làm như vậy. Tôi đã sửa rồi.
Có vẻ như bản dịch của tiêu đề có sai sót.
Nội dung có vẻ là về việc chỉnh sửa tình trạng tật viễn thị do lão thị gây ra.
Trong tiếng Hàn, khái niệm này chỉ trạng thái “chỉ nhìn rõ ở gần”, tức là near vision acuity.
Cụm từ "fix near vision" có nghĩa là đã khắc phục vấn đề về tầm nhìn gần (một phần trước đó chưa tốt),
nên đúng hơn là phải nói rằng đã hiệu chỉnh tật viễn thị do lão thị gây ra, hay nói cách khác là đã chỉnh thị lực gần.
Tôi muốn nói rằng lý do chuyển từ C sang Rust thực ra là vì năng suất. Hỗ trợ an toàn bộ nhớ cũng rất tốt, nhưng chỉ riêng
cargothôi cũng đã là lý do đủ để chuyển sang rồi.Khi tạo mô-đun mở rộng cho Python, việc xử lý GIL luôn phức tạp bất kể ngôn ngữ nào. Phần này thì C/C++ cũng vậy; tất nhiên sẽ có ngoại lệ nếu dùng các thư viện hoặc công cụ hỗ trợ viết mô-đun mở rộng, nhưng Rust cũng có một crate tuyệt vời là PyO3.
Ngoài ra, từ góc nhìn của một lập trình viên C thì đương nhiên Zig rất dễ làm việc cùng. Về cơ bản, bản thân Zig cũng là một trình biên dịch C, đến mức có thể chỉ cần import trực tiếp các file header để sử dụng.
Tôi vẫn chưa thấy đủ lý do để chuyển từ C sang Rust cho mã hiệu năng cao. Những ngôn ngữ như Zig, với cú pháp ít nhiều còn đơn giản hơn, có vẻ phù hợp hơn cho phát triển end-to-end; còn các trường hợp khác thì dù sao cấu trúc cũng là sau khi profiling mới chỉ triển khai những phần được gọi từ ngôn ngữ cấp cao (tôi là người dùng Python). Nếu dùng Rust, chi phí phát triển cho việc tương tác với ngôn ngữ khác, như kiểm soát GIL chẳng hạn, lại cao hơn dự kiến khá nhiều. C thì vốn dĩ là thứ mà các ngôn ngữ khác đã trông đợi sẵn rồi.
Tôi đã gặp khá nhiều khó khăn, nên khi thấy PR đã được merge, tôi đã viết một bài blog. Vì “show” là nơi giới thiệu sản phẩm do mình tự phát triển nên có vẻ không phù hợp, nên tôi đăng bài này như một bản tin thông thường, mặc dù chưa chắc đã đúng.
Có vẻ đây là bài viết của người đã tạo ra crate
rayoncủa Rust.Python và TypeScript hiện giờ đúng là vẫn có vẻ là những ngôn ngữ trung tâm...
Rust thì vẫn chưa ở vị thế đến mức đó. Có lẽ là vì mọi người vẫn nghĩ nó khó.
Mong là LLM sẽ hạ thấp rào cản tiếp cận để Rust cũng vươn lên thành một ngôn ngữ trung tâm.