שפות תכנות

תוכן העניינים:

• סיכום
  • בעיה
  • החלטה
  • מצב
• פרטים
  • הנחות
  • אילוצים
  • עמדות
  • טיעון
  • השלכות
• נושאים קשורים
  • החלטות קשורות
  • דרישות קשורות
  • תוצרים קשורים
  • עקרונות קשורים
• הערות

סיכום

בעיה

אנו צריכים לבחור שפות תכנות לתוכנה שלנו. יש לנו שני צרכים עיקריים: שפת תכנות לצד לקוח המתאימה ליישומי ווב, ושפת תכנות לצד שרת המתאימה ליישומי שרת.

החלטה

אנו בוחרים ב-TypeScript לצד הלקוח.

אנו בוחרים ב-Rust לצד השרת.

מצב

הוחלט. אנו פתוחים לחלופות חדשות כשיופיעו.

פרטים

הנחות

יישומי צד הלקוח הם טיפוסיים:

• משתמשים ואינטראקציות טיפוסיים

• דפדפנים ומערכות טיפוסיים

• פיתוחים ופריסות טיפוסיים

יישומי צד הלקוח צפויים להתפתח במהירות:

• אנו רוצים להבטיח פיתוחים, פריסות, איטרציות וכדומה מהירים וקלים.

• אנו מעריכים יכולת הוכחה, כמו בטיחות טיפוסים, ומוכנים לעבוד קצת יותר כדי להשיג אותה.

• איננו זקוקים לתאימות מורשת.

יישומי צד השרת הם ברמה גבוהה מהטיפוסי:

• יעדים גבוהים מהטיפוסי לאיכות, במיוחד יכולת הוכחה, אמינות, אבטחה וכדומה.

• יעדים גבוהים מהטיפוסי לזמן אמת כמעט, כלומר איננו רוצים השהיות עקב איסוף אשפה במכונה וירטואלית.

• יעדים גבוהים מהטיפוסי לתכנות פונקציונלי, במיוחד למקבול, לעיבוד רב-ליבתי ולבטיחות זיכרון.

אנו מקבלים מהירויות קומפילציה נמוכות יותר לטובת בטיחות בזמן קומפילציה ומהירויות בזמן ריצה.

אילוצים

יש לנו אילוץ חזק על שפות שאפשר להשתמש בהן עם שירותי ספקי ענן עיקריים לפונקציות, כמו Amazon Lambda.

עמדות

שקלנו את השפות האלה:

• C

• C++

• Clojure

• Elixir

• Erlang

• Elm

• Flow

• Go

• Haskell

• Java

• JavaScript

• Kotlin

• Python

• Ruby

• Rust

• TypeScript

טיעון

סיכום לכל שפה:

• C: נדחתה בגלל בטיחות נמוכה; Rust יכולה לעשות כמעט הכול טוב יותר.

• C++: נדחתה כי היא בלגן; Rust יכולה לעשות כמעט הכול טוב יותר.

• Clojure: מידול מצוין; קירוב ה-Lisp הטוב ביותר; סביבת ריצה מצוינת על ה-JVM.

• Elixir: סביבת ריצה מצוינת כולל יכולת פריסה ומקביליות; חוויית מפתח מצוינת; אקוסיסטם קטן יחסית.

• Erlang: סביבת ריצה מצוינת כולל יכולת פריסה ומקביליות; חוויית מפתח מאתגרת; אקוסיסטם קטן יחסית.

• Elm: נראית מבטיחה מאוד; IBM מפרסמת מקרי בוחן גדולים עם תוצאות טובות; אקוסיסטם קטן יותר.

• Flow: שיפור מעניין על JavaScript; אולם מפתחים מתרחקים ממנה.

• Go: חוויית מפתח מצוינת; מקביליות מצוינת; אבל רקורד של החלטות גרועות שמשתקות את השפה.

• Haskell: השפה הפונקציונלית הטובה ביותר; קהילת מפתחים קטנה יותר; לא השיגה מספיק הצלחות ייצור מפורסמות.

• Java: סביבת ריצה מצוינת; אקוסיסטם מצוין; חוויית מפתח ברמה נמוכה.

• JavaScript: השפה הפופולרית ביותר אי פעם; האקוסיסטם הנפוץ ביותר.

• Kotlin: מתקנת כל כך הרבה מ-Java; גיבוי מצוין של JetBrains; מקרים טובים שפורסמו של העברה מ-Java ל-Kotlin.

• Python: השפה הפופולרית ביותר לניהול מערכות; כלי ניתוח מצוינים; מסגרות ווב טובות; אבל ננטשה על ידי Google לטובת Go.

• Ruby: חוויית המפתח הטובה ביותר אי פעם; מסגרות הווב הטובות ביותר; הקהילה הנעימה ביותר; אבל איטית מאוד; קשה במידה מסוימת לאריזה.

• Rust: השפה החדשה הטובה ביותר; דגש על אפס הפשטה; דגש על מקביליות; אולם אקוסיסטם קטן יחסית; ויש לה מגבלות מכוונות על סוגים מסוימים של האצות מהדר, למשל גישה ישירה לזיכרון צריכה להיות מפורשות לא בטוחה.

• TypeScript: מוסיפה טיפוסים ל-JavaScript; מתרגם (transpiler) מצוין; דגש גובר של מפתחים על העברה מ-JavaScript ל-TypeScript; גיבוי חזק של Microsoft.

החלטנו שלמכונות וירטואליות יש קבוצת שיקולי ביניים שאיננו זקוקים להם כרגע, כמו מורכבות נוספת שמספקת יכולות בזמן ריצה.

אנו מאמינים שההחלטה המרכזית שלנו מונעת משני שיקולים חוצי-מערכת:

• למהירות ריצה מהירה ביותר וגישה הדוקה ביותר למערכת, היינו בוחרים ב-JavaScript וב-C.

• למהירות ריצה קרובה למהירה ביותר וגישה קרובה להדוקה ביותר למערכת, אנו בוחרים ב-TypeScript וב-Rust.

אזכור לשבח לשפות המכונה הווירטואלית ולמסגרות הווב שהיינו בוחרים אילו היינו רוצים שפת מכונה וירטואלית:

• Clojure ו-Luminus

• Java ו-Spring

• Elixir ו-Phoenix

השלכות

מפתחי צד לקוח יצטרכו ללמוד TypeScript. כנראה זו עקומת למידה קלה אם הניסיון העיקרי של המפתח הוא עם JavaScript.

מפתחי צד שרת יצטרכו ללמוד Rust. כנראה זו עקומת למידה בינונית אם הניסיון העיקרי של המפתח הוא עם C/C++, ועקומת למידה קשה אם הניסיון העיקרי של המפתח הוא עם Java, Python, Ruby או שפות דומות עם ניהול זיכרון.

TypeScript ו-Rust חדשות שתיהן יחסית. משמעות הדבר היא שלכלים רבים עדיין אין תיעוד לשפות האלה. לדוגמה, צינור ה-devops יצטרך להיות מוקם לשפות האלה, ועד כה, באף אחד מכלי ה-devops שאנו מעריכים אין דוגמאות ברירת מחדל לשפות האלה.

זמני הקומפילציה של TypeScript ושל Rust איטיים למדי. חלק מזה עשוי לנבוע מחידשות השפות. ייתכן שנרצה לבחון איך למתן זמני קומפילציה איטיים, למשל קומפילציה לפי דרישה, מקביליות בקומפילציה וכדומה.

התמיכה ב-IDE בשפות האלה עדיין אינה נפוצה ועדיין אינה מהמעלה הראשונה. לדוגמה, JetBrains מוכרת את ה-IDE בשם PyCharm לתמיכה מהמעלה הראשונה ב-Python, אבל אינה מוכרת IDE עם תמיכה מהמעלה הראשונה ב-Rust; במקום זאת, JetBrains יכולה להשתמש בתוסף Rust שמספק אולי 80% מתמיכת שפת Rust ביחס לתמיכת שפת Python.

נושאים קשורים

החלטות קשורות

נשאף לבחירות אקוסיסטם שמתיישרות עם השפות האלה.

לדוגמה, אנו רוצים לבחור IDE בעל יכולות טובות לשפות האלה.

לדוגמה, למסגרת הווב בצד הלקוח שלנו, סביר יותר שנחליט על מסגרת שנוטה לכיוון TypeScript (למשל Vue) מאשר על מסגרת שנוטה לכיוון JavaScript רגיל (למשל React).

דרישות קשורות

שרשרת הכלים כולה שלנו חייבת לתמוך בשפות האלה.

תוצרים קשורים

אנו מצפים שנייצא כמה סודות למשתני סביבה.

עקרונות קשורים

למדוד פעמיים, לבנות פעם אחת. אנו מעדיפים מעט בטיחות על פני מעט מהירות.

זמן ריצה בעל ערך רב יותר מזמן קומפילציה. אנו מעדיפים שימוש לקוחות על פני שימוש מפתחים.

הערות

כאן אפשר להוסיף הערות.