a0.dev - Nền tảng tạo ứng dụng React Native dựa trên AI
Ở đây cũng có nói là sắp bổ sung triển khai chỉ với một cú nhấp, vậy thì giờ các nền tảng tạo ứng dụng dựa trên AI có lẽ phải mặc định hỗ trợ cả khâu triển khai nữa.
Nói rất đơn giản
nếu đến mức chỉ cần đưa bản yêu cầu là việc phát triển đã hoàn tất, thì có thể xem là đã bị thay thế
nhưng không biết ngày đó đến bao giờ đây
Trong kernel Linux, những phần Rust dùng unsafe phần lớn là các đoạn bọc để tương tác với C.
Ngoài ra cũng có một số rất ít phần điều khiển phần cứng cần thao tác trực tiếp với bộ nhớ.
Phần được áp dụng Rust là phát triển driver. Không cần đụng tới, và cũng không thể đụng tới, bản thân kernel như quản lý bộ nhớ hay block layer.
Lượng mã driver còn nhiều hơn rất nhiều so với mã của chính kernel. Và phần lớn những điểm phát sinh vấn đề cũng là ở mã driver.
Tôi nghĩ phần phát triển driver nên được viết bằng một ngôn ngữ có độ an toàn bộ nhớ và bảo mật tốt hơn C.
Dù đó là Rust, Zig hay thứ gì khác thì tôi cũng không chắc.
Tôi cũng đồng ý rằng Rust quá phức tạp để phát triển ứng dụng thông thường, và cũng khó để các lập trình viên C học nhanh.
Dù vậy, tôi vẫn hy vọng ít nhất riêng mảng phát triển driver sẽ được chuyển sang một ngôn ngữ hiện đại hơn, bất kể đó là ngôn ngữ nào.
Ở công ty cũ, tôi từng mất khoảng 7 năm để phát triển và ổn định hóa một driver chỉ vài nghìn dòng, và dù không thể đơn giản hóa hoàn toàn, có lẽ khoảng 3 năm trong số đó chỉ là để debug.
Phần lớn là lỗi liên quan đến bộ nhớ. Những lỗi logic như deadlock thì chỉ chiếm số ít.
Đó là một lựa chọn không thể tránh khỏi đối với Hector Martin.
Khi tầng quản lý trung gian của Linux đều kín chỗ bởi các chuyên gia C, thì làm sao họ lại chịu tiếp nhận những ý kiến của số ít lập trình viên Rust chứ.
Torvalds không nói một lời nào về Rust trong cuộc tranh luận đó.
Khi có tranh chấp về ý kiến kỹ thuật, thì phải thảo luận dựa trên cơ sở kỹ thuật,
chứ đừng tìm cách kết thúc tranh chấp bằng việc tạo dư luận trên SNS.
Có vẻ không ổn khi dùng các dự án lớn làm nơi thử nghiệm cho ngôn ngữ của mình.
Nếu không hợp thì cũng nên quay lại thời trước, khi cứ tách nhánh nếu cần.
Với một kernel xử lý toàn bộ thiết bị, tôi chỉ thấy rằng dù có dùng Rust thì một khi bắt đầu dùng unsafe, cuối cùng cũng thành ra loại mã khó đọc và dễ phát sinh vấn đề.
Đây cũng đâu phải kiểu dự án không có bản phát hành chính thức rõ ràng như 0.91, 0.92, 0.99, 0.991 gì đó, nên tôi không hiểu vì sao lại đi port cả những phần vốn đang chạy tốt.
Cũng chẳng phải là nhân lúc sửa một lỗi lớn thì tiện thể chuyển sang cách an toàn hơn.
Trong lúc tạo mới website cá nhân và đăng ký lên công cụ tìm kiếm, tôi biết đến giao thức IndexNow, thấy trên GeekNews dường như chưa có nội dung liên quan nên đã đăng bài này.
Thật tiếc là phần thân bài không có trích dẫn nguyên văn. Vì tò mò nên tôi đã tự tìm bản gốc và đọc thử; dù tôi cũng chưa nắm hết được một cách chính xác, nhưng có vẻ là có khá nhiều câu chuyện phía sau, nên khó mà chỉ kể lại đơn giản như nguyên văn được.
Tôi thấy đây là một góc nhìn khá thú vị, và là một bài viết có nhiều điểm khiến tôi đồng cảm. Bản thân tôi cũng nghĩ rằng trong một khoảng thời gian nhất định, những khía cạnh được nhắc đến trong bài viết đó sẽ phát huy tác động khá mạnh. Tuy vậy, tôi cũng cảm thấy rằng cái gọi là một khoảng thời gian nhất định đó sẽ không kéo dài quá lâu.
Cuối cùng thì có phải cũng sẽ cần biết cả Docker lẫn WASM không nhỉ haha. Dù vậy, Docker cũng đã trở nên dễ tiếp cận hơn khi công nghệ dần chín muồi, nên mình nghĩ WASM có lẽ cũng sẽ đi theo hướng tương tự và ngày càng dễ tiếp cận hơn.
a0.dev - Nền tảng tạo ứng dụng React Native dựa trên AI
Ở đây cũng có nói là sắp bổ sung triển khai chỉ với một cú nhấp, vậy thì giờ các nền tảng tạo ứng dụng dựa trên AI có lẽ phải mặc định hỗ trợ cả khâu triển khai nữa.
Nói rất đơn giản
nếu đến mức chỉ cần đưa bản yêu cầu là việc phát triển đã hoàn tất, thì có thể xem là đã bị thay thế
nhưng không biết ngày đó đến bao giờ đây
Trong kernel Linux, những phần Rust dùng
unsafephần lớn là các đoạn bọc để tương tác với C.Ngoài ra cũng có một số rất ít phần điều khiển phần cứng cần thao tác trực tiếp với bộ nhớ.
Phần được áp dụng Rust là phát triển driver. Không cần đụng tới, và cũng không thể đụng tới, bản thân kernel như quản lý bộ nhớ hay block layer.
Lượng mã driver còn nhiều hơn rất nhiều so với mã của chính kernel. Và phần lớn những điểm phát sinh vấn đề cũng là ở mã driver.
Tôi nghĩ phần phát triển driver nên được viết bằng một ngôn ngữ có độ an toàn bộ nhớ và bảo mật tốt hơn C.
Dù đó là Rust, Zig hay thứ gì khác thì tôi cũng không chắc.
Tôi cũng đồng ý rằng Rust quá phức tạp để phát triển ứng dụng thông thường, và cũng khó để các lập trình viên C học nhanh.
Dù vậy, tôi vẫn hy vọng ít nhất riêng mảng phát triển driver sẽ được chuyển sang một ngôn ngữ hiện đại hơn, bất kể đó là ngôn ngữ nào.
Ở công ty cũ, tôi từng mất khoảng 7 năm để phát triển và ổn định hóa một driver chỉ vài nghìn dòng, và dù không thể đơn giản hóa hoàn toàn, có lẽ khoảng 3 năm trong số đó chỉ là để debug.
Phần lớn là lỗi liên quan đến bộ nhớ. Những lỗi logic như deadlock thì chỉ chiếm số ít.
> https://madewithwebassembly.com/
Ở đây có một bộ sưu tập các trường hợp triển khai.
(Cá nhân tôi thấy) chủ yếu những lĩnh vực như CAD hay xử lý ảnh trông có vẻ thuyết phục nhất.
Điều này lại khiến tôi nhớ đến đội phát triển giải pháp trước đây từng trăn trở về việc triển khai hình ảnh y tế độ phân giải cao trên web.
Tôi đang dùng nó khá hữu ích,
Đó là một lựa chọn không thể tránh khỏi đối với Hector Martin.
Khi tầng quản lý trung gian của Linux đều kín chỗ bởi các chuyên gia C, thì làm sao họ lại chịu tiếp nhận những ý kiến của số ít lập trình viên Rust chứ.
Đó là Redox đấy. Chắc là vì vẫn còn những phần chưa được hỗ trợ nên mới chuyển sang Linux thôi...
https://vt.social/@lina/113064510447670892
Torvalds không nói một lời nào về Rust trong cuộc tranh luận đó.
Khi có tranh chấp về ý kiến kỹ thuật, thì phải thảo luận dựa trên cơ sở kỹ thuật,
chứ đừng tìm cách kết thúc tranh chấp bằng việc tạo dư luận trên SNS.
Có vẻ không ổn khi dùng các dự án lớn làm nơi thử nghiệm cho ngôn ngữ của mình.
Nếu không hợp thì cũng nên quay lại thời trước, khi cứ tách nhánh nếu cần.
Với một kernel xử lý toàn bộ thiết bị, tôi chỉ thấy rằng dù có dùng Rust thì một khi bắt đầu dùng
unsafe, cuối cùng cũng thành ra loại mã khó đọc và dễ phát sinh vấn đề.Đây cũng đâu phải kiểu dự án không có bản phát hành chính thức rõ ràng như 0.91, 0.92, 0.99, 0.991 gì đó, nên tôi không hiểu vì sao lại đi port cả những phần vốn đang chạy tốt.
Cũng chẳng phải là nhân lúc sửa một lỗi lớn thì tiện thể chuyển sang cách an toàn hơn.
Trong lúc tạo mới website cá nhân và đăng ký lên công cụ tìm kiếm, tôi biết đến giao thức IndexNow, thấy trên GeekNews dường như chưa có nội dung liên quan nên đã đăng bài này.
Thật tiếc là phần thân bài không có trích dẫn nguyên văn. Vì tò mò nên tôi đã tự tìm bản gốc và đọc thử; dù tôi cũng chưa nắm hết được một cách chính xác, nhưng có vẻ là có khá nhiều câu chuyện phía sau, nên khó mà chỉ kể lại đơn giản như nguyên văn được.
Phân biệt và giải thích giữa Vertical AI và Horizontal AI khá thú vị.
Phường ống log, bảo vệ.
WASM giống như một chiếc máy in 3D mới vậy. Người ta nói rằng "một thế giới mới đang đến", nhưng thực tế thì chẳng có mấy người dùng...
> Học WASM qua ví dụ
https://vi.news.hada.io/topic?id=11891
Tôi thử làm theo.
Có vẻ như ngay cả đến năm 2030, k8s vẫn sẽ tiếp tục vững vàng.
Tôi thấy đây là một góc nhìn khá thú vị, và là một bài viết có nhiều điểm khiến tôi đồng cảm. Bản thân tôi cũng nghĩ rằng trong một khoảng thời gian nhất định, những khía cạnh được nhắc đến trong bài viết đó sẽ phát huy tác động khá mạnh. Tuy vậy, tôi cũng cảm thấy rằng cái gọi là một khoảng thời gian nhất định đó sẽ không kéo dài quá lâu.
Cuối cùng thì có phải cũng sẽ cần biết cả Docker lẫn WASM không nhỉ haha. Dù vậy, Docker cũng đã trở nên dễ tiếp cận hơn khi công nghệ dần chín muồi, nên mình nghĩ WASM có lẽ cũng sẽ đi theo hướng tương tự và ngày càng dễ tiếp cận hơn.
Đó là điều hiển nhiên, nhưng lại khó thực hiện..
Tiêu đề của bài viết đã được đổi thành tên gốc.