CTO ของ Azure: "ถึงเวลาแล้วที่จะหยุดเริ่มโปรเจกต์ใหม่ด้วย C/C++"

 (twitter.com/markrussinovich)
22 คะแนน โดย xguru 2022-09-21 | 55 ความคิดเห็น | แชร์ทาง WhatsApp
  • หากเป็นกรณีที่จำเป็นต้องใช้ภาษาแบบไม่มี GC จริง ๆ ให้ใช้ Rust
  • เพื่อความปลอดภัยและความน่าเชื่อถือ
  • อุตสาหกรรมควรประกาศให้ C/C++ เป็นภาษาที่เลิกใช้งานแล้ว

บทความที่เกี่ยวข้อง

55 ความคิดเห็น

 
ahwjdekf 2023-03-01

แม้แต่คนที่คอยยกย่องและใช้งาน Rust มาตลอด พอเจอ async เข้า ก็ถึงกับสติหลุดกันบ้าง แล้วยังมีเสียงบ่นออกมาด้วยว่า งั้นนี่คือไม่ควรสร้างไลบรารีด้วย Rust เลยหรือเปล่า (มันซับซ้อน จุกจิก และยากเกินไป)
 
kernel00 2022-10-03

ยังมีคนที่พูดดูแคลนทั้งที่ไม่รู้ด้วยซ้ำว่า Mark Russinovich คือใคร... เขาเป็นผู้เขียนชุดเครื่องมือ sysinternals tool suite และหนังสือ Windows Internals... เป็นคนที่ทำเครื่องมือจากการรีเวิร์สเอนจิเนียริง Windows จนได้เป็น Microsoft Fellow...
 
ahwjdekf 2022-09-25

บทความที่เสียดสีปัญหาของบรรดาแฟนพันธุ์แท้ Rust ด้วยวิดีโอสั้นๆ

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

Rust ยังไม่มีแม้แต่สเปกอย่างเป็นทางการเลยด้วยซ้ำ ....
 
functor 2022-09-29

C++ มีสเปกอย่างเป็นทางการ "มีอยู่จริง" ก็จริง แต่ทุก implementation (gcc, clang, ...) ก็ยังไม่สมบูรณ์กันทั้งนั้น
 
lifthrasiir 2022-09-26

นี่เป็นตรรกะที่พบได้บ่อยครับ แต่ในฐานะคนที่เคยอ่านสเปกมามากและเคยลงมือทำอิมพลีเมนเทชันหลายครั้ง ผมไม่ค่อยเข้าใจนักว่าการมีหรือไม่มีสเปกนั้นมีความหมายในตัวเองอย่างไร

"สเปก" มีได้หลายแนวทาง มีทั้งวิธีอธิบายโดยยึดพฤติกรรมที่มองเห็นภายนอกเป็นหลัก และวิธีอธิบายการทำงานภายใน อีกทั้งยังแบ่งได้ว่าใช้ภาษาธรรมชาติ หรือใช้วิธีที่เครื่องอ่านได้ เช่น pseudocode หรือคำนิยามทางคณิตศาสตร์ เอกสารอ้างอิงของภาษาอย่าง Python หรือ Rust ก็เป็นสเปกที่อธิบายพฤติกรรมภายนอกด้วยภาษาธรรมชาติ ส่วนแนวทางที่มักพบในมาตรฐาน ISO เป็นต้น คือสเปกที่อธิบายการทำงานภายในด้วยภาษาธรรมชาติ แต่ก็ไม่ได้รับประกันว่าการทำงานภายในนั้นจะสอดคล้องกับแนวทางของอิมพลีเมนเทชันจริงเสมอไป แทนที่จะเป็นเช่นนั้น มันจะนิยามในทำนองว่า หากอิมพลีเมนเทชันสมมุติที่สร้างจากการทำงานภายในนั้น และอิมพลีเมนเทชันจริง แสดงพฤติกรรมภายนอกเหมือนกันหรือ observationally equivalent ต่อกัน ก็ถือว่าสอดคล้องกับมาตรฐาน ECMAScript แม้จะเขียนอธิบายด้วยภาษาธรรมชาติ แต่โครงสร้างจริงก็แทบจะเป็น pseudocode ที่เขียนด้วยภาษาธรรมชาติ และก็มีกรณีอย่าง WebAssembly ที่ให้ทั้งสเปกภาษาธรรมชาติของการทำงานภายในและคำนิยามทางคณิตศาสตร์ควบคู่กันไป

ในมุมของการอิมพลีเมนต์ สเปกภาษาธรรมชาติก็ไม่ได้ต่างกันมากนัก เพราะสเปกภาษาธรรมชาติต้องถูกสร้างขึ้นแยกจากอิมพลีเมนเทชันจริง จึงเป็นธรรมดาที่บางครั้งทั้งสองอย่างจะค่อย ๆ ห่างกันออกไป และความผิดพลาดก็เกิดขึ้นได้บ่อยด้วย ว่าพฤติกรรมภายนอกจะอิมพลีเมนต์ง่ายกว่า หรือการทำงานภายในจะอิมพลีเมนต์ง่ายกว่า ก็ขึ้นอยู่กับสถานการณ์ และในมุมของภาษาโปรแกรมก็ไม่ได้มีเหตุผลจำเป็นชัดเจนว่าต้องเลือกอย่างใดอย่างหนึ่ง ในแง่นั้น Rust ก็มีสเปกอยู่แล้ว และสเปกนั้นก็ให้ข้อมูลเพียงพอจริงจนสามารถมีอิมพลีเมนเทชันทดแทนอื่น ๆ เกิดขึ้นได้

ถ้าคุณอยากตัดสินความสมบูรณ์ของมาตรฐานจากแค่ว่ามันได้เป็นมาตรฐาน ISO หรือไม่ ผมก็ขอแจ้งข่าวว่า ผมพบบั๊กประมาณ 100 จุดในมาตรฐาน ISO/IEC 18181-1 JPEG XL (และเพราะเรื่องนั้นเอง 2nd amendment จึงกำลังล่าช้าอยู่)...
 
xguru 2022-09-25

บน Hacker News ก็มีคอมเมนต์เกิน 800 รายการแล้วเหมือนกัน.. ที่นี่ก็ดุเดือดเช่นกัน... https://news.ycombinator.com/item?id=32905885
 
kayws426 2022-09-25

ขอบคุณสำหรับความเหน็ดเหนื่อยครับ
อีกด้านหนึ่ง.. ผมเคยเห็นบทความที่บอกว่า เวลาพยายามตีความปฏิกิริยาของใครบางคนตอนที่สิ่งที่เขาชอบถูกโจมตี เราควรระวังอย่าโยนไปว่าเป็นเพราะนิสัยของคนนั้น ซึ่งผมคิดว่าเป็นคำพูดที่ดี เพราะเหตุผลก็คงเป็นเพราะในสถานการณ์จริง การมีใจแบบนั้นเป็นเรื่องยาก
 
ahwjdekf 2022-09-24

มีคอมเมนต์ในทวีตอันหนึ่งที่น่าประทับใจนะ

People end up writing Rust code the "unsafe way". - ละไว้ - Rust was never meant to replace those.
 
kayws426 2022-09-24

ถึงตรงนี้ ขอลองแปะลิงก์สำหรับคนที่อยากรู้ว่า Mark Russinovich คือใคร
https://en.m.wikipedia.org/wiki/Mark_Russinovich
 
ahwjdekf 2022-09-24

ขอพูดอีกอย่างนะ คนที่ใช้ C++ แล้วทำเออเรอร์อยู่เรื่อย ๆ สร้างบั๊กอยู่ตลอด พอถึงจุดหนึ่งก็จะบอกว่า เฮ้ อันนี้ใช้ไม่ไหวแล้ว ไปลอง Rust ที่กำลังดังช่วงนี้ดีกว่า.. เห็นว่าถ้าใช้แล้วไม่ต้องกังวลเรื่อง memory error นี่นา.. คนแบบนี้ก็เหมือนเดิมแหละ ถึงใช้ Rust ก็จะสร้างบั๊กคล้าย ๆ กันออกมาอีก ... แล้วก็จะไปคิดกันต่อว่า งั้นจะไปเรียนภาษาอะไรตัวถัดไปมาลองดี คนแบบนี้มีเยอะครับ พวกที่ยังย้อน dereference pointer ใน C++ ยังไม่เคยทำให้ถูกต้องด้วยซ้ำ แต่กลับอวย Rust กันใหญ่
 
ahwjdekf 2022-09-24

คนประเภทนั้นน่ะ เวลาคอมไพล์แล้วเจอว่าเรื่อง ownership, reference, borrowing ที่ Rust ชูเป็นจุดแข็งมันขึ้น error และชวนปวดหัว ก็จะเมินมันทั้งหมดแล้วผสม unsafe เข้าไป ใช้แบบมั่ว ๆ ให้เหมือนเป็น C++ อยู่ดี
 
functor 2022-09-29

ยังไงก็ต้องตายอยู่แล้ว แล้วจะมีชีวิตไปทำไม?
ตรรกะแทบจะอยู่ในระดับเดียวกับประโยคนี้เลย
 
budlebee 2022-09-25

ให้ความรู้สึกเหมือนกำลังเห็นคำอ้างว่า ต่อให้คนที่จะก่อเรื่องก็ไม่คาดเข็มขัดนิรภัยและยังไม่สนใจสัญญาณไฟจราจรอยู่ดี ดังนั้นเข็มขัดนิรภัยกับสัญญาณไฟจราจรก็แทบไม่มีความหมายอะไร
จะอ้างได้ก็จริงว่าคนเก่งจะทำอะไรก็เก่ง และคนที่ไม่เก่งจะทำอะไรก็ไม่เก่ง แต่ถ้าใช้ตรรกะแบบนั้น การถกเถียงเรื่องประโยชน์ของเครื่องมือก็ย่อมตั้งต้นไม่ได้เลย
 
cr543l 2022-09-23

ปัญหาก็คือภาษานี้ใช้งานยากเกินไป แต่ก็เป็นคำพูดที่ถูกต้องนะ
 
iolothebard 2022-09-23

ถ้ามี visual rust ออกมาเมื่อไรค่อยยอมรับ อืม... ฮ่าๆ
 
binaryeast 2022-09-21

ดูเหมือนว่า C/C++ กำลังมุ่งหน้าไปอยู่ในสถานะเดียวกับภาษาละตินจริง ๆ นะครับ ถ้าเพื่อการศึกษาแล้วใคร ๆ ก็ควรเรียน แต่จะให้เชี่ยวชาญถึงขั้นแตกฉานนั้นแทบเป็นไปไม่ได้ และเพราะเป็นระบบเก่า เมื่อมองจากปัจจุบันก็มีหลายส่วนที่ไม่สมเหตุสมผลอยู่มาก...
 
dalinaum 2022-09-21

น่าสนใจดีนะที่ใช้ภาษาที่ทุกอย่างเป็น unsafe กันได้ แต่กลับบอกว่าใช้ภาษาที่สามารถใช้ unsafe ได้อย่างจำกัดนั้นไม่ได้เด็ดขาด
 
functor 2022-09-22

ผมมองว่านี่เป็นอาการชนิดหนึ่งของ Stockholm syndrome
 
williameom 2022-09-21

จิตวิญญาณของ C

1. จงเชื่อใจโปรแกรมเมอร์  
2. อย่าขัดขวางไม่ให้โปรแกรมเมอร์ทำสิ่งที่จำเป็นต้องทำ  
3. ทำให้ภาษามีขนาดเล็กและเรียบง่าย  
4. จัดให้มีเพียงวิธีเดียวในการทำโอเปอเรชันหนึ่ง ๆ  
5. ทำให้มันเร็ว แม้จะไม่ได้รับประกันว่าสามารถพกพาได้
 
functor 2022-09-22

ส่วนตัวผมคิดว่าข้อ 1 ก็ดูผิดตั้งแต่แรกแล้วนะ ฮ่าๆ เพราะมนุษย์นั้นโดยธรรมชาติแล้วก็ error-prone อยู่แล้ว..
 
heal9179 2022-09-21

แม้แต่ C++ เอง ถ้าใช้ smart pointer กับ memory pool อย่างจริงจังก็พอแล้ว...
ผมมองว่าในความเป็นจริงแล้ว มีเรื่องที่ต้องไปจัดการ pointer โดยตรงน้อยกว่าที่คิดมาก

ผมคิดว่าโค้ดที่เป็น thread-safe สุดท้ายแล้วก็ขึ้นอยู่กับความสามารถของโปรแกรมเมอร์เอง
ไม่ว่าจะใช้ภาษาไหน ถ้าฝีมือยังไม่ดีพอ
ก็มักจะลงเอยเป็นโค้ดที่ปลอดภัยแต่ประสิทธิภาพต่ำ หรือไม่ก็โค้ดที่อันตรายอยู่ดี
 
hiyama 2022-09-23

มันน่ากลัวเกินไปที่จะฝากเรื่องแบบการขับรถหรือการบังคับเครื่องบินไว้กับความสามารถของโปรแกรมเมอร์....
 
functor 2022-09-22

โค้ดที่ thread-safe สุดท้ายแล้วก็ขึ้นอยู่กับความสามารถของโปรแกรมเมอร์เอง <- ผมมองว่าความคิดนี้อันตราย เพราะ memory / thread safety ไม่ได้อยู่แค่ระดับที่โปรแกรมล่มหรือช้าลงเท่านั้น แต่ยังลุกลามไปเป็นช่องโหว่ด้านความปลอดภัยได้ด้วย ดังนั้นผมจึงคิดว่าไม่ควรฝากเรื่องนี้ไว้กับความสามารถของคนคนเดียว
มีการวิจัยวิธีการต่าง ๆ มากมายเพื่อป้องกันสิ่งนี้ล่วงหน้า และเมื่อสิ่งเหล่านั้นพัฒนาจนสุกงอมก็ได้กลายมาเป็นภาษาอย่าง rust หรือเครื่องมืออื่น ๆ ดังนั้นการไม่ใช้สิ่งเหล่านี้แล้วโยนความผิดให้ตัวบุคคลจึงไม่เหมาะสม เพราะผมมองว่าซอฟต์แวร์ได้กลายเป็นสิ่งที่มีอิทธิพลต่อชีวิตประจำวันมากเกินไปแล้ว
 
mastotron 2022-09-21

มนุษย์ยังไงก็เป็นมนุษย์ จึงหลีกเลี่ยงความผิดพลาดไม่ได้ และไม่ว่าโปรแกรมเมอร์จะเก่งแค่ไหนก็ย่อมพลาดกันได้อยู่ดีครับ บั๊กด้านหน่วยความจำเองก็สุดท้ายแล้วเกิดจากความผิดพลาดเหมือนกัน...

ช่วงนี้เลยก็อดคิดไม่ได้ว่า แทนที่จะหวังให้คนทำได้ดีด้วยตัวเอง การสร้างสภาพแวดล้อมที่ทำให้พลาดได้ยากตั้งแต่แรก อาจเป็นแนวทางที่ดีกว่าก็ได้
 
ahwjdekf 2022-09-21

ถ้าจะให้ใช้ Rust ในบริษัทของเรา ก็ต้องห้ามใช้ unsafe แบบเด็ดขาด ต้องมีกฎแบบนี้ถึงจะพอเชื่อถือความปลอดภัยที่ตัวภาษาสนับสนุนมาให้ได้บ้าง แต่แบบนี้มันจะสมเหตุสมผลจริงหรือ?
 
mastotron 2022-09-21

แน่นอนว่าในบริษัทที่ใช้ Rust ก็คงมีข้อตกลงร่วมกันว่าไม่ควรใช้ unsafe หากไม่จำเป็นจริง ๆ แต่ผม/ฉันอยากแนะนำให้ลองเขียนด้วย Rust ด้วยตัวเองมากกว่าครับ/ค่ะ... ว่าจริง ๆ แล้วจะมีเรื่องที่ต้องใช้ unsafe มากแค่ไหน ก็คงต้องลองใช้เองถึงจะรู้ไม่ใช่หรือ?
 
ahwjdekf 2023-02-15

ไลบรารีที่พอรู้จักกันอย่าง tokio ก็ถม unsafe กันเต็มไปหมดเหมือนกัน
 
novemberoscar 2022-09-21

ดูเหมือนจะมีคอมเมนต์ค่อนข้างมากที่มองแบบ all or nothing ว่าถ้าไม่ All ก็ไม่มีคุณค่าอะไรเลย

มันมีข้อดีตรงที่สามารถแยกและกักขอบเขต unsafe / safe ได้อย่างชัดเจน และทำให้คนที่เดิมทีอาจสร้างบั๊กด้านหน่วยความจำ 100 ครั้ง เหลือ 10 ครั้งได้ แต่สุดท้ายก็ยังมี unsafe อยู่ / และบั๊กด้านหน่วยความจำก็ยังเกิดขึ้นได้ => ดังนั้นจึงมองว่าไม่ได้ดีกว่า C++ เลย ผมก็ไม่แน่ใจว่าวิธีคิดแบบนี้เป็นการตัดสินที่สมจริงหรือเปล่า 😅
 
ruinnel 2022-09-22

ถ้าวัดจากจำนวนคอมเมนต์ก็เหมือนจะใช่ แต่ว่า.....
ดูเหมือนว่าสถานการณ์ที่ถูกต้องคือ... มีคอมเมนต์จำนวนมากที่เขียนโดยคนคนหนึ่งซึ่งมีความเห็นแบบ All or nothing
 
csjune 2022-09-21

ผมก็เห็นด้วยกับคอมเมนต์นี้เหมือนกัน ยิ่งมองอะไรแบบแบ่งขั้วสุดโต่ง ก็ยิ่งมีแต่ตัวเองที่เสียประโยชน์

ในการทำงานจริงก็มักจะชั่งน้ำหนักข้อดีข้อเสีย แล้วสุดท้ายก็เลือกสิ่งที่ให้ผลบวกมากที่สุดอยู่แล้ว ถ้าไม่ใช่กรณีที่ด้วยลักษณะของอุตสาหกรรมจำเป็นต้องใช้ C/C++ ในตอนนี้จริง ๆ ผมคิดว่าประโยชน์ที่ได้จากการใช้ Rust นั้นมีมาก เลยทำให้ขอบเขตการใช้งานของ Rust ค่อย ๆ กว้างขึ้นเรื่อย ๆ

คนที่ย้ายไปใช้ Rust ก็ไม่ใช่ว่าจะโง่อะไร พอลองใช้ Rust แล้วก็คงเห็นว่ามันมีอะไรที่โดยรวมดีกว่า C++ เลยยังใช้กันต่อไปนั่นแหละ 555
 
alstjr7375 2022-09-21

ไม่มีอะไร... ทุกอย่าง
 
functor 2022-09-21

ตอนนี้คงมีไม่กี่คนแล้วที่จะไม่เห็นด้วยว่า Rust คือ Next C++ ถึงขั้นที่ลินุกซ์เคอร์เนลรับไปเป็นภาษาทางการแล้ว
แต่ก็ยังน่าสงสัยอยู่ว่า Rust เป็นภาษาที่ใช้งานสะดวกจริงหรือไม่... เพราะการวิเคราะห์แบบสแตติกที่ทำเพื่อป้องกันปัญหา memory safety ล่วงหน้าทำให้เวลา compile ค่อนข้างเจ็บปวด และด้วย semantics อย่าง ownership ที่เข้าใจยาก จึงต้องอาศัยการเรียนรู้มากกว่าภาษาทั่วไปอย่าง Python หรือ Java มากทีเดียว.
 
dalinaum 2022-09-21

เวลาในการคอมไพล์น่าจะเป็นปัญหาใหญ่ของตัว LLVM เอง Facebook ก็กำลังทุ่มเทเพื่อปรับปรุง instruction selection ของ LLVM อยู่ ดังนั้นสถานการณ์คงจะดีขึ้นครับ
 
functor 2022-09-22

พอลองค้นดูแล้วก็เป็นแบบนั้นจริง ๆ นะครับ ผมนึกว่าเขาใช้เวลาไปกับการตรวจเช็กชนิดข้อมูลที่เกี่ยวกับ ownership เยอะมาก แต่ดูเหมือนว่า llvm backend จะเป็นส่วนใหญ่..
 
ahwjdekf 2022-09-21

ตอนที่ rust ออกมาใหม่ ๆ ผมสนใจมากและลองศึกษาอยู่พักหนึ่ง... แต่พอเห็นเรื่อง unsafe ก็เลิกทันทีเลย ผมหาเหตุผลที่สมเหตุสมผลมาชักจูงตัวเองไม่ได้จริง ๆ ว่าทำไมต้องเรียนแล้วเอามาใช้ เพราะยังไงโปรแกรมที่ซับซ้อนขึ้นมาหน่อยก็ต้องใช้ unsafe อยู่ดี แล้วถ้าเป็นแบบนั้น ความปลอดภัยที่ rust ชอบเอามาอวดก็คงหายไป แบบนี้จะใช้มันไปทำไม?
 
mastotron 2022-09-21

ใน Rust unsafe จำเป็นก็ต่อเมื่อต้องเขียนโค้ดระดับล่างเท่านั้น สำหรับการเขียนแอปพลิเคชันทั่วไปแทบจะถือได้ว่าไม่มีโอกาสต้องใช้เลย

และถึงแม้จะเกิดปัญหาด้านหน่วยความจำภายในบล็อก unsafe ก็ยังมีข้อดีตรงที่ตัวภาษารับประกันได้ว่าจุดที่เกิดปัญหาจะอยู่ภายในบล็อก unsafe ทำให้ดีบักได้ง่ายขึ้นด้วยครับ
 
functor 2022-09-21

ถ้ามี unsafe แล้วจะถามว่า "จะใช้สิ่งนี้ไปทำไม?" ตั้งแต่แรกก็คงไม่ควรใช้ C/C++ อยู่แล้วไม่ใช่เหรอ?
 
ahwjdekf 2022-09-21

C++ ก็ยังพัฒนาอย่างต่อเนื่องอยู่ และถ้าจะใช้ unsafe ก็สู้ใช้ C++ ไปเลยดีกว่า จึงไม่ค่อยรู้สึกถึงความจำเป็นที่จะต้องเรียน Rust แล้วนำมาใช้
 
functor 2022-09-21

ไม่ใช่ว่าการเขียนโปรแกรมด้วย Rust ทุกอย่างจะต้องใช้ unsafe เสมอไปนะครับ
การจัดการหน่วยความจำอย่างละเอียดอ่อนถึงขั้นต้องใช้ unsafe โดยปกติมักแยกไปอยู่ฝั่งพัฒนาไลบรารีเสียมากกว่า ดังนั้นในฝั่งพัฒนาแอปพลิเคชันซึ่งน่าจะมีความต้องการมากที่สุด ผมมองว่าแทบจะไม่มีเรื่องให้ต้องใช้ unsafe เลย
C++ เองก็จริงที่ยังพัฒนาต่อเนื่องอยู่ แต่ภาระจาก legacy เพื่อรักษาความเข้ากันได้ย้อนหลังนั้นเจ็บปวดมากจริง ๆ ถ้าคุณไม่พอใจเพียงเพราะ unsafe ตัวเดียว ผมว่าคงไม่พอใจกับฟีเจอร์ทั้งหมดของ C++ เหมือนกันแหละครับ 555
 
alstjr7375 2022-09-21

ดังนั้น unsafe จึงไม่ใช่สิ่งที่แนะนำ
ถ้าใช้ safe ก็ปลอดภัยกว่า C/C++ ที่ทุกอย่างแทบไม่ต่างจาก unsafe อยู่แล้ว
https://people.mpi-sws.org/~dreyer/papers/rustbelt/paper.pdf
 
ahwjdekf 2022-09-21

ถ้าไม่มี unsafe ซึ่งเป็นกลไกที่กำกวมคลุมเครือ Rust ก็อาจจะกลายเป็นทางเลือกแท้จริงของ C++ ได้เหมือนกัน
 
jjpark78 2022-09-21

ผมก็คิดเหมือนกันนะว่าถ้า FFI เป็นมิตรกว่านี้อีกสักหน่อยก็คงดี.. ผมเคยพยายามส่งรับ composite struct กับไลบรารีภายนอกผ่าน FFI แล้วจำได้เลยว่าทรมานมาก
 
alstjr7375 2022-09-21

แม้แต่ rust to rust เองก็ยังไม่ง่ายเลย..
https://github.com/rodrimati1992/abi_stable_crates
 
jjpark78 2022-09-21

เมื่อมองว่าเป็นส่วนต่อเนื่องของสถานการณ์ที่ MS สนับสนุน Rust อย่างจริงจัง ก็ถือว่าเป็นคำกล่าวที่ดูเป็นธรรมชาติมาก
 
colus001 2022-09-21

แม้แต่ Torvalds ที่ดื้อดึงคนนั้นก็ยังรับ Rust มาใช้แล้ว ผมเลยไม่รู้สึกว่าจำเป็นต้องฝืนใช้ภาษาที่คนเรียนก็น้อยลงต่อไปอีก
 
ahwjdekf 2022-09-21

บั๊กที่เกี่ยวกับหน่วยความจำไม่ได้หายไปอย่างแน่นอนเพียงแค่ใช้ Rust หรอก คนที่สร้างบั๊ก ต่อให้ยื่นภาษาอะไรให้ก็ยังผลิตบั๊กออกมาได้อยู่ดี ตอนนี้ก็ใช้ C++ ได้อย่างมีประสิทธิภาพดีโดยไม่มีปัญหาอะไร จะมาบอกให้เลิกอะไรกัน คำพูดแรงแบบนี้นี่แทบจะเป็นคำพูดโยนระเบิดตอนเกิดสงครามเลย พูดส่งเดชเกินไปแล้ว
 
functor 2022-09-21

จะบอกว่าใช้ C/C++ ได้อย่างมีประสิทธิภาพดีโดยไม่มีปัญหาอะไรเลยก็คงไม่ได้ เพราะในเชิงประวัติศาสตร์มีบั๊กที่เกี่ยวข้องกับหน่วยความจำจำนวนมากเกิดขึ้นจาก C/C++ มาแล้ว และตอนนี้ก็น่าจะยังเกิดอยู่ที่ไหนสักแห่ง (แม้จะทำให้นักวิจัยสาย PL/SE จำนวนมากมีงานทำก็เถอะ)
ตามที่ Microsoft ประกาศ บั๊กด้านความปลอดภัย 70% เป็นบั๊กที่เกี่ยวข้องกับหน่วยความจำ (https://zdnet.com/article/…)
ผลการสำรวจจากโครงการ Chromium ก็ออกมาคล้ายกัน (https://www.chromium.org/Home/chromium-security/memory-safety/) โดยเกือบ 70% ก็เป็นบั๊กที่เกี่ยวข้องกับหน่วยความจำเช่นกัน
 
jjpark78 2022-09-21

บั๊กของเคอร์เนล Windows ส่วนใหญ่เป็นข้อผิดพลาดที่เกี่ยวกับหน่วยความจำ
และผมเคยเห็นบทความก่อนหน้านี้ที่บอกว่าสำหรับส่วนที่พัฒนาด้วย Rust ข้อผิดพลาดประเภทนี้ลดลงอย่างมาก..

ด้วยการออกแบบของภาษาตั้งแต่ต้นที่สนับสนุน readonly อย่างจริงจัง จึงคงปฏิเสธได้ยากว่าเป็นการออกแบบทางภาษาที่ปลอดภัยกว่า C++ อย่างไรก็ตาม เพราะเหตุนี้เองจึงมีแนวคิดเรื่อง ownership ที่ไม่เคยได้ยินได้ฟังมาก่อนโผล่เข้ามา ทำให้การเขียนโปรแกรมยากขึ้น

และยังมีข้อได้เปรียบด้านประสิทธิภาพด้วย คือโค้ด Rust ที่ทำแบบพอๆ ไปยังรันได้เร็วกว่าโค้ด C++ ที่ออกแบบมาอย่างดีมากในเชิงสถิติ
 
lordang 2022-09-21

ดูเหมือนจะพูดอะไรที่เสี่ยงโดนถล่มพอสมควรเลยนะครับ 555
ส่วนตัวผมมองว่า C++ เก่าเกินไปจนถูกข้อจำกัดจากความเข้ากันได้ย้อนหลังฉุดไว้ ทำให้พัฒนาไปในทางที่โมเดิร์นได้ช้า
แล้วพอพยายามใส่สิ่งที่โมเดิร์นเข้าไปพร้อมกับรักษาความเข้ากันได้ย้อนหลังอย่างเคร่งครัด วิธีทำงานเดียวกันก็เลยมีหลายแบบเกินไป จนผมคิดว่านี่กลับกลายเป็นอุปสรรคในการเริ่มต้นสำหรับมือใหม่มากกว่า
ตอนนี้ผมเองก็มองว่า Rust ดีกว่า C++ แล้ว ยุคที่ต้องตาแดงนั่งไล่หาบั๊กเกี่ยวกับการจัดการหน่วยความจำคงถึงเวลาจบเสียที
 
jjpark78 2022-09-21

ใช่ครับ.. ถ้าเป็นโปรเจ็กต์พัฒนาที่เริ่มจากศูนย์ ก็ไม่มีเหตุผลอะไรเป็นพิเศษที่จะต้องเลือก c++ เลย..
 
kandk 2022-09-21

เห็นด้วยสุดๆ
 
loblue 2022-09-22

ถึงอยากใช้ Rust ก็ได้แค่ใช้เสริม ๆ แต่ในงานจริงยังไม่มีโอกาสได้ใช้เลยครับ
ก็เลยไม่ค่อยได้คุ้นมือ แถมถ้าวางมือไปแป๊บหนึ่งก็ลืมอีก...
ชัดเจนว่าเป็นของที่อยากใช้เพราะชอบจริง ๆ ... ฮ่า
 
koreacglee 2022-09-23

พวกที่ไม่เคยเขียน memory pool สักครั้งเพื่อเพิ่มประสิทธิภาพการใช้งาน heap ยังมาพร่ำเรื่อง RUST กันใหญ่เลย 555
แน่นอนว่า Azure CTO ไม่ได้เป็นความเห็นที่มีน้ำหนักถึงขั้นเป็นตัวแทนมาตรฐานของทั้งอุตสาหกรรม และต่อให้จำกัดแค่ใน Microsoft เอง ก็ไม่ใช่ความเห็นที่เป็นตัวแทนจุดยืนของบริษัทอย่างเด็ดขาด เป็นแค่การที่จู่ ๆ นึกอะไรขึ้นมาได้แล้วพร่ำบ่นความเห็นส่วนตัวของตัวเองเท่านั้นแหละ... พวกที่ทำ C++ ไม่เป็นให้ถูกต้อง จะทำ Rust ได้ดีจริงเหรอ? สรุปแล้วก็มีแต่พวกดีแต่พูดเต็มไปหมด
 
functor 2022-09-26

จากสำนวนพูดของคุณก็เผยให้เห็นความหยาบคายได้อย่างชัดเจนเลยนะครับ สู้ ๆ ครับ