השילוב של Rust בלינוקס קיבל רמה גבוהה של קבלה על ידי הקהילה והמפתחים
אחד בעיות עיקריות שהתעוררו בפיתוח הקרנל של לינוקס במשך זמן רב, הוא הרעיון למצוא מועמד מושלם לשנות את שפת התכנות "C" עבור מודרני יותר ועד לאחרונה עם הגעתו של Rust, הרעיון הזה לא הפסיק להיות מוצב על השולחן.
עם התצוגה המקדימה הראשונה של Rust ב-Linux 6.1, אני מחייה את הרוחות מצד חלק גדול מהמפתחים של הליבה וג'ונתן קורבט מציינים ש"עדיין לא יהיה מספיק חלודה בקרנל כדי לעשות משהו מעניין", הכללת שפה זו הציתה מחדש את הוויכוח על הצורך להשליך את שפת ה-C לטובת Rust במונחים של תכנות המערכת. השאלה מפלגת את קהילת המפתחים.
אסאהי ליניה לקח על עצמו את המשימה לפתח מנהל התקן ליחידת עיבוד גרפי (GPU) עבור ה-Mac M1 ב-Rust.
על ההשוואה שלך בין שפות Rust ושפות C מזכיר כי:
"אין שום סיכוי שלא תצטרך להתמודד עם ניהול גישה בו-זמנית, ניסיונות שלאחר השחרור לגשת לאזורי זיכרון, וכל מיני בעיות אחרות אם היית כותב את זה ב-C. כל בעיות במקביל נעלמות עם Rust! הזיכרון מתפנה בעת הצורך! ברגע שתלמד איך לגרום ל-Rust לעבוד בשבילך, אני חושב שזה ידריך אותך לכתיבת קוד הגון, אפילו מעבר להבטחות האבטחה של השפה. זה ממש קסום! »
"יש הרבה ויכוחים אם Rust שימושי בקרנל או לא... מניסיוני, זה הרבה יותר שימושי ממה שאי פעם דמיינתי!" ", היא מוסיפה.
ההערות שלך די חוזרות על עצמן מתוך אוסף של סיבות טכניות שכנראה להצדיק ביטול שפת C לטובת Rust. למעשה, 15,9% מ-2288 הפגיעויות שהשפיעו על ליבת לינוקס ב-20 שנה (נתונים ממילון Common Vulnerabilities and Exposure (CVE)) קשורות לפגמים בשפת C, בעיות הקשורות לניהול הזיכרון: הצפת חיץ , הקצאות לא משוחררות, גישה לאזורי זיכרון לא חוקיים או משוחררים וכו'.
בנוסף, המתחזקים העיקריים של ליבת לינוקס מכירים את שפת C, שגילה כבר נחשב בגיל השלישי. דור חדש של מתחזקים שקבוצת הגיל שלהם בשנות השלושים לחייהם נמצא במגמת עלייה, ולפיכך הקושי למצוא מתחזקים לגרעין הלינוקס צפוי לגדול אם הפיתוח שלו יימשך בשפת C. הסיבות שבגללן לינוס טורוואלדס פתח את הדלת לקרנל פיתוח ב- Rust.
בשאלת האפשרות לבטל את שפת C, היוצר של שפת C מפרט מספר סיבות מדוע יוזמות עלולות להיכשל שהולכים בכיוון הזה:
שרשרת כלי השפה של VS
שפת C היא לא רק השפה עצמה, אלא גם כל כלי הפיתוח שפותחו לשפה זו.
האם אתה רוצה לבצע ניתוח סטטי של קוד המקור שלך? – יש הרבה אנשים שעובדים על זה עבור C. כלים לאיתור דליפות זיכרון, מירוצי נתונים ושגיאות אחרות? יש הרבה, גם אם השפה שלך מצוידת יותר.
אם אתה רוצה למקד לפלטפורמה לא מוכרת, רוב הסיכויים שאתה משתמש בסטטוס של C. C בתור השפה הצרפתית של המחשוב היום עושה את זה שווה כלים לכתיבה, וכלים רבים נכתבים.
אם למישהו יש שרשרת כלים עובדת:
למה להסתכן בשינוי השפה? "C טוב יותר" אמור לייצר הרבה פרודוקטיביות נוספת כדי להניע את הזמן המושקע בהקמת שרשרת כלים חדשה. האם זה אפשרי נותר לראות.
אי הוודאות של שפה חדשה
לפני ששפה מגיעה לבגרות, סביר להניח שהיא תהיה באגי. והוא שונה באופן משמעותי כדי לטפל בבעיות הסמנטיות של השפה. והאם השפה בכלל תואמת את המודעה? זה יכול להציע משהו כמו "זמני קומפילציה יוצאי דופן" או "מהיר יותר מ-C", אך מטרות אלו הופכות קשות להשגה כאשר השפה מוסיפה את
והמתחזקים? בטח, אתה יכול למכור שפת קוד פתוח, אבל אני בספק אם חברות רבות יהיו מעוניינות להשתמש בשפה שאולי הן ייאלצו לשמור מאוחר יותר. הימור על שפה חדשה הוא סיכון גדול.
העובדה שהשפה אולי לא מספיק טובה
האם השפה מתייחסת לנקודות הכאב בפועל של C?
מסתבר ש אנשים לא תמיד מסכימים מהן החולשות של ג'. הקצאת זיכרון, טיפול במערך ובמחרוזות הם לרוב מסובכים, אך עם הספריות הנכונות ואסטרטגיית זיכרון טובה, ניתן למזער אותם.
האם השפה לא מטפלת בבעיות שלמשתמשים מתקדמים לא ממש אכפת מהן? אם כן, הערך האמיתי שלו יכול להיות הרבה פחות מהצפוי.
וחמור מכך, מה אם השפה משמיטה מאפיינים מכריעים שקיימים ב-C? תכונות שמתכנתי C מתקדמים מסתמכים עליהן? הסיכון הזה גדל אם מעצב השפה לא השתמש הרבה ב-C, אלא מגיע מ-C++, Java וכו'.
חוסר במפתחים מנוסים לשפה חדשה
לשפה חדשה תהיה, באופן טבעי, מאגר קטן בהרבה של מפתחים מנוסים. עבור כל חברה בינונית או גדולה זו בעיה גדולה. ככל שיותר מפתחים זמינים לחברה, כך מצבה טוב יותר.
כמו כן, אם לחברה יש ניסיון בגיוס מפתחי C, הם לא יודעים איך לגייס לשפה החדשה הזו.
לבסוף, אם אתה מעוניין לדעת יותר על כך, תוכל להתייעץ עם פרטים בקישור הבא.