כתבה ראשונה בסדרה
לא משנה איפה אתם - אתם צריכים Golang
כל מי שעוסק היום בענן (ולא חשוב אם זה במכולות או ב-Serverless), לא יכול להתעלם משפת Golang. במאמר זה, אנסה להסביר למה.
קהל היעד של הכתבה הזו היא כל מי שבאחריותו להחליט על התשתית שאיתה יפותח פרויקט התוכנה (או לצורך העניין, חלקים מהפרויקט) ולא משנה לצורך העניין מה סוג היישום (שולחני או ענני), באיזו פלטפורמה הוא ירוץ (שרת, מחשב שולחני או טלפון) או על איזו מערכת הפעלה (מק, חלונות, לינוקס וכו').
כן, אני יודע, Portability או בניסוח אחר "קודד פעם אחת ותריץ איפה שאתה רוצה" זה החלום הרטוב של תעשיית התכנה כבר הרבה שנים. וכן, אני רואה רבים מכם מגלגלים עיניים מפני שבדרך כלל יש לחלום הזה מחיר יקר בהטמעה, הנובע מהצורך להתקין סביבת ריצה מתאימה (java, .NET וכו') ומחיר יקר בביצועים, הנובע מהצורך בהוספת של שכבת ההפשטה המתחייבת. אבל Portability זה בכלל לא הסיבה העיקרית ש-Go (או בשמה המלא Golang) היא כרגע אחד הנושאים החמים ביותר בתעשיית התוכנה. למעשה, זהו רק אחד מתוצרי הלואי.
האם אתם משתמשים ב-Kubernetes בארגון שלכם? אם אתם בעולם המכולות והמיקרו שירותים, סביר להניח שכן. Kubernetes הינה חבילת תכנה כבדה עם הרבה שורות קוד, והיא מאד נפוצה בשטח. טריוויה קצרה: Kubernetes כתובה ב-Go!
זו לא הדוגמא היחידה. גוגל משתמשת ב-Go בלב של מנוע החיפוש שלה. חברות כמו uber, Airbnb, Spotify, Twitch ועוד רבות אחרות אימצו את Go. אז אם אתם מחפשים את המכנה המשותף לכל הפרויקטים והחברות האלה, הדבר הראשון שיקפוץ לכם לעין, זה הצורך בביצועים: מסתבר ש-Go מספקת קוד מכונה Native יעיל ומהיר שמתקרב בביצועים שלו לרמת הביצועים של קוד באסמבלר, וזאת מבלי לאבד את האלמנטים הנדרשים של שפה עילית.
ישנו קשר הדוק בין אורך הקומפילציה וזמן ה-Build לתפוקה של המתכנתים. ככל שזמן הקומפילציה גדל, קצב ההתקדמות של התכנת המקודד הופך לאיטי יותר ולא רק בגלל הזמן שלוקחת הקומפילציה, אלא בעיקר בגלל שבזמן ההמתנה לקומפיילר, המפתח יוצא מה Zone, מאבד ריכוז ומוסט לדברים אחרים - מה שגורם לכך שזמן הכניסה מחדש ל"ראש" של הפרויקט, הוא ברוב המקרים הרבה יותר משמעותי מזמן הקומפילציה נטו. אז כדאי לדעת ש-Go מקמפל מהר מאד, ולמעשה, אחת המוטיבציות ליצירת השפה הייתה הזמן הארוך מדי של כל תהליך ה-Build בגוגל, שהציק מאד ליוצרי השפה. במקום לקטר על זה במפגש הפיצוחים השבועי, הם החליטו לעשות משהו עם זה.
הפסקה שהולכת לעצבן לא מעט אנשים
אני יודע שהרבה מהקוראים של הקטע הבא יתחילו להשתולל ולשלוח בי אש וגופרית, אבל Object Oriented זה דבר רע מאד (ואני מוכן להתייחס במאמר נפרד לנושא הזה ולהוכיח ש-Object Oriented מעולם לא סיפק את ההבטחות שלו לתעשייה), בעיקר בגלל הנימוק הפשוט שהוא יותר מדי Coupled ומאפשר לך לדעת יותר ממה שבריא על האובייקטים מהם אתה יורש ובהם אתה משתמש.
הכיוון הנכון הוא Interface Oriented, שיוצר הפרדה מוחלטת וברורה בין שתי יחידות קוד שאמורות לתקשר אחת עם השנייה. אז Go הוא לא Object Oriented, אבל הוא תומך בצורה מלאה ב-Interfaces, כאשר הקישור הוא Implied ולא דורש הכרזה מראש. זוהי נקודת חוזק לכל מי שצריך לתכנן ארכיטקטורה של פרויקט תכנה, כי הוא מספק הגנה די טובה בפני עקיפות וביזוי בדרכים אחרות של הארכיטקטורה.
שפת Golang אמנם צעירה, אבל לא באמת חדשה. העבודה עליה החלה כבר ב-2009, והגרסה הרשמית יצאה ב2014, כך שניתן לומר ש-Golang כבר יצאה משלב ה-Hype והיא כבר בשלב הבשלות. השפה מתפשטת בקצב מהיר, נמצאת בשימוש בהרבה פרויקטים גדולים וקטנים שעובדים בפועל בשטח, כך שלא מדובר פה על שפה אקדמית לעבודות דוקטורט בלבד. מה שאומר שכל מי שמעדיף לחכות שתי גרסאות לפני שהוא מכניס את הראש למים, כבר יכול לחוש די בטוח להכניס את האצבעות ולבדוק מה הטמפרטורה של המים.
הפרויקט של Golang הוא פרויקט קוד פתוח, עם רישיון מאד ליבראלי, שמאפשר לעשות איתו פחות או יותר מה שרוצים, גם בפרויקטים מסחריים. אבל מאחר ואתה בדרך כלל משתמש רק בתוצר הבינרי הסופי של הקומפילציה, כל נושא הרישוי לא באמת משמעותי. מצד שני, יש לך גישה כשצריך לקוד המקור, ואם אתה נתקל במשהו לא ברור, אתה תמיד יכול להסתכל על קוד המקור.
אתה כמובן יותר ממוזמן להצטרף לקבוצות הדיון ולתרום קוד לקהילה, אבל לזה כמובן, אף פעם אין זמן. מצד שני, כדאי לקחת בחשבון, שמעורבות בקהילה תורמת בעיקר לידע שלכם. אז אולי כן כדאי לך להקדיש לזה זמן. עד כאן פרסומת חינם לקהילת הקוד הפתוח.
המקום שבו Go ממש מצטיינת בו הוא נושא ה-Concurrency. יש לשים לב ש Concurrency זה לא Parallelism, וזו אבחנה חשובה שאתייחס אליה באחד המאמרים הבאים. העולם שלנו הוא מרובה יחידות עיבוד, ופיזור נכון (הדגש הוא על נכון) של יחידות העבודה והמשימות, בין יחידות העיבוד השונות, יאפשר שיפור משמעותי בביצועים.
כמה פשוט, כמה טוב
כמובן שכל מי שנכנס לעולם מרובה המעבדים, נתקל מיד בבעיות של סינכרון בין תהליכים, Deadlocks ומירוצים קריטיים. הפתרון של Go לכל הבעיות האלה מבוסס על מודל שנקרא Communicating Sequential Processes, המאפשר לנהל ולתקשר בין תהליכים שרצים במקביל בצורה קלה ופשוטה ובמינימום נעילות. הטכניקה הזו עוקפת הרבה מהבעיות שמפתחים נתקלים בהם בעיבוד בו זמני, וגם מאפשרת לגלות מהר מאד (לפעמים כבר בשלב הקומפילציה) בעיות של Dead locks ומרוצים קריטיים.
לגבי ההורים. השפה נוצרה על ידי Robert Griesemer, Rob Pike ו-Ken Thompson, אשר לכל אחד מהם ישנו מקום של כבוד בעולם פיתוח התכנה. Ken ו Rob נמצאים בעולם התכנה הרבה מאד זמן. הם היו שם, בשנות השישים, כשהכל התחיל, עם עישון הגראס במעבדות בל. הם עבדו שם ביחד עם Kernighan ו-Ritchie, כשנולדה Unix ושפת C. אמנם רוברט צעיר יותר, אבל גם הוא עם מספיק ותק בעולם התכנה כדי להבחין בין טוב לרע.
באחת ההמתנות הארוכות לקומפילציה בגוגל, הם שאלו את עצמם למה זה לוקח כל כך הרבה זמן, ולשם שינוי בחרו לחקור את הנושא גם מהזווית התיאורטית. אחד מהדברים שהם גילו, זה ששפות התכנות הולכות ומסתבכות ויש מרוץ מטורף בין השפות השונות, מי נותנת יותר Features ויותר Syntactic Suger. המרוץ הזה גורם לכך שמצד אחד, כל השפות נהיות דומות אחת לשנייה, אבל מצד שני, הם מסבכות את הקומפיילרים. לכן, קומפיילר כיום עובד הרבה יותר קשה וקומפילציה לוקחת הרבה יותר זמן ממה שהיה בעבר.
מסתבר, שלהתקדמות המופרעת של השפות במרוץ המטורף אחר ה-Features, יש תוצר לוואי הרבה יותר משמעותי מאשר זמן הקומפילציה" זמן הלימוד של המתכנת לשליטה בשפה נהיה ארוך יותר. יעילות הפיתוח של המתכנת נפגמת משמעותית, בגלל שמרוב אפשרויות לוקח לו יותר זמן לבחור את האפשרות הטובה ביותר מבין אופציות שאין ביניהם הבדל משמעותי. בקיצור, מרוב אפשרויות לא רואים את היער. מה שיותר גרוע הוא שניתוח של קוד קיים לאיתור בעיות או לצורך Code review נהיה מורכב יותר ולוקח יותר זמן - שוב פגיעה ביעילות. אז Go נותנת לזה תשובה טובה.
לכל רשימת יתרונות יש גם חסרונות
עם כל הדברים הטובים הללו, חייב לבוא גם מחיר - לא יכול להיות שהכל כל כך טוב. אז נכון, יש לשימוש ב-Golang מחיר: אתם צריכים לכתוב קוד נקי, פשוט וברור. אתם צריכים לכתוב בדיוק את מה שאתה רוצים שיתבצע, בלי כל מיני צעצועי תחביר וסוכריות. אני יודע שחלק מכם מרימים גבה ושואלים למה זה דבר כל כך רע, כי זה בעצם מה שכל מנהל של פרויקט תכנה חולם שהמפתחים שלו יעשו – אבל זוהי בדיוק הבעיה.
אין בשפה אף Feature מיותר. כל אחת מהיכולות שיש בשפה נבחנה על ידי שלושת היוצרים לאור ניסיון החיים שלהם, ורק יכולת ששלושתם הסכימו בצורה מלאה שהיא משהו הכרחי נכנסה לשפה. השלישיה בוחנת כל הצעה להוספת Feature בזכוכית מגדלת והם מאד קמצנים בתוספות של כאלו חדשים. זה נותן אחידות, תקניות ובהירות אבל יש לזה מחיר שהמפתח צריך לנסח את הבעיות שלו בצורה ישירה וברורה.
אז למה זה רע? כי זה גורם מידית להתנגדות אצל ה-Code monkeys, בגלל שלוקחים להם את הצעצועים. נדרשת כאן מנהיגות של ראש הצוות ו/או הארכיטקט ולפעמים גיבוי של ההנהלה, על מנת להתחיל להזיז את המערכת. מה שמקל על המעבר, הוא שעקומת הלימוד של השפה היא מאד קלה: אפשר לשלב אותה במקטעים, בעיקר בארכיטקטורות מבוזרות ולאחר שמתגברים על החיכוך הראשוני ורואים את העוצמה, בדרך כלל ההתנגדות פוחתת ללא יותר מקיטור שבועי על מתי יכניסו את ה-Feature האהוב עליי (אף פעם) ועל החיים הנוחים שהיו לנו פעם, כשיכולנו להשמיד ביצועים של מערכת, בשורה אחת של קוד מצופה ב-Syntactic Sauger.
לסיכום
בינתיים עד למאמר הבא, אני ממליץ לגשת לאתר של golang.org, להתרשם ממבחר הפלטפורמות, להוריד את קבצי ההתקנה ולהתחיל לשחק. רק מילת אזהרה: במבט ראשון, השפה נראית קלה ללימוד ואת כל נושא ה-Syntax ניתן לחסל תוך פחות מיומיים. אבל כפי שכבר אמר מישהו, "With great power comes great responsibility." מה שייקח לכם יותר זמן ולימוד, הוא הנושא של איך להשתמש נכון בשפה, ואיך לא לבזות את היכולות החזקות שלה.
מאת: גד מאיר, מנהל מו"פ בידאג בע"מ
כתבה ראשונה בסדרה
לא משנה איפה אתם - אתם צריכים Golang
כל מי שעוסק היום בענן (ולא חשוב אם זה במכולות או ב-Serverless), לא יכול להתעלם משפת Golang. במאמר זה, אנסה להסביר למה.
קהל היעד של הכתבה הזו היא כל מי שבאחריותו להחליט על התשתית שאיתה יפותח פרויקט התוכנה (או לצורך העניין, חלקים מהפרויקט) ולא משנה לצורך העניין מה סוג היישום (שולחני או ענני), באיזו פלטפורמה הוא ירוץ (שרת, מחשב שולחני או טלפון) או על איזו מערכת הפעלה (מק, חלונות, לינוקס וכו').
כן, אני יודע, Portability או בניסוח אחר "קודד פעם אחת ותריץ איפה שאתה רוצה" זה החלום הרטוב של תעשיית התכנה כבר הרבה שנים. וכן, אני רואה רבים מכם מגלגלים עיניים מפני שבדרך כלל יש לחלום הזה מחיר יקר בהטמעה, הנובע מהצורך להתקין סביבת ריצה מתאימה (java, .NET וכו') ומחיר יקר בביצועים, הנובע מהצורך בהוספת של שכבת ההפשטה המתחייבת. אבל Portability זה בכלל לא הסיבה העיקרית ש-Go (או בשמה המלא Golang) היא כרגע אחד הנושאים החמים ביותר בתעשיית התוכנה. למעשה, זהו רק אחד מתוצרי הלואי.
האם אתם משתמשים ב-Kubernetes בארגון שלכם? אם אתם בעולם המכולות והמיקרו שירותים, סביר להניח שכן. Kubernetes הינה חבילת תכנה כבדה עם הרבה שורות קוד, והיא מאד נפוצה בשטח. טריוויה קצרה: Kubernetes כתובה ב-Go!
זו לא הדוגמא היחידה. גוגל משתמשת ב-Go בלב של מנוע החיפוש שלה. חברות כמו uber, Airbnb, Spotify, Twitch ועוד רבות אחרות אימצו את Go. אז אם אתם מחפשים את המכנה המשותף לכל הפרויקטים והחברות האלה, הדבר הראשון שיקפוץ לכם לעין, זה הצורך בביצועים: מסתבר ש-Go מספקת קוד מכונה Native יעיל ומהיר שמתקרב בביצועים שלו לרמת הביצועים של קוד באסמבלר, וזאת מבלי לאבד את האלמנטים הנדרשים של שפה עילית.
ישנו קשר הדוק בין אורך הקומפילציה וזמן ה-Build לתפוקה של המתכנתים. ככל שזמן הקומפילציה גדל, קצב ההתקדמות של התכנת המקודד הופך לאיטי יותר ולא רק בגלל הזמן שלוקחת הקומפילציה, אלא בעיקר בגלל שבזמן ההמתנה לקומפיילר, המפתח יוצא מה Zone, מאבד ריכוז ומוסט לדברים אחרים - מה שגורם לכך שזמן הכניסה מחדש ל"ראש" של הפרויקט, הוא ברוב המקרים הרבה יותר משמעותי מזמן הקומפילציה נטו. אז כדאי לדעת ש-Go מקמפל מהר מאד, ולמעשה, אחת המוטיבציות ליצירת השפה הייתה הזמן הארוך מדי של כל תהליך ה-Build בגוגל, שהציק מאד ליוצרי השפה. במקום לקטר על זה במפגש הפיצוחים השבועי, הם החליטו לעשות משהו עם זה.
הפסקה שהולכת לעצבן לא מעט אנשים
אני יודע שהרבה מהקוראים של הקטע הבא יתחילו להשתולל ולשלוח בי אש וגופרית, אבל Object Oriented זה דבר רע מאד (ואני מוכן להתייחס במאמר נפרד לנושא הזה ולהוכיח ש-Object Oriented מעולם לא סיפק את ההבטחות שלו לתעשייה), בעיקר בגלל הנימוק הפשוט שהוא יותר מדי Coupled ומאפשר לך לדעת יותר ממה שבריא על האובייקטים מהם אתה יורש ובהם אתה משתמש.
הכיוון הנכון הוא Interface Oriented, שיוצר הפרדה מוחלטת וברורה בין שתי יחידות קוד שאמורות לתקשר אחת עם השנייה. אז Go הוא לא Object Oriented, אבל הוא תומך בצורה מלאה ב-Interfaces, כאשר הקישור הוא Implied ולא דורש הכרזה מראש. זוהי נקודת חוזק לכל מי שצריך לתכנן ארכיטקטורה של פרויקט תכנה, כי הוא מספק הגנה די טובה בפני עקיפות וביזוי בדרכים אחרות של הארכיטקטורה.
שפת Golang אמנם צעירה, אבל לא באמת חדשה. העבודה עליה החלה כבר ב-2009, והגרסה הרשמית יצאה ב2014, כך שניתן לומר ש-Golang כבר יצאה משלב ה-Hype והיא כבר בשלב הבשלות. השפה מתפשטת בקצב מהיר, נמצאת בשימוש בהרבה פרויקטים גדולים וקטנים שעובדים בפועל בשטח, כך שלא מדובר פה על שפה אקדמית לעבודות דוקטורט בלבד. מה שאומר שכל מי שמעדיף לחכות שתי גרסאות לפני שהוא מכניס את הראש למים, כבר יכול לחוש די בטוח להכניס את האצבעות ולבדוק מה הטמפרטורה של המים.
הפרויקט של Golang הוא פרויקט קוד פתוח, עם רישיון מאד ליבראלי, שמאפשר לעשות איתו פחות או יותר מה שרוצים, גם בפרויקטים מסחריים. אבל מאחר ואתה בדרך כלל משתמש רק בתוצר הבינרי הסופי של הקומפילציה, כל נושא הרישוי לא באמת משמעותי. מצד שני, יש לך גישה כשצריך לקוד המקור, ואם אתה נתקל במשהו לא ברור, אתה תמיד יכול להסתכל על קוד המקור.
אתה כמובן יותר ממוזמן להצטרף לקבוצות הדיון ולתרום קוד לקהילה, אבל לזה כמובן, אף פעם אין זמן. מצד שני, כדאי לקחת בחשבון, שמעורבות בקהילה תורמת בעיקר לידע שלכם. אז אולי כן כדאי לך להקדיש לזה זמן. עד כאן פרסומת חינם לקהילת הקוד הפתוח.
המקום שבו Go ממש מצטיינת בו הוא נושא ה-Concurrency. יש לשים לב ש Concurrency זה לא Parallelism, וזו אבחנה חשובה שאתייחס אליה באחד המאמרים הבאים. העולם שלנו הוא מרובה יחידות עיבוד, ופיזור נכון (הדגש הוא על נכון) של יחידות העבודה והמשימות, בין יחידות העיבוד השונות, יאפשר שיפור משמעותי בביצועים.
כמה פשוט, כמה טוב
כמובן שכל מי שנכנס לעולם מרובה המעבדים, נתקל מיד בבעיות של סינכרון בין תהליכים, Deadlocks ומירוצים קריטיים. הפתרון של Go לכל הבעיות האלה מבוסס על מודל שנקרא Communicating Sequential Processes, המאפשר לנהל ולתקשר בין תהליכים שרצים במקביל בצורה קלה ופשוטה ובמינימום נעילות. הטכניקה הזו עוקפת הרבה מהבעיות שמפתחים נתקלים בהם בעיבוד בו זמני, וגם מאפשרת לגלות מהר מאד (לפעמים כבר בשלב הקומפילציה) בעיות של Dead locks ומרוצים קריטיים.
לגבי ההורים. השפה נוצרה על ידי Robert Griesemer, Rob Pike ו-Ken Thompson, אשר לכל אחד מהם ישנו מקום של כבוד בעולם פיתוח התכנה. Ken ו Rob נמצאים בעולם התכנה הרבה מאד זמן. הם היו שם, בשנות השישים, כשהכל התחיל, עם עישון הגראס במעבדות בל. הם עבדו שם ביחד עם Kernighan ו-Ritchie, כשנולדה Unix ושפת C. אמנם רוברט צעיר יותר, אבל גם הוא עם מספיק ותק בעולם התכנה כדי להבחין בין טוב לרע.
באחת ההמתנות הארוכות לקומפילציה בגוגל, הם שאלו את עצמם למה זה לוקח כל כך הרבה זמן, ולשם שינוי בחרו לחקור את הנושא גם מהזווית התיאורטית. אחד מהדברים שהם גילו, זה ששפות התכנות הולכות ומסתבכות ויש מרוץ מטורף בין השפות השונות, מי נותנת יותר Features ויותר Syntactic Suger. המרוץ הזה גורם לכך שמצד אחד, כל השפות נהיות דומות אחת לשנייה, אבל מצד שני, הם מסבכות את הקומפיילרים. לכן, קומפיילר כיום עובד הרבה יותר קשה וקומפילציה לוקחת הרבה יותר זמן ממה שהיה בעבר.
מסתבר, שלהתקדמות המופרעת של השפות במרוץ המטורף אחר ה-Features, יש תוצר לוואי הרבה יותר משמעותי מאשר זמן הקומפילציה" זמן הלימוד של המתכנת לשליטה בשפה נהיה ארוך יותר. יעילות הפיתוח של המתכנת נפגמת משמעותית, בגלל שמרוב אפשרויות לוקח לו יותר זמן לבחור את האפשרות הטובה ביותר מבין אופציות שאין ביניהם הבדל משמעותי. בקיצור, מרוב אפשרויות לא רואים את היער. מה שיותר גרוע הוא שניתוח של קוד קיים לאיתור בעיות או לצורך Code review נהיה מורכב יותר ולוקח יותר זמן - שוב פגיעה ביעילות. אז Go נותנת לזה תשובה טובה.
לכל רשימת יתרונות יש גם חסרונות
עם כל הדברים הטובים הללו, חייב לבוא גם מחיר - לא יכול להיות שהכל כל כך טוב. אז נכון, יש לשימוש ב-Golang מחיר: אתם צריכים לכתוב קוד נקי, פשוט וברור. אתם צריכים לכתוב בדיוק את מה שאתה רוצים שיתבצע, בלי כל מיני צעצועי תחביר וסוכריות. אני יודע שחלק מכם מרימים גבה ושואלים למה זה דבר כל כך רע, כי זה בעצם מה שכל מנהל של פרויקט תכנה חולם שהמפתחים שלו יעשו – אבל זוהי בדיוק הבעיה.
אין בשפה אף Feature מיותר. כל אחת מהיכולות שיש בשפה נבחנה על ידי שלושת היוצרים לאור ניסיון החיים שלהם, ורק יכולת ששלושתם הסכימו בצורה מלאה שהיא משהו הכרחי נכנסה לשפה. השלישיה בוחנת כל הצעה להוספת Feature בזכוכית מגדלת והם מאד קמצנים בתוספות של כאלו חדשים. זה נותן אחידות, תקניות ובהירות אבל יש לזה מחיר שהמפתח צריך לנסח את הבעיות שלו בצורה ישירה וברורה.
אז למה זה רע? כי זה גורם מידית להתנגדות אצל ה-Code monkeys, בגלל שלוקחים להם את הצעצועים. נדרשת כאן מנהיגות של ראש הצוות ו/או הארכיטקט ולפעמים גיבוי של ההנהלה, על מנת להתחיל להזיז את המערכת. מה שמקל על המעבר, הוא שעקומת הלימוד של השפה היא מאד קלה: אפשר לשלב אותה במקטעים, בעיקר בארכיטקטורות מבוזרות ולאחר שמתגברים על החיכוך הראשוני ורואים את העוצמה, בדרך כלל ההתנגדות פוחתת ללא יותר מקיטור שבועי על מתי יכניסו את ה-Feature האהוב עליי (אף פעם) ועל החיים הנוחים שהיו לנו פעם, כשיכולנו להשמיד ביצועים של מערכת, בשורה אחת של קוד מצופה ב-Syntactic Sauger.
לסיכום
בינתיים עד למאמר הבא, אני ממליץ לגשת לאתר של golang.org, להתרשם ממבחר הפלטפורמות, להוריד את קבצי ההתקנה ולהתחיל לשחק. רק מילת אזהרה: במבט ראשון, השפה נראית קלה ללימוד ואת כל נושא ה-Syntax ניתן לחסל תוך פחות מיומיים. אבל כפי שכבר אמר מישהו, "With great power comes great responsibility." מה שייקח לכם יותר זמן ולימוד, הוא הנושא של איך להשתמש נכון בשפה, ואיך לא לבזות את היכולות החזקות שלה.
מאת: גד מאיר, מנהל מו"פ בידאג בע"מ
לפרטים נוספים ויצירת קשר עם נציג אורקל
הודעתך לא התקבלה - נסה שוב מאוחר יותר