คำถามติดแท็ก rust

1
ลักษณะของ Rust แตกต่างจาก Go Interfaces อย่างไร
ฉันค่อนข้างคุ้นเคยกับ Go โดยเขียนโปรแกรมขนาดเล็กจำนวนมากในนั้น แน่นอนว่าสนิมฉันไม่คุ้นเคย แต่จับตาดู เมื่อเร็ว ๆ นี้อ่านhttp://yager.io/programming/go.htmlฉันคิดว่าฉันควรตรวจสอบสองวิธีที่ Generics ได้รับการจัดการเพราะบทความดูเหมือนจะวิพากษ์วิจารณ์อย่างไม่เป็นธรรมไปเมื่อในทางปฏิบัติมีอะไรมากที่อินเตอร์เฟส ไม่สามารถทำได้อย่างสวยงาม ฉันยังคงได้ยินโฆษณาต่อไปเกี่ยวกับลักษณะของ Rust ที่ทรงพลังและไม่มีอะไรนอกจากการวิจารณ์จากคนเกี่ยวกับ Go มีประสบการณ์ใน Go ฉันสงสัยว่าความจริงมันเป็นอย่างไรและอะไรคือความแตกต่างในท้ายที่สุด สิ่งที่ฉันพบคือลักษณะและการเชื่อมต่อมีความคล้ายคลึงกัน! ท้ายที่สุดฉันไม่แน่ใจว่าฉันขาดอะไรบางอย่างดังนั้นนี่คือบทสรุปการศึกษาที่รวดเร็วเกี่ยวกับความคล้ายคลึงกันของพวกเขาเพื่อให้คุณสามารถบอกฉันว่าฉันพลาดอะไรไป! ตอนนี้ขอใช้เวลาดูไปเชื่อมต่อจากพวกเขาเอกสาร : อินเทอร์เฟซในตัวไปมีวิธีในการระบุพฤติกรรมของวัตถุ: หากมีสิ่งใดสามารถทำได้ก็สามารถใช้ที่นี่ได้ ส่วนใหญ่แล้วอินเตอร์เฟสจะStringerส่งคืนสตริงที่แสดงถึงวัตถุ type Stringer interface { String() string } ดังนั้นวัตถุใด ๆ ที่มีการString()กำหนดไว้เป็นStringerวัตถุ นี้สามารถใช้ในลายเซ็นประเภทเช่นที่func (s Stringer) print()ใช้วัตถุเกือบทั้งหมดและพิมพ์ นอกจากนี้เรายังมีinterface{}สิ่งที่ใช้วัตถุใด ๆ จากนั้นเราจะต้องกำหนดประเภทของรันไทม์ผ่านการสะท้อนกลับ ตอนนี้เรามาดูลักษณะของสนิมจากเอกสารประกอบ : ที่ง่ายที่สุดลักษณะคือชุดของลายเซ็นวิธีการศูนย์หรือมากกว่า ตัวอย่างเช่นเราสามารถประกาศลักษณะที่พิมพ์ได้สำหรับสิ่งที่สามารถพิมพ์ไปยังคอนโซลด้วยลายเซ็นวิธีการเดียว: trait Printable { fn …
64 go  rust 

2
Rust แตกต่างจากสิ่งอำนวยความสะดวกในการทำงานพร้อมกันของ C ++ อย่างไร
คำถาม ฉันพยายามที่จะเข้าใจว่าสนิมช่วยปรับปรุงพื้นฐานและพร้อมกันของสิ่งอำนวยความสะดวกในการทำงานพร้อมกันของ C ++ หรือไม่เพื่อที่จะตัดสินใจว่าฉันควรใช้เวลาในการเรียนรู้สนิมหรือไม่ โดยเฉพาะอย่างยิ่ง idiomatic Rust จะพัฒนาขึ้นอย่างไรหรือในอัตราที่ต่างกันอย่างไรสิ่งอำนวยความสะดวกที่เกิดขึ้นพร้อมกันของ C ++ การปรับปรุง (หรือความแตกต่าง) ส่วนใหญ่เกี่ยวกับการสร้างประโยคหรือเป็นการปรับปรุงที่สำคัญในกระบวนทัศน์หรือไม่? หรือมันเป็นอย่างอื่น? หรือไม่เป็นการปรับปรุงที่แท้จริง (divergence) เลยเหรอ? หลักการและเหตุผล ฉันเพิ่งพยายามสอนสิ่งอำนวยความสะดวกในการทำงานพร้อมกันของ C ++ 14 และมีบางสิ่งที่รู้สึกไม่ถูกต้อง บางสิ่งบางอย่างรู้สึกปิด สิ่งที่รู้สึกออก? ยากที่จะพูด. รู้สึกว่าคอมไพเลอร์ไม่ได้พยายามช่วยฉันในการเขียนโปรแกรมที่ถูกต้องเมื่อพูดถึงการทำงานพร้อมกัน รู้สึกราวกับว่าฉันกำลังใช้แอสเซมเบลอร์มากกว่าคอมไพเลอร์ เป็นที่ยอมรับกันว่าเป็นไปได้ทั้งหมดที่ฉันยังต้องทนทุกข์ทรมานจากแนวคิดที่บอบบางและผิดพลาดเมื่อมันเกิดขึ้นพร้อมกัน บางทีฉันอาจจะยังไม่เห็นความตึงเครียดของ Bartosz Milewski ระหว่างการเขียนโปรแกรมแบบรัฐและการแข่งขันข้อมูล บางทีฉันอาจไม่เข้าใจว่ามีวิธีการทำงานพร้อมกันของเสียงในคอมไพเลอร์มากน้อยแค่ไหนและมันมีอยู่ในระบบปฏิบัติการเท่าใด
35 c++  concurrency  rust  c++14 

8
ใช้ระบบพิมพ์ที่“ แข็งแกร่ง” ในโลกแห่งความเป็นจริงพูดสำหรับเว็บแอปขนาดใหญ่หรือไม่?
ฉันรู้ว่านี่เป็นคำถามที่กว้างขวางคลุมเครือและเป็นไปได้ทางปรัชญา ในขอบเขตที่คำหลักที่สำคัญที่สุดในคำถาม - "ความเชื่อ" ระบบการพิมพ์ - ตัวเองเป็นป่วยกำหนด ดังนั้นให้ฉันพยายามอธิบายสิ่งที่ฉันหมายถึง บริบทโดยรวมของคำถาม เราได้สร้างเว็บแอปขนาดใหญ่ขึ้นใน Ruby on Rails และโดยทั่วไปเรามีความสุขกับกองซ้อนของเรา เมื่อเราต้องการเราสามารถจัดส่งสิ่งต่าง ๆ ได้อย่างรวดเร็วจริง ๆ - สิ่งที่ใช้งานได้ 90% ของคดี "ธุรกิจ" โดยไม่ต้องกังวลเรื่องขอบคดีมากถึง 10% ในทางกลับกันด้วยความช่วยเหลือในการใช้โค้ดรีวิวและทดสอบครอบคลุมเราจะช้าและพิจารณาและตรวจสอบให้แน่ใจว่าเราครอบคลุมฐานทั้งหมด - อีกครั้งเฉพาะในสถานการณ์ที่สมควรได้รับการตรวจสอบข้อเท็จจริงและความปลอดภัยอย่างใกล้ชิด อย่างไรก็ตามเมื่อทีมเติบโตขึ้นฉันเริ่มรู้สึกไม่สบายใจกับการขาด "ตาข่ายนิรภัย" ที่ถูกอบเข้าไปในกองของเรา เราเพิ่งเริ่มทำการพัฒนา Android พื้นเมืองบน Java และฉันก็นึกถึงความปลอดภัยที่จัดเตรียมโดยภาษาที่รวบรวม / คงที่ / พิมพ์ดีดอย่างยิ่ง ตัวแปรที่สะกดผิดประเภทข้อมูลที่ไม่ถูกต้องการเรียกใช้ฟังก์ชันที่ไม่ถูกต้องและโฮสต์ของข้อผิดพลาดเล็กน้อยที่ IDE ของคุณติดอยู่เอง ทั้งหมดเป็นเพราะ IDE สามารถเชื่อมต่อกับคอมไพเลอร์และตรวจสอบบางแง่มุมของโปรแกรม "ความถูกต้อง" ต้องการเปลี่ยนลายเซ็นฟังก์ชั่นหรือไม่? ง่าย. คอมไพเลอร์ …

1
เป็นไปได้ที่จะบรรลุถึงรูปแบบการเป็นเจ้าของของ Rust ด้วยเสื้อคลุม C ++ ทั่วไปหรือไม่
ดูบทความนี้เกี่ยวกับความปลอดภัยของการเกิดพร้อมกันของ Rust: http://blog.rust-lang.org/2015/04/10/Fearless-Concurrency.html ฉันสงสัยว่าความคิดเหล่านี้สามารถทำได้ใน C ++ 11 (หรือใหม่กว่า) โดยเฉพาะอย่างยิ่งฉันสามารถสร้างคลาสของเจ้าของที่โอนความเป็นเจ้าของไปยังวิธีการใด ๆ ที่มันอาจจะผ่าน? ดูเหมือนว่า C ++ มีหลายวิธีในการส่งผ่านตัวแปรที่เป็นไปไม่ได้ แต่บางทีฉันอาจวางข้อ จำกัด บางอย่างในคลาสหรือเทมเพลตเพื่อให้แน่ใจว่าโค้ดเทมเพลตบางตัวได้รับการประมวลผลด้วยวิธีการส่งผ่านทุกครั้งหรือไม่

5
เป็นไปได้หรือไม่ที่จะประเมินความปลอดภัยของโปรแกรมสำหรับรหัสที่กำหนดเอง?
เมื่อเร็ว ๆ นี้ฉันคิดถึงรหัสที่ปลอดภัยมาก Thread ปลอดภัย หน่วยความจำที่ปลอดภัย ไม่ระเบิดในหน้าของคุณด้วย -a- segfault ปลอดภัย แต่เพื่อความชัดเจนในคำถามลองใช้โมเดลความปลอดภัยของรัสเป็นคำจำกัดความต่อเนื่องของเรา บ่อยครั้งที่การทำให้มั่นใจในความปลอดภัยนั้นเป็นปัญหาใหญ่แค่ไหนเพราะได้รับการพิสูจน์โดยความต้องการของ Rust unsafeมีแนวคิดการเขียนโปรแกรมที่สมเหตุสมผลเช่นการเห็นพ้องต้องกันซึ่งไม่สามารถนำมาใช้ใน Rust ได้โดยไม่ต้องใช้unsafeคำสำคัญ . แม้ว่าการทำงานพร้อมกันสามารถทำให้ปลอดภัยได้อย่างสมบูรณ์แบบด้วยการล็อก mutexes ช่องทางและการแยกหน่วยความจำหรือสิ่งที่มีอยู่คุณต้องทำงานนอกรูปแบบความปลอดภัยของ Rust ด้วยunsafeแล้วรับรองตัวแปลด้วยตนเองว่า"ใช่ฉันรู้ว่าฉันกำลังทำอะไร สิ่งนี้ดูไม่ปลอดภัย แต่ฉันได้พิสูจน์แล้วว่าในทางคณิตศาสตร์มันปลอดภัยอย่างสมบูรณ์ " แต่ปกติแล้วจะลงมาด้วยตนเองทำให้รูปแบบของสิ่งเหล่านี้และพวกเขาพิสูจน์ความปลอดภัยอยู่กับprovers ทฤษฎีบท จากทั้งมุมมองวิทยาศาสตร์คอมพิวเตอร์ (เป็นไปได้) และมุมมองการปฏิบัติจริง (มันจะใช้ชีวิตของจักรวาล) มันสมเหตุสมผลที่จะจินตนาการโปรแกรมที่ใช้รหัสโดยพลการในภาษาใด ๆ และประเมินว่ามันเป็นหรือไม่ " ปลอดภัยสนิม "? คำเตือน : สิ่งที่ง่ายในเรื่องนี้ก็คือการชี้ให้เห็นว่าโปรแกรมอาจจะปล่อยปละละเลยดังนั้นปัญหาการหยุดทำงานจึงทำให้เราล้มเหลว สมมติว่าโปรแกรมใดก็ตามที่ส่งไปยังผู้อ่านนั้นรับประกันว่าจะหยุด ในขณะที่ "รหัสโดยพลการในภาษาใด ๆ " เป็นเป้าหมาย แต่ฉันก็ตระหนักว่าสิ่งนี้ขึ้นอยู่กับความคุ้นเคยของโปรแกรมกับภาษาที่เลือกซึ่งเราจะดำเนินการตามที่กำหนด
โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.