CTO của Azure: "Đã đến lúc ngừng bắt đầu các dự án mới bằng C/C++"

 (twitter.com/markrussinovich)
22 điểm bởi xguru 2022-09-21 | 55 bình luận | Chia sẻ qua WhatsApp
  • Nếu thực sự cần một ngôn ngữ không có GC, hãy dùng Rust
  • Vì mục tiêu bảo mật và độ tin cậy
  • Ngành công nghiệp nên tuyên bố C/C++ là các ngôn ngữ đã lỗi thời

Bài viết liên quan

55 bình luận

 
ahwjdekf 2023-03-01

Những người trước giờ vẫn ca ngợi và dùng Rust cũng nói rằng, cứ đụng đến async là tụt hứng ngay. Thậm chí còn có ý kiến rằng chẳng lẽ với Rust thì đừng nên làm thư viện luôn sao (quá phức tạp, quá kén, quá khó). Những lời than phiền như vậy cũng đang xuất hiện.
 
kernel00 2022-10-03

Cũng có người hạ thấp ông ấy dù còn chẳng biết Mark Russinovich là ai... ông là tác giả của bộ công cụ Sysinternals và cuốn sách Windows Internals... là người đã reverse engineering Windows để làm công cụ rồi sau đó trở thành Microsoft Fellow...
 
ahwjdekf 2022-09-25

Bài viết châm biếm vấn đề của những người cuồng Rust bằng một video ngắn

https://twitter.com/cmuratori/status/1367627549816152064?lang=en
 
ahwjdekf 2022-09-25

Rust thậm chí còn chưa có cả đặc tả chính thức nữa ....
 
functor 2022-09-29

C++ có spec chính thức "tồn tại", nhưng mọi implementation (gcc, clang, ...) đều chưa hoàn chỉnh.
 
lifthrasiir 2022-09-26

Đây là một lập luận khá phổ biến, nhưng từ góc độ của người đã đọc khá nhiều đặc tả và cũng đã triển khai nhiều lần, tôi thật sự không rõ bản thân việc có hay không có đặc tả rốt cuộc có ý nghĩa gì.

"Đặc tả" có nhiều chiến lược khác nhau. Có cách mô tả xoay quanh hành vi bề ngoài, và cũng có cách mô tả hoạt động nội bộ; ngoài ra còn có sự khác biệt giữa việc dùng ngôn ngữ tự nhiên hay dùng cách mà máy có thể đọc được như giả mã hoặc định nghĩa toán học. Những thứ như tài liệu tham chiếu của Python hay Rust là các đặc tả mô tả hành vi bề ngoài bằng ngôn ngữ tự nhiên. Cách tiếp cận thường thấy trong các tiêu chuẩn ISO là đặc tả mô tả hoạt động nội bộ bằng ngôn ngữ tự nhiên, nhưng không có gì đảm bảo hoạt động nội bộ đó thực sự khớp với cách tiếp cận của các triển khai ngoài đời; thay vào đó, nó được định nghĩa theo kiểu nếu một triển khai giả định được xây dựng theo hoạt động nội bộ đó và một triển khai thực tế có hành vi bề ngoài giống nhau, tức là observationally equivalent, thì được xem là phù hợp với tiêu chuẩn. ECMAScript tuy được mô tả bằng ngôn ngữ tự nhiên, nhưng cấu trúc thực tế gần như ở mức viết giả mã bằng ngôn ngữ tự nhiên; cũng có những trường hợp như WebAssembly, nơi hoạt động nội bộ được cung cấp cả dưới dạng đặc tả ngôn ngữ tự nhiên lẫn định nghĩa toán học.

Từ phía người triển khai, các đặc tả bằng ngôn ngữ tự nhiên nói chung cũng na ná nhau cả. Vì đặc tả ngôn ngữ tự nhiên phải được tạo ra tách biệt với triển khai thực tế, nên đương nhiên cũng có trường hợp hai bên bị lệch nhau, và việc mắc lỗi cũng xảy ra khá thường xuyên. Việc mô tả hành vi bề ngoài dễ triển khai hơn hay mô tả hoạt động nội bộ dễ triển khai hơn thì còn tùy tình huống; nhưng xét từ góc độ ngôn ngữ lập trình, không hề có lý do bắt buộc phải chọn hẳn một bên nào. Theo nghĩa đó, Rust đã có đặc tả rồi, và đúng là đặc tả đó cung cấp đủ thông tin để các triển khai thay thế khác có thể xuất hiện.

Nếu bạn muốn chỉ dựa vào việc có trở thành tiêu chuẩn ISO hay chưa để đánh giá độ trưởng thành của một tiêu chuẩn, thì xin báo cho bạn biết là tôi đã phát hiện khoảng 100 lỗi trong tiêu chuẩn ISO/IEC 18181-1 JPEG XL (và vì thế mà bản sửa đổi thứ hai đang bị trì hoãn)...
 
xguru 2022-09-25

Trên Hacker News cũng đã có hơn 800 bình luận.. bên này cũng đang rất nóng...
https://news.ycombinator.com/item?id=32905885
 
kayws426 2022-09-25

Xin cảm ơn vì những chia sẻ.
Mặt khác... tôi từng đọc một bài viết nói rằng khi cố gắng diễn giải phản ứng của một người lúc thứ họ yêu thích bị công kích, ta nên cảnh giác với việc quy tất cả cho tính cách của người đó, và tôi nghĩ đó là một lời đáng suy ngẫm, vì trong tình huống thực tế, thật khó để giữ được một tâm thế như vậy.
 
ahwjdekf 2022-09-24

Có một bình luận trên Twitter khá ấn tượng.

Mọi người cuối cùng vẫn viết mã Rust theo cách "unsafe". - lược bỏ - Rust chưa bao giờ được tạo ra để thay thế những thứ đó.
 
kayws426 2022-09-24

Nhân đây, tôi đính kèm một liên kết để biết Mark Russinovich là ai.
https://en.m.wikipedia.org/wiki/Mark_Russinovich
 
ahwjdekf 2022-09-24

Nói thêm một câu nữa. Những người cứ dùng C++ rồi liên tục gây lỗi và tạo bug, lại bảo “ôi cái này không dùng được, thử chuyển sang Rust đang hot dạo này xem.. nghe nói không cần phải để ý lỗi bộ nhớ nữa mà..”. Những người như vậy vẫn như nhau thôi. Với Rust họ cũng sẽ tạo ra những bug tương tự... Rồi lại sẽ có nhiều người nghĩ tiếp “thế học ngôn ngữ nào tiếp theo để thử đây?”. Những người còn chưa từng làm cho ra hồn cả việc dereference con trỏ trong C++ lại đang tung hô Rust đấy.
 
ahwjdekf 2022-09-24

Những người kiểu đó sẽ phớt lờ hết mấy thứ như quyền sở hữu, reference, borrowing mà Rust lấy làm thế mạnh, vì ngay từ lúc biên dịch chúng đã báo lỗi và gây đau đầu, rồi cứ trộn unsafe vào để dùng bừa như thể đó là C++.
 
functor 2022-09-29

Đằng nào cũng chết thì sao còn sống?
Lập luận này gần như cũng cùng một mức như thế.
 
budlebee 2022-09-25

Cảm giác như đang thấy lập luận rằng đằng nào người hay gây tai nạn cũng không thắt dây an toàn và còn phớt lờ đèn tín hiệu, nên dây an toàn và đèn tín hiệu cũng chẳng có nhiều ý nghĩa. Người giỏi thì làm gì cũng giỏi, người kém thì làm gì cũng kém — có thể đưa ra lập luận như vậy, nhưng nếu đi theo logic đó thì sẽ không thể bàn luận về tính hữu ích của công cụ nữa.
 
cr543l 2022-09-23

Vấn đề là ngôn ngữ này quá khó sử dụng, nhưng đúng là nói cũng có lý.
 
iolothebard 2022-09-23

Khi nào có visual rust thì tôi mới công nhận -. - cười
 
binaryeast 2022-09-21

Có vẻ C/C++ giờ thật sự đang đi vào vị thế như tiếng Latin. Nếu là vì mục đích học thuật thì ai cũng nên học, nhưng để thành thạo thì gần như là bất khả thi, và vì là một hệ thống cũ nên nếu xét theo hiện tại cũng có khá nhiều điểm thiếu hợp lý...
 
dalinaum 2022-09-21

Thật thú vị khi người ta vẫn dùng tốt các ngôn ngữ mà mọi thứ đều là unsafe, nhưng lại tuyệt đối phản đối các ngôn ngữ chỉ cho phép dùng unsafe một cách hạn chế.
 
functor 2022-09-22

Tôi cho rằng đó là một dạng hội chứng Stockholm
 
williameom 2022-09-21

Tinh thần của C

1. Hãy tin tưởng lập trình viên.  
2. Đừng ngăn lập trình viên làm những gì cần phải làm.  
3. Giữ cho ngôn ngữ nhỏ gọn và đơn giản.  
4. Chỉ cung cấp một cách để thực hiện một thao tác.  
5. Hãy làm cho nó nhanh, ngay cả khi không được đảm bảo có tính khả chuyển.
 
functor 2022-09-22

Theo ý kiến cá nhân của tôi thì có vẻ ngay từ điểm số 1 đã sai rồi haha vì con người vốn dĩ sinh ra đã dễ mắc lỗi..
 
heal9179 2022-09-21

Với cả C++, nếu tích cực dùng smart pointer và memory pool thì cũng ổn mà..
Tôi nghĩ thực ra không có nhiều lúc phải trực tiếp xử lý con trỏ như người ta tưởng.

Tôi cho rằng code thread-safe rốt cuộc vẫn là năng lực của chính lập trình viên.
Dù dùng ngôn ngữ nào đi nữa, nếu tay nghề không tốt,
thì cuối cùng vẫn sẽ xuất hiện kiểu code an toàn nhưng hiệu năng kém, hoặc code nguy hiểm.
 
hiyama 2022-09-23

Giao khả năng của lập trình viên cho việc lái ô tô hay điều khiển máy bay thì đáng sợ quá mà....
 
functor 2022-09-22

Mã thread-safe suy cho cùng là năng lực của chính lập trình viên <- Tôi cho rằng cách nghĩ này nguy hiểm, vì memory / thread safety không chỉ dừng ở mức chương trình bị sập hay chậm đi mà còn có thể phát triển thành lỗ hổng bảo mật, nên tôi nghĩ không thể giao việc này cho năng lực của một cá nhân. Đã có nhiều phương pháp khác nhau được nghiên cứu để ngăn chặn điều này từ trước, và khi chúng trưởng thành thì đã ra đời những ngôn ngữ như Rust cùng các công cụ khác; tôi cho rằng hiện nay phần mềm đã có ảnh hưởng quá lớn đến đời sống hằng ngày để có thể không sử dụng chúng rồi quy trách nhiệm cho từng cá nhân.
 
mastotron 2022-09-21

Con người thì đã là con người nên khó tránh khỏi sai sót, và dù là lập trình viên thông minh đến đâu cũng vẫn sẽ mắc lỗi. Bug bộ nhớ rốt cuộc cũng xuất phát từ sai lầm mà ra...

Dạo này tôi cũng nghĩ rằng thay vì trông chờ mọi người tự làm cho thật tốt, có lẽ cách tiếp cận tốt hơn là ngay từ đầu tạo ra một môi trường mà việc mắc lỗi trở nên khó hơn.
 
ahwjdekf 2022-09-21

Nếu ở công ty tôi mà muốn dùng Rust thì phải cấm dùng unsafe. Phải có những quy tắc như vậy thì mới có thể thử tin vào tính an toàn được ngôn ngữ hỗ trợ ở cấp độ ngôn ngữ. Nhưng chuyện này có hợp lý không?
 
mastotron 2022-09-21

Tất nhiên, ở những công ty sử dụng Rust hẳn sẽ có sự đồng thuận rằng nếu không thật sự cần thiết thì không nên dùng unsafe. Hơn thế nữa, tôi khuyên bạn nên thử tự viết bằng Rust... Có lẽ bạn phải trực tiếp dùng thử thì mới biết thực sự sẽ có bao nhiêu trường hợp cần đến unsafe, đúng không?
 
ahwjdekf 2023-02-15

Ngay cả trong các thư viện nổi tiếng như tokio cũng đầy rẫy unsafe.
 
novemberoscar 2022-09-21

Có vẻ có khá nhiều bình luận nhìn theo kiểu hoặc là phải là All, còn không thì chẳng có chút giá trị nào cả.

Có ưu điểm là có thể phân biệt và cô lập rõ ràng giữa unsafe / safe, và nếu một người vốn sẽ gây ra 100 lỗi bộ nhớ thì có thể giảm xuống còn 10 lần; nhưng rồi lại có cách tiếp cận rằng dù sao vẫn có unsafe / dù vậy lỗi bộ nhớ vẫn xảy ra => vì thế nên chẳng tốt hơn C++ ở điểm nào. Tôi không rõ liệu đó có phải là một nhận định thực tế hay không 😅
 
ruinnel 2022-09-22

Xét theo số lượng bình luận thì đúng là vậy nhưng.....
Có vẻ đúng hơn là: có một người theo kiểu ý kiến "all or nothing" đã viết rất nhiều bình luận...
 
csjune 2022-09-21

Tôi cũng đồng ý với bình luận này. Càng nhìn một đối tượng theo kiểu nhị nguyên thì rốt cuộc chỉ tự mình chịu thiệt thôi.

Trong công việc thực tế, người ta thường cân nhắc ưu nhược điểm rồi cuối cùng chọn thứ mang lại lợi ích lớn nhất. Xét theo đặc thù của ngành, nếu không phải là bắt buộc phải dùng C/C++ ngay lúc này thì lợi ích có được khi dùng Rust là khá lớn, nên tôi nghĩ phạm vi Rust được sử dụng đang dần mở rộng.

Những người chuyển sang Rust đâu phải ngốc, chắc là vì sau khi dùng Rust họ thấy về tổng thể có điểm gì đó tốt hơn C++ nên mới tiếp tục dùng thôi haha
 
alstjr7375 2022-09-21

Không có gì... Mọi thứ
 
functor 2022-09-21

Giờ có lẽ không còn nhiều người không đồng ý rằng Rust là Next C++. Ngay cả kernel Linux cũng đã chấp nhận nó như một ngôn ngữ chính thức.
Tuy vậy, việc Rust có thực sự là một ngôn ngữ dễ dùng hay không thì vẫn hơi đáng nghi... Nhờ vào phân tích tĩnh được thực hiện để ngăn chặn trước các vấn đề về an toàn bộ nhớ, thời gian biên dịch khá đau đớn, và vì các semantics như ownership khá khó nên nó đòi hỏi phải học nhiều hơn hẳn so với các ngôn ngữ đa dụng như Python hay Java.
 
dalinaum 2022-09-21

Thời gian biên dịch có lẽ bản thân LLVM mới là vấn đề lớn. Facebook đang nỗ lực cải thiện instruction selection của LLVM, nên tình hình rồi sẽ khá hơn.
 
functor 2022-09-22

Tìm hiểu ra thì đúng là như vậy thật. Tôi cứ nghĩ phần kiểm tra kiểu liên quan đến ownership mới tốn nhiều thời gian, nhưng hóa ra backend LLVM mới là phần lớn..
 
ahwjdekf 2022-09-21

Khi rust mới ra mắt, tôi đã rất quan tâm và có học thử một chút... nhưng thấy mục unsafe là bỏ ngay. Tôi hoàn toàn không thấy có lý do hợp lý nào để phải học rồi dùng cái này. Dù sao thì chương trình chỉ cần hơi phức tạp một chút là cũng phải dùng unsafe thôi. Mà như vậy thì sự an toàn mà rust hay tự hào cũng bay mất rồi. Dùng cái này để làm gì?
 
mastotron 2022-09-21

Trong Rust, có thể xem như unsafe chỉ cần khi lập trình mức thấp, còn khi viết ứng dụng thông thường thì hầu như không có dịp phải dùng đến.

Ngoài ra, ngay cả khi phát sinh vấn đề về bộ nhớ bên trong khối unsafe, ngôn ngữ cũng bảo đảm rằng phần gây ra vấn đề nằm trong chính khối unsafe, nên cũng có ưu điểm là giúp việc gỡ lỗi trở nên dễ hơn.
 
functor 2022-09-21

Nếu thấy có unsafe rồi hỏi "Sao lại dùng cái này?" thì ngay từ đầu chẳng phải là không nên dùng C/C++ sao?
 
ahwjdekf 2022-09-21

C++ vẫn đang tiếp tục tiến hóa, và nếu đã dùng unsafe thì thà cứ dùng luôn C++ còn hơn, nên tôi không cảm thấy thật sự cần thiết phải học rồi sử dụng Rust.
 
functor 2022-09-21

Không phải mọi lập trình Rust đều cần unsafe.
Những thao tác bộ nhớ tinh vi đến mức cần unsafe thường được tách ra ở phía phát triển thư viện, nên ở phía phát triển ứng dụng — nơi có lẽ nhu cầu lớn nhất — tôi nghĩ gần như sẽ không có chuyện phải dùng unsafe.
Đúng là C++ vẫn đang tiếp tục tiến hóa, nhưng gánh nặng di sản để giữ tương thích ngược thì quá đau đớn. Nếu chỉ vì một unsafe mà bạn đã thấy khó chịu, thì có lẽ bạn sẽ còn không hài lòng với mọi tính năng của C++ đâu haha
 
alstjr7375 2022-09-21

Vì thế nên unsafe không được khuyến nghị.
Dùng safe thì vẫn an toàn hơn C/C++ vốn về cơ bản mọi thứ đều như unsafe.
https://people.mpi-sws.org/~dreyer/papers/rustbelt/paper.pdf
 
ahwjdekf 2022-09-21

Nếu không có cơ chế mơ hồ là unsafe, thì Rust có lẽ có thể trở thành một lựa chọn thay thế thực sự cho C++.
 
jjpark78 2022-09-21

Tôi chỉ ước FFI thân thiện hơn một chút.. Tôi nhớ đã từng cố trao đổi các cấu trúc phức hợp với thư viện bên ngoài thông qua FFI, và đó là một trải nghiệm vô cùng đau khổ.
 
alstjr7375 2022-09-21

Ngay cả rust to rust còn không dễ nữa..
https://github.com/rodrimati1992/abi_stable_crates
 
jjpark78 2022-09-21

Xét trong bối cảnh MS đang tích cực hỗ trợ Rust, đây có vẻ là một phát biểu rất tự nhiên.
 
colus001 2022-09-21

Đến cả Torvalds cứng đầu như vậy cũng đã chấp nhận Rust, nên tôi không thấy cần phải cứ tiếp tục dùng một ngôn ngữ mà ngày càng ít người học.
 
ahwjdekf 2022-09-21

Lỗi liên quan đến bộ nhớ không bao giờ tự nhiên biến mất chỉ vì dùng Rust. Những người tạo ra lỗi thì dù đưa cho họ ngôn ngữ nào cũng sẽ sản xuất ra lỗi hàng loạt. C++ vẫn đang được dùng hiệu quả và ổn thỏa mà chẳng có vấn đề gì, chứ bỏ là bỏ cái gì. Đúng là đã buột miệng đưa ra một phát ngôn gây bão như thể sắp nổ ra chiến tranh vậy.
 
functor 2022-09-21

Nói rằng C/C++ đang được sử dụng hiệu quả và ổn thỏa, không có vấn đề gì thì cũng khó, vì trong lịch sử đã có vô số lỗi liên quan đến bộ nhớ bùng phát từ C/C++, và có lẽ ngay lúc này vẫn đang phát sinh ở đâu đó. (Dù nhờ vậy mà nhiều nhà nghiên cứu PL/SE cũng có cái để sống)
Theo nội dung công bố của Microsoft, 70% lỗi bảo mật là lỗi liên quan đến bộ nhớ (https://zdnet.com/article/…)
Nội dung khảo sát từ dự án Chromium cũng tương tự (https://www.chromium.org/Home/chromium-security/memory-safety/): gần 70% cũng là lỗi liên quan đến bộ nhớ.
 
jjpark78 2022-09-21

Tôi nhớ là đã từng đọc đâu đó một bài viết trước đây nói rằng phần lớn lỗi của kernel Windows là các lỗi liên quan đến bộ nhớ, và ở những phần đang được phát triển bằng Rust thì các lỗi đó đã giảm đi một cách đáng kể..

Vì ngay từ khi ra đời, ngôn ngữ này đã được thiết kế để tích cực khuyến khích readonly, nên có lẽ khó mà phủ nhận rằng đây là một thiết kế ngôn ngữ an toàn hơn C++. Tuy nhiên, vì thế mà xuất hiện khái niệm quyền sở hữu nghe rất lạ lẫm, khiến việc lập trình trở nên khó hơn.

Ngoài ra còn có lợi thế về hiệu năng: về mặt thống kê, mã Rust viết khá sơ sài vẫn chạy nhanh hơn mã C++ được thiết kế rất tốt.
 
lordang 2022-09-21

Có vẻ ông ấy đã nói một câu dễ gây tranh cãi rồi đấy. haha
Cá nhân tôi thấy C++ vì đã quá lâu đời nên bị ràng buộc bởi khả năng tương thích ngược, khiến việc phát triển theo hướng hiện đại diễn ra chậm chạp.
Thêm nữa, do vừa phải giữ tương thích ngược triệt để vừa phải đưa các yếu tố hiện đại vào, nên có quá nhiều cách để làm cùng một việc, và tôi nghĩ điều đó lại trở thành rào cản gia nhập lớn hơn với người mới.
Tôi cũng nghĩ giờ Rust tốt hơn C++. Thời phải đỏ mắt đi tìm các lỗi liên quan đến quản lý bộ nhớ giờ nên chấm dứt thôi.
 
jjpark78 2022-09-21

Đúng vậy.. nếu là một dự án phát triển bắt đầu từ con số 0 thì thực sự không có lý do gì phải chọn C++ cả..
 
kandk 2022-09-21

Chuẩn luôn
 
loblue 2022-09-22

Dù muốn dùng Rust thì cũng chỉ dùng bổ trợ, còn trong công việc thì vẫn chưa có dịp dùng đến. Vì vậy cũng khó mà quen hẳn, mà chỉ cần bỏ tay một thời gian là lại quên mất... Rõ ràng là thích nên cũng muốn dùng lắm mà... hehe
 
koreacglee 2022-09-23

Toàn mấy người chưa từng tự tay viết lấy một memory pool để tối ưu hiệu quả sử dụng heap mà cứ ra rả Rust suốt, đúng là buồn cười ha. Azure CTO thì dĩ nhiên chẳng phải loại ý kiến đủ đại diện cho tiêu chuẩn của cả ngành, mà kể cả bó hẹp trong Microsoft cũng tuyệt đối không phải là ý kiến đại diện cho lập trường của Microsoft; cùng lắm chỉ là tự dưng nổi hứng rồi đem suy nghĩ chủ quan của mình ra nói mà thôi... Mấy người còn chẳng làm C++ cho ra hồn thì liệu sang Rust có làm cho ra hồn được không? Đúng là đầy rẫy những kẻ chỉ giỏi chém gió.
 
functor 2022-09-26

Ngay từ cách nói chuyện, bạn đã bộc lộ sự thô lỗ một cách không che giấu. Cố lên nhé.