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

• אם collectData == true – התוכנה תתנהג כצפוי.
• אם collectData == false, אנו נקבל שגיאת panic שאומר כך: invalid memory address or nil pointer dereference. כלומר: ניסינו להשתמש במצביע שהוא nil.

1. הגדרת הפונקציה main, שכבר מוכרת לנו. בשפת גו אין ל main פרמטרים או ערך החזרה (כמו ב C, או ג'אווה).
   המילה השמורה להגדרת פונקציה היא func. לא עוד function ארוך או def בפייטון שנשמע כמו "death". אהבתי! חבל שלא קיצרו עוד יותר וקראו לה fun…
2. לפונקציה יכול להיות ערך החזרה, הוא מוגדר מימין.
   למה מימין? האם זה לא קצת מוזר? הסיבה היא עבור מקרים בהם חתימת הפונקציה היא מורכבת:
   1. הנה תראו את הפונקציה שמקבלת כפרמטרים "פונקציה שמקבלת 2 ints ומחזירה int" ו int, ומחזירה "פונקציה שמקבלת 2 ints ומחזירה int". לוגי, וקריא בצורה מפתיעה – לא?
   2. הנה דוגמה שלילית בה הגדרנו את טיפוס ההחזרה בהתחלה (נניח, כמו בג'אווה). האם אתם מסוגלים לקרוא את זה בלי מאמץ ניכר?
3. הפונקציה יכולה לקבל כמובן כמה פרמטרים. אם הם מאותו טיפוס – ניתן לקצר.
4. ניתן לכתוב גם בכתיבה מלאה. float32 הוא 32 ביט – כך שלא צריך להיזכר כל פעם מהו "double".
5. ניתן להחזיר מפונקציה מספר ערכים. במידה ויש יותר מערך החזרה אחד – יש לשים את ערכי ההחזרה בסוגריים.
6. ניתן לתת שמות לערכי ההחזרה (למשל s1, s2). השמות הללו יוגדרו כמשתנים בפונקציה ולכן אינם יכולים לחפוף לשמות הפרמטרים. הגדרת שמות לערכי ההחזרה מאפשרת לנו להשתמש ב naked return שמחזיר את ערכי המשתנים הרלוונטיים. שימוש אפשרי הוא ערך שאפשר לקבוע בכל מקום בפונקציה, ולעשות return בלי לציין אותו במפורש (למשל error, אבל לא רק).
   הערה: השמות היא שימושיים רק ב scope של הפונקציה, ולא כערך החזרה / חתימה של הפונקציה.
7. פונקציה שמקבלת מספר לא מוגבל של פרמטרים נקראת variadic function. המשתנה שיכיל את "שאר הפרמטרים" מוגדר ע"י שלוש נקודות והטיפוס הרצוי (כמו varargs בשפת ג'אווה). בפועל זה יהיה slice של אותו הטיפוס (מייד נגדיר לעומק מהו slice), והוא חייב להיות הפרמטר האחרון בחתימה הפונקציה – כמובן.

1. הדרך ה"פורמלית" להגדיר slice הוא בעזרת פקודת make (המייצרת עוד כמה מבנים בשפת גו). הפרמטרים שאנו שולחים הם:
   1. טיפוס – כדי ליצור slice עלינו לציין "מערך" של טיפוס, במקרה שלנו int[].
   2. length – אורך ה Slice שאנו רוצים לייצר.
   3. Capacity – אורך המערך שגו תייצר, מאחורי הקלעים, עבור ה slice. ה slice לא יכול לחיות ללא מערך מאחוריו, כמו ש ArrayList או Vector לא יכולים לחיות ללא מערך (למי שמכיר את המימוש).
2. אנו בודקים את תוצר היצירה שלנו
   1. len היא פקודה בשפה שבודקת אורך של מבנה, במקרה הזה ה slince
   2. cap (קיצור של capacity) היא פקודה בשפה שבודקת את אורך התכולה השל המבנה – במקרה שלנו: אורך המערך.
3. צורת הגדרה אחרת היא ה slice literal.
   תחביר ההגדרה דומה מאוד להגדרה של מערך, ההבדל הוא שבהגדרה של מערך עלינו לציין בסוגריים את מספר האיברים (או אפשר פשוט לכתוב שלוש נקודות …)
4. במקרה זה גו ייצור מערך בדיוק באורך של ה slice (כלומר: 5 איברים).
5. כעת אנו מבצעים פעולת slice על ה slice שלנו. נזכיר שהאינדקס לפני ה סימן : בפעולה – הוא איבר שייכלל ב slice שייווצר, והאינדקס שלאחר סימן ה : – לא ייכלל ב slice שייווצר.
6. התוצאה יכולה לרגע מעט להפתיע – אך היא הגיונית: הנה תרשים שיסביר אותה:

האורך של sliceOfSlice הוא אכן 3. ה capacity שלו הוא 4 מכיוון שיש לו עוד תא אחד לגדול במערך.

הוספת איברים ל slice

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

1. אנו יוצרים מערך של int בגודל 4, ומאתחלים אותו בערכים (השמה מרובה). יכולתי להשתמש בתחביר של array literal, אך מכיוון שהוא דומה כ"כ ל slice literal בחרתי בצורה המגושמת, אך המפורשת יותר.
2. מתוך המערך, אנו מבצעים פעולת גזירה – שיוצרת את slice. להזכיר: האינדקס הראשון כלול, והאינדקס השני לא. תחביר מקוצר לפעולה היה יכול להיות [2:]
3. כפי שאנו רואים slice הוא בגודל 2, וה capacity שלו הוא 4 – בגלל המערך שעליו הוא מבוסס.
4. אם אנו מציבים ערך במערך – הוא משתקף מיד ב slice. המערך הוא האחסון של ה slice.
5. כאשר אנו מוסיפים איבר ל slice, היכן הוא יאוחסן? – במערך, כל עוד הוא גדול מספיק.
   המשמעות היא שאנו דורסים את הערך הישן (100) בערך שנוסף ל slice. בעבודה עם מספר slices מעל אותו מערך – יש סכנה של דריסת ערכים הדדית.
6. הנה אני מדפיס את מצב המערך. v% הוא הסימן להציג את הטיפוס בפורמט ברירת-המחדל שלו. זו תצוגה טובה לצורך debugging.
7. ה slice כרגע בגודל 3 ו capacity של 4. מה יקרה אם נוסיף ל slice שני איברים, מערך ל capacity הנתון?
   הפעולה מצליחה, ואנו רואים שה capacity קפץ ל 8 (כמו Vector ב ++C, ג'אווה, וכו' – מגדילים את שטח האחסון פי 2).
8. כפי שאנו רואים ה slice גדל, אך לא המערך. מערך איננו יכול לגדול – בהגדרה.
   פקודת append הגדירה מערך חדש גדול פי 2, והעתיקה אליו את כל הערכים הקיימים. הקשר בין slice ל array ניתק – ו slice עכשיו מצביע (ומאחסן נתונים) במערך חדש שהוקצה עבורו.
9. הנה וידוא נוסף, שזה אכן מה שהתרחש: אנו מציבים ערך ב array – ורואים שהוא לא השפיע על הערך ב slice.

כפי שאתם רואים, ה slice מכסה לנו את ההתנהגות הכל-כך נדרשת של ArrayList.

איך מסירים איבר מ slice? הרי המערך הוא קבוע ורציף בזיכרון… הנה דוגמה:

1. הדרך להסיר איברים היא בעצם ליצור slice חדש, שיכיל פחות איברים.
   התחביר של … הוא expansion שהופך את ה slice לרשימה של פרמטרים – הצורה לה הפונקציה append מצפה.
2. אנו יכולים לראות שהפעולה הצליחה והמספר 10 נמחק מהרשימה.
   מדוע, אם כן, ל slice יש capacity של 4?
3. בגלל שפקודת append לא יצרה מערך חדש. היא בכלל לא מודעת לזה שביצענו מחיקה.
   כמו שראינו את הדוגמה הקודמת – הוספה של איבר ל slice מוסיף את הערך במקום הבא במערך – אם יש מקום לכך.

Structs

Struct הוא טיפוס מורכב להרכבה אישית. אם אנו מתארים Struct של אדם הוא יכול לכלול מחרוזת עם שם ושם משפחה, מספר זהות, ותאריך לידה.

אפשר לחשוב על Struct כאובייקט ללא מתודות – רק members.

1. אנו מגדירים struct חדש בעזרת המילים השמורות type ו struct. בניגוד לג'אווה או #C בהם מקובל ששם של טיפוס (מחלקה, struct ב #C) מתחיל באות גדולה, בשפת גו האות הגדולה מציינת האם הטיפוס הוא פרטי לחבילה (אות קטנה) או ציבורי (אות גדולה)
   1. בתוך ה struct אנו מגדירים את השדות (נקראים fields).
2. יש לנו 3 דרכים ליצור instance חדש של ה struct שהגדרנו
   1. ע״י שימוש ב var – ה struct יאותחל לערכי 0.
      שפת גו לא מגדירה אם בצורה זו האובייקט ייווצר על ה stack או על ה heap – זה פרט מימוש של הקומפיילר. בד״כ הקומפיילר יבצע תהליך שנקרא escape analysis ויראה אם יש חובה להגדיר את המופע, במקרה הספציפי, על ה heap. העדפת ברירת המחדל היא להגדיר אובייקטים על ה stack (מכיוון ששחרור הזיכרון הוא אפקטיבי יותר).
   2. ע״י שימוש במילה השמורה new, שיגרום ל:
      1. האובייקט ייווצר על ה heap. כל הערכים יאותחלו לערכי אפס.
      2. המשתנה sprite2 יכיל פויינטר לאובייקט, ולא את האובייקט עצמו.
   3. ע״י צורת ה shorthand של יצירה והשמת ערכים. בצורה זו אנו מציבים ערכים בעצמנו. כמו צורה #1 – אין הבטחה אם האובייקט ייווצר על ה stack או ה heap.

עניין של סגנון

• הקומפיילר ו gofmt (שאני מקווה שרוב ה IDEs עובדים איתה) – מכתיבים חלק גדול מהסגנון. רוצים סוגריים מסולסלים בשורה חדשה? – אין.
• שפת Go היא מינימליסטית: אין Generics, ואין Meta-programming – כלים שלרוב הם הבסיס ליצירת סגנונות בשפה (ע"י Frameworks, בד"כ). אין הורשה, אין מחלקות מקוננות, אין מחלקות אבסטרקטיות. בעצם: אין מחלקות. כל אלו, כלים שעוזרים להגדיר "DSL" על גבי השפה – ואין אותם ב Go.
• הספריות הסטנדרטיות של שפת גו מכסות מרחב גדול של נושאים, שלרוב מגיעים כספריות צד-שלישי: בדיקות (יחידה/אינטגרציה/APIs, ועוד), Templating, עבודה עם HTTP, שרת ווב, טיפול ב JSON/XML, ועוד.
  ספריות, ובעצם ה APIs שלהם – נוטים להכתיב חלק גדול מהסגנון הכתיבה שלנו. אם כולם משתמשים באותן ספריות – הקוד הוא יפה.

ניתן לראות תכונה זו של השפה כ"אובדן אינדוודואליזם", או מצד שני – כ"היופי שבפרגמטיות". כתיבת קוד שיהיה עקבי במערכת גדולה (גוגל) – היה אחת ממטרות השפה. אני באופן אישי, אוהב את ה trade-off שנלקח – ומעדיף שפה מגבילה, אך שמכתיבה סגנון אחיד.בכל זאת, יש כמה ענייני סגנון מקובלים ב Go, שאינם מוכתבים או אפילו מושפעים מהגורמים הנ"ל. זו הקהילה שמאמצת אותם. הנה כמה:

1. נהוג להשתמש בתחביר של if עם השמה מרובה, ובדיקת שגיאה  -באותה השורה. לרוב עבור טיפול בשגיאות.
2. מה שלא נהוג לעשות הוא להיכנס לקינון של if או בלוקים מסוג אחר. יש הרבה מפתחי ג'אווה שכותבים כך קוד – אז זה מצב לא רצוי ב Go.
3. מה שיש לחתור אליו הוא להישאר, עד כמה שאפשר, ברמת אינדנטציה מינימלית. זה אומר:
   1. לפצל פונקציות לפונקציות קטנות יותר.
   2. במקרה לעיל (#2) הסיבה לכתוב קוד בתוך ה else היה ה scope בו הוגדר המשתנה err. אין בעיה: ניתן להגדיר אותו ב scope רחב יותר – ואז להיפטר מהאינדנטציה הנוספת.
   3. עוד דבר שמצמצם את כמות שורות הקוד באינדנטציה במשפטי if הוא, לטפל קודם במקרה הפשוט (במקרה שלנו: return x – שורה אחת באינדנטציה), ואז במקרה המורכב יותר – מחוץ ל if (במקרה שלנו: הטיפול בשגיאה – 4 שורות שעכשיו אינן באינדנטציה).

הרעיון הזה הוא לא מקורי. הוא אפילו לא חדש: ניתן למצוא אותו בספר Code Complete (עליו כתבתי פוסט) שנכתב אי שם בשנות ה-90 המוקדמות. פשוט הקהילה של גו (כנראה בעקבות צורת הקוד בה כתובות הספריות של גו) – החליטה לאמץ אותו.

את ה import נהוג לסדר בקבוצות, שמפרידות ביניהן רווח – כאשר הקבוצה הראשונה היא של הספריות הסטנדרטיות:

לא מופרך להאמין שבגו תשתמשו ביחידות זמן שונות (שניות, מילי-שניות, ננו-שניות). במקום ליצור (קבוע?) עם ערך מספרי ושם או הערה שלא תסביר אותו היטב, יש בשפה טיפוס בשם time.Duration שהופך את ההגדרה להרבה יותר אלגנטית:

סיכום קצר

Go היא שפה פשוטה, אך ללמוד שפה בצורה מעמיקה זו לא משימה קצרה.
בפוסט זה כיסינו מבנים בסיסיים (לולאות, פונקציות, slices, ו structs), וגם דנו קצת בסגנון הכתיבה המקובל בשפת Go.
יש עוד כמה נושאים חשובים, אולי אמשיך אותם בפוסט המשך.

שיהיה בהצלחה!

—-

לינקים רלוונטיים

Slice Tricks in Go – לא ממש טריקים, אלא ריכוז הפעולות השונות על slices.

Best practices for a new Go developer – המלצות משורה של מתכנתים מנוסים ב Go, על מה כדאי לשים לב כשנכנסים לשפה. דוגמאות:

• אנשים חדשים נוטים לעשות overuse למודל ה concurrency של Go (כי הוא "כ'כ מגניב"?!).
• נסו להתמקד ולהבין את מודל ה interfaces לעומק – זה לב השפה (רלוונטי למי שלא הגיע מג'אווה או #C).
• השתמשו ב gofmt, כהרגל – כבר מההתחלה.

twelve Go best practices – גם נחמד

50 גוונים של Go – טעויות נפוצות של מתכנתים מתחילים בגו. מקום טוב ללמוד ממנו "פינות" של השפה.

Code Review Comments – מדריך לכתיבת הערות בגו

ברומא, התנהג כרומאי, Organizing Go Code, שפת גו – ל Gophers  – מצגות טובות על סגנון כתיבה מקובל בגו.

• אין מחלקות (אלא Structs עם מתודות "מקושרות")
• אין בנאים (constructors) – משתמשים במקום ב Factory methods
• אין הורשה (לא יחידה, לא מרובה)
• אין exceptions
• אין annotations
• אין Generics (לפחות לא כאלו שהמתכנת יכול להגדיר).
• יש צמצום בכלים של השפה, שיש להם תחליף (למשל יש for, אבל אין while…until).

• GOROOT – המצביע לתיקיה בה נמצא ה GO SDK
• GOPATH – המצביע למקום בו נמצא קוד ה GO.

רוב הניסיונות להתחכם, ולנהל קוד Go בתיקיות שונות במערכת – יסתיימו באכזבה (שלכם). הדרך היחידה המקובלת, שאני מכיר, לנהל את הקוד בתיקיות שונות הוא לייצר symbolic links תחת GOPATH לתיקיות בהן אתם רוצים לנהל את הקוד.

• src – התיקייה מתחתיה נמצא הקוד שלכם.
• pkg – התיקייה מתחתיה נמצאים package objects שמתארים את הקוד מצב הקוד המקומפל (כך שלא צריך לקמפל בשנית). כל צמד "מערכת הפעלה"_"ארכיטקטורת מעבד" מנוהל בתיקיה משלו.
• bin – התיקייה אליה נשלחים תוצרי הקומפליציה (קבצים בינאריים). הקומפילציה עצמה מתרחשת בתיקיה tmp של מערכת ההפעלה (התיקיה המדוייקת – תלוי במערכת ההפעלה).

כאשר נפעיל ב command line את הפקודה go install hello/web/server, הכלי לא ישאל היכן החבילה (package) נמצאת – הוא ימצא אותה בעצמו.

reference רלוונטי

1. בשפת Go, מגדירים משתנה בעזרת המילה השמורה var. קודם מופיע שם המשתנה –  ורק אז הטיפוס (הפוך מ Java או C – מה שמבלבל בהתחלה).
2. ניתן באותה השורה גם לאתחל ערך. אם לא מאתחלים ערך, הקומפיילר של Go יקבע "ערך אפס" (המספר 0 עבור מספר, nil עבור אובייקט, וכו')
3. בהשראת Python – מנסים ב Go לייתר הגדרות לא הכרחיות: אם אנו מציבים ערך ברור (במקרה שלנו: 1 שהוא int) אז הקומפיילר של Go יקבע את הטיפוס בעצמו ע"פ כללים מסוימים (במקרה שלנו: int).
4. ניתן באופן מקוצר לבצע כמה הגדרות של משתנים כ Grouping declaration.
5. בתוך פונקציה, הגדרת משתנה שלא בשימוש (במקרה שלנו: f) – היא שגיאת קומפילציה.
6. בתוך פונקציה, ניתן להשתמש בתחביר מקוצר =: המייתר את השימוש ב var, במידה ואנו מציבים ערך במשתנה.

1. ב Go אין casting אוטומטי של טיפוסים. חיבור של int ו float גורר שגיאת קומפילציה. הגישה של Go היא "אנחנו לא רוצים אקראיות – תגדיר בדיוק למה התכוונת". זו גישה מאוד בוגרת – לשפה "צעירה ומגניבה".
2. ניתן לבצע casting בקלות יחסית (הסוגריים הם על המשתנה ולא על הטיפוס – הפוך מג'אווה), ולקבל תוצאות בהתאם.
3. ישנם גם קבועים. הם דומים להגדרת משתנים ב var, אך לא ניתן להשתמש בתחביר המקוצר =:, וכמובן שלא ניתן לדרוס את הערך לאחר שהוגדר. נסיון לדרוס קבוע – מסתיים בשגיאת קומפליציה, כמובן.
4. אם אתם לא מעוניינים להשתמש כרגע במשתנה, אבל גם לא רוצים שגיאת קומפילציה – הציבו את ערך המשתנה בתוך ה blank identifier שהוא קו תחתון. ה blank identifier הוא משתנה לכתיבה בלבד, כאשר רוצים להיפטר מערך כלשהו. ממש כמו dev/null/ בלינוקס.

טיפול בסיסי במחרוזות

הנה כמה תכונות בשפה שבוודאי יקסמו למשתמשי פייטון (וגם לאחרים):

1. ניתן להגדיר טווח בסוגריים, בכדי לבצוע sub_string מתוך מחרוזת.
2. for … range הוא ה "foreach" של שפת גו. ניתן להשתמש ב range על מערך, slice (חלק ממערך), מחרוזת, map או channel (קונסטרנט לתקשורת בין goroutines, נגיע אליהן בהמשך).
   range בעצם מחזיר 2 ערכים: key ו value, מה שלא מוצג בדוגמה למעלה (יש שימוש רק ב key, שהוא האינדקס של ה char במחרוזת).
3. ב go יש שימוש נרחב ב Printf, לביצוע הדפסה עם formatting – ממש כמו בשפת C. הפקודה Printf מתחילה באות גדולה – מכיוון שהפונקציה היא public לחבילת "fmt". ניתן לגשת ל character במחרוזת בעזרת אינדקס (כמו שפות רבות אחרות).
4. איזה כיף! יש הגדרה של מחרוזת  multi-line!
   שימו לב ששורה 2 עד 4 יכילו מספר רווחים לפני הטקסט, כי העימוד מתחיל מעמודה 0 ולא מהעימוד של שורת הקוד הקודמת (התנהגות זהה לפייטון, אם אני זוכר נכון).

Result מרובה וטיפול בסיסי בשגיאות

האם הבחירות של שפת גו (טיפול בשגיאות, חוסר סלחנות על משתנים שלא בשימוש, וכו') היא ריאליזם בהתגלמותו (כי בסוף אנחנו מגיעים לשם בכל מקרה), או הגזמה? – קשה לומר עדיין. בפרספקטיבה של זמן, נוכל כנראה לומר.

יאללה כיף – goroutines

אם אתם מתעניינים בשפת גו, אתם בוודאי רוצים לדעת, ומהר – קצת יותר על תכונות ה concurrency שלה, שהן כ"כ מדוברות.

אני מניח שכולנו מכירים היטב את מודל ה Threads של שפת ג'אווה, ואולי אף את מודל ה Actors שבשימוש בשפת סקאלה. גו משתמשת במודל אחר.

טיפה רקע תיאורטי:

מודל ה goroutines של שפת גו הוא בעצם מימוש של רעיון שנקרא coroutines: הבסיס ל concurrency הוא פונקציות, ולא "אובייקטים פעילים" (כמו threads).
מודל המקביליות עצמו מתבסס על מודל ה Communicating Sequential Processes  (בקיצור CSP) של טוני אוהרה משנת 1978, שלא היה בשימוש נרחב עד שפת גו הציגה אותו כחלק מהשפה עצמה (ולא כספריה חיצונית).

המודל של Actors, המודל "של סקאלה" (בעצם Akka? או PID של שפת Erlang), הוא פרי עבודתו של קארל הייט מ1973.

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

חזרה לת'כלס:

ה goroutines של שפת גו הם בעצם סוג של Green-threads, נימים (threads) המנוהלים ע"י סביבת הריצה או ה VM – ולא ע"י מערכת ההפעלה.
יתרה מכך: greenthreads לא משתמשים באף מנגנון של מערכת ההפעלה. כל הניהול הוא אפליקטיבי ומתרחש ב user space (ללא context switch ל kernel).

• green threads הם מהירים יותר ליצירה, לתזמון, ולסנכרון. עבודת CPU תהיה לרוב יעילה משמעותית יותר איתם, מאשר עם native threads.
• צריכת הזיכרון של green threads יכולה להיות משמעותית קטנה (בשפת go, ה stack ההתחלתי של goroutine הוא 2KB זכרון, מול 1MB ב thread של מערכת ההפעלה) – מה שמאפשר להחזיק הרבה מאוד goroutines במקביל.
• כאשר מדובר בהרבה פעולות I/O, דווקא native threads נוטים להיות יותר יעילים.
• green threads לא יכולים להשתמש בריבוי מעבדים, וזה כולל את יכולת ה Hyper-Threading של אינטל, שמדמה מעבדים וירטואליים.
• כאשר / אם green thread מבצע פעולת blocking ברמת מערכת ההפעלה (ולא הדמיה שלה סינכרוניות ברמת סביבת הריצה), לא רק ה green thread נחסם – אלא נחסם ה thread של מערכת ההפעלה עד סיום פעולת ה I/O (שכעת לא יכול לתזמן green threads אחרים). לשפת Go ספציפית יש ייתרון שהיא חדשה, ותוכננה לתסריט זה. היא לא מספקת גישה לקריאות blocking I/O (אולי רק ממשק שנראה שכזה) כמו שפות קיימות (למשל ג'אווה) – ולכן זה עניין שהתמכנת לא צריך לדאוג לו.

בואו נראה קצת קוד:

התוכנית שלנו קוראת ל-2 פונקציות: printHello ו printWorld.

1. בשלב זה אנו קוראים ל printWorld, אבל שימו לב למילה השמורה go: היא גורמת לפונקציה הרגילה לגמרי לרוץ כ goroutine על greenthread של סביבת הריצה של גו!
   קרוב לוודאי שיש קשר חזק בין שם השפה – לשם המילה השמורה go.
2. הפונקציה (שרצה ב greenthread נפרד) תמתין עכשיו כ 2 שניות. זה לא יפריע לשאר התוכנית להמשיך ולרוץ.
   לאחר ההמתנה היא תדפיס את הטקסט "!World".
3. בזמן ש printWorld ממתינה, אנו קוראים לפונקציה printHello, גם כ goroutine.
   יכולתי להגדיר את printHello כעוד פונקציה של ה package, אבל חבל לי להעמיס על המרחב הציבורי עבור פונקציה של שורה אחת.
   למה אני זקוק לעוד פונקציה עבור שורת קוד בודדה? כי אני רוצה להריץ אותה כ goroutine, כמובן!
   1. שפת גו מאפשרת להגדיר פונקציה ולהריץ אותה מיד, בעזרת כתיבת סוגריים מיד לאחר הגדרת הפונקציה – ממש כמו בשפת javaScript.
      זה התרגיל שעשיתי – ואני מקווה שלא הקשיתי מדי לעקוב (אני גם לא רוצה לשעמם…)
4. פה יש קטע: מכיוון ש printHello ו printWorld רצות במקביל כ goroutines, הפונקציה main הגיעה לסופה – מה שיגרום לתוכנה להסתיים, ולא אוכל לראות את הפלט של התוכנית.
   אני יוצר המתנה יזומה של 3 שניות בפונקציה main (שלצורך העניין היא goroutine בפני עצמה), בכדי לתת דיי זמן ל printHello ו printWorld להתבצע בבטחה.

1. אנו יוצרים אובייקט מסוג WaitGroup שיקרא מעתה "המוניטור" (ע"ש דפוס העיצוב)
2. אנו מודיעים למוניטור שתנאי הסיום שלו הוא 2 הודעות Done.
3. כל אחת מהפונקציות printHello ו printWorld יודיעו למוניטור כשהן סיימו.
   אנו כמובן עושים זאת בדרך של גו: בעזרת המילה השמורה defer – שמבטאת רעיון יפה מאוד:
   התפקיד של defer היא כמו finally בשפת ג'אווה – לבצע דברים בסיום ההרצה של הפונקציה, גם במקרה סיום תקין וגם במקרה של סיום עם שגיאה.
   נקודת חולשה של finally היא שההקשר הסיבתי אבד: כל הפעולות שיש לבצע ביציאה מהפונקציה מרוכזות בבלוק ה finally ללא קשר ממה הן נובעות. הפקודה defer מאפשרת לנו להכריז על הפעולה שיש לבצע בעת יציאה מהפונקציה – בהקשר שקל להבין. ניתן לקרוא ל defer בכל מקום בפונקציה, והפעולה תמיד תרשם לזמן היציאה מהפונקציה. ממש יפה!
4. אנו אומרים למוניטור להמתין לתנאי הסיום שלו.

בפוסט המשך, אמשיך ואצלול לתוך השפה.

שיהיה בהצלחה!