האם ה-open source הוא המטאור שיכחיד את מיקרוסופט?
רון קליין עבר מפיתוח ב-DotNet לפייתון בסביבת לינוקס. שנתיים אחרי הוא מספר על ההבדלים, התובנות שצבר ועל הכיוון שאליו מיקרוסופט הולכת. ספוילר: זה לא ייגמר בטוב
מקור: עיבוד תמונה
מאת רון קליין, מפתח תוכנה בכיר
אחרי שהצהרתי בעבר שאני עובר לתכנת בפייתון, הגיע הזמן לחלוק כמה תובנות. בפוסט הזה אני אחלוק דברים שדווקא קשורים לשפת פייתון עצמה, אלא יותר למאקרו: המעבר מפיתוח בסביבת Microsoft, כלומר דוט-נט על Windows, לפיתוח בסביבת open-source: כיום אני מפתח בפייתון וב Clojure על לינוקס. הפוסט הזה הוא (גם) סוג של תגובה לפוסט של עופר שמציג התלבטות בין הפיתוח בסביבת דוט-נט לבין פיתוח בשפות open-source כמו פייתון, רובי וכד'. בלי קשר לידידות ארוכת השנים שיש לי עם עופר, אני ממליץ בחום לקרוא את הפוסט, שמסכם בצורה טובה מאוד את הלך הרוח שמתקיים בקרב מתכנתים רבים בסביבת Microsoft. גם התגובות לפוסט ממחישות יפה את ההתלבטות.
TL;DR
החזית הטכנולוגית נמצאת בסביבת open-source. הנוחות נמצאת בסביבות אחרות, כמו דוט-נט. ויש לזה סיבה. הכנתם קפה? יפה. נתחיל.
באופן כללי, אחרי יותר משנתיים בסביבת open-source, אני חושב שבסביבה הזו אפשר לראות באופן בולט שני דברים חשובים: מענה אמיתי לבעיות אמיתיות ופתרונות חדשניים לבעיות אמיתיות.
העולם הישן – פתרונות עקומים לבעיות אמיתיות
הצורך הוא אבי ההמצאה. אבל מהו הצורך? מי מגדיר מהו הצורך?
בפיתוח בסביבה סגורה (כלומר לא פתוחה לשינויים), כמו בסביבת Microsoft, מי שמגדיר את הצורך הוא מספר מצומצם של מהנדסים, שיושבים וחושבים מהו הצורך הנוכחי ומה יהיה הצורך הבא, ואיך ניתן יהיה לספק את תשתית הפיתוח למתכנתים בצורה הטובה ביותר. אבל בסופו של דבר זה מספר מצומצם של מהנדסים, והם לא יכולים לנחש ולעלות על כל היבט אפשרי. נסתכל לרגע על בעיה ידועה: איך אפשר לפתח ל-web בצורה מהירה וקלה לתחזוקה?
הפתרון של Microsoft
בואו נצעד אחורה בזמן לתקופה של 2002-2003, כאשר Microsoft הכריזו בקול גדול על דוט-נט (עזבו את 1.0, נלך ישר ל 1.1), ובפרט על ASP.NET עם הפיצ'ר המדהים שנקרא WebForms. על איזה צורך ענה כל הנושא הזה של WebForms ב-ASP.NET?
מהנדסי Microsoft חשבו וחשבו, וחשבו עוד קצת, והגיעו למסקנה שמתכנתי web צריכים לאמץ שיטות פיתוח של מתכנתי desktop, כלומר "לצייר" ב-Visual Studio אלמנטים ע"י drag-and-drop, והכל בסוף יתורגם ל-HTML. אה, והלהיט הגדול: התוצאה הסופית תיקבע על פי הדפדפן עצמו (לפי ה user-agent), כי ככה נוכל לעצב פעם אחת את המסכים שלנו והשרת ייצור HTML (או WML, למי שהתנסה בזה) שמותאם לדפדפן הנוכחי.
על כל זה אוכל לומר: כוונות טובות. אבל בפועל, הרבה מתכנתים אכלו הרבה חצץ (ואני בוחר בקפידה את המילים כאן) כדי להשתלב ב"ספינת הדגל" החדשה שנקראת WebForms. לקח לנו לא מעט זמן להבין שזה מודל עם יותר חסרונות מאשר יתרונות, ולהרים קול בעניין. בקיצור, Microsoft סיפקו פתרון עקום לבעיה אמיתית.
הפתרונות מעולם ה open-source
המודל שמתכנתי web מעדיפים הוא בדרך כלל מודל פיתוח שנקרא MVC. בסביבת הקוד הפתוח זה מודל שמוכר ועובד היטב כבר שנים:
- בפייתון יש מספר פרויקטים, והמוכר שבהם נקרא Django, שקיים מ-2005.
- ברובי יש את Rails, שקיים מ-2005.
- ב PHP יש את CakePHP שקיים מ-2005.
- בדוט-נט, בסביבת open-source:
- פרויקט MonoRail, שהוא תת-פרויקט של Castle. קיים בערך מ-2005-2006. נוהל במשך תקופה ארוכה ע"י חן אגוזי.
- פרויקט ASP.NET MVC, התחיל בסביבות 2007 ע"י Scott Guthrie, וצבר תאוצה די מהר.
ובינתיים, במשרדי Microsoft, אי שם ברדמונד
מה קרה בינתיים, בתקופה של 2005-2010? בתקופה הזו, Microsoft התעלמו לחלוטין ממודל MVC לפיתוח web, לפחות כלפי חוץ. רק בסביבות 2010 "אומץ" פרויקט ASP.NET MVC על-ידי Microsoft והפך להיות חלק מ Visual Studio, בתור תוסף. רק ב 2012, הטמיעה Microsoft באופן רשמי פרוייקטים מסוג MVC ב Visual Studio. לזה קוראים הצתה מאוחרת.
מענה אמיתי לבעיות אמיתיות
מההתרשמות שלי, הספריות והפריימוורקס שקיימים בסביבת open-source נותנים מענה אמיתי לבעיות אמיתיות.
בואו ניקח דוגמה, ונבדוק את הבעיה (האמיתית!) שנקראת בעיית ה C10K. לעצלנים שביניכם אסביר רק שהבעיה היא איך להחזיק סדר גודל של 10,000 (במילים: עשרת אלפים) חיבורים פתוחים בו זמנית, ולספק תוכן דינמי (תלוי בקשה). דמיינו למשל מערכת צ'ט שרצה על שרת יחיד ומחוברים אליה בו זמנית 10,000 משתמשים – איך עושים את זה?
איך Microsoft פותרים את בעיית C10K בדוט-נט? כנראה ע"י מספר שרתי Windows Server עם load-balancer רציני לפניהם. כלומר, הבעיה נופלת על ה-load-balancer, והפתרון הזה עולה די הרבה כסף בסופו של דבר. אמנם, כבר בדוט-נט 2.0 הוצג הפיצ'ר שנקרא Asynchronous Pages, וידידו ה"קל" יותר IHttpAsyncHandler שכבר קיים (!) מגירסה 1.1.
אלה פתרונות חלקיים לבעיה. באופן כללי, ASP.NET זו מערכת שנבנתה עם מערכת שיקולים משלה, וכנראה בזמן ה-design, לא ייחסו חשיבות גבוהה מדי לכל הנושא של concurrency ושל non-blocking execution. רק בשנת 2012, החל מגירסה 4.5 של דוט-נט, יש סוף-סוף התייחסות סבירה ל- async I/O בתבנית של async/await. בלי להכנס לפרטים, אסביר רק שהכוונה ב async I/O היא להעביר למערכת ההפעלה עצמה (ולמעשה לבקר החומרה הרלוונטי) את הביצוע ברקע של משימות I/O, כגון כתיבה/קריאה לדיסק, או שליחה/קבלה של נתונים ממשאבי רשת. בזמן הביצוע ברקע, ה-thread ה"נוכחי" מתפנה למשימות אחרות. אפשר לקרוא עוד פה, כאן ופה. זה עדיין פתרון חלקי אם דרוש thread לכל חיבור.
ואיך בסביבת open-source פותרים את בעיית C10K? כאן כבר יש התייחסות ענפה לבעיה, ויש פתרונות טובים וזולים, כבר משנת 2009. שלוש דוגמאות בולטות:
- node.js, שתוכנן מראש להיות event-driven, כולל non-blocking I/O, והוא נותן מענה יפה ל-concurrency. קיים מ 2009.
- הפריימוורק/שרת שנקרא Tornado, שוחרר כ open-source, כתוב בפייתון, משתמש ב Reactor pattern. יש בו שימוש אינטנסיבי ב async I/O. הוא מאוד קל לפיתוח והוא מאוד סקאלבילי (אין לי סטטיסטיקה מדויקת, אבל אתם יודעים, פייסבוק קנו את FriendsFeed, החברה שכתבה את זה). קיים מ 2009.
- הפריימוורק שנקרא Twisted, כתוב בפייתון, open-source. באופן כללי הוא "כבד" יותר מ-Tornado. קיים מ 2002.
אלו רק שלוש דוגמאות, אבל היד עוד נטויה. ב open-source יש פתרונות מלאים וזמינים לבעיית C10K.
פתרונות חדשניים לבעיות אמיתיות
בסביבת open-source, יש פרויקט פתוח (!), ואפשר בד"כ לשפר אותו ולהוסיף פיצ'רים שמתבססים על צרכים אמיתיים, שהגיעו "מהשטח". פרוייקטי open-source צומחים מהשטח, וחופש הבחירה שיש לנו, המפתחים, מאפשר לפרויקטים המוצלחים יותר – להמשיך ולהתקיים, ולפחות מוצלחים – להתפוגג לאיטם.
זוהי אבולוציה במיטבה. המוצלח – שורד. הפחות מוצלח – מתפוגג.
בהקשר הזה, המוצלח בדרך כלל נותן פתרון חדש יותר, איזשהו טוויסט מעניין שלא ניסו קודם לכן. מה שעוד יותר יפה כאן הוא המשוב המיידי שקהילת המשתמשים מספקת לפרוייקט: דיווח על באגים, הצעות לשיפור, פוסטים, שאלות – הכל מגיע, ומהר. פרוייקט מוצלח הוא כזה שגם עונה על צורך אמיתי, וגם מצליח להשתנות בהתאם למשובים השונים.
כדוגמה לפרויקט מוצלח אתן את Kafka. זה פרויקט מדהים, שבא מצורך אמיתי, של distributed message queue עם יכולות מאוד מתקדמות, וכתוב ב-Scala. האם חברה כמו Microsoft תספק מוצר חדשני כמו זה בעתיד?
יש עוד הרבה פרויקטים מוצלחים וחדשניים. רשימה קצרה: Redis, Couchbase, Storm, Hadoop, Cassandra ועוד ועוד. כל פרויקט מוצדק בפני עצמו, ונותן מענה חדשני לבעיה מסויימת. לרובם קהילה פעילה ומדריכים טובים.
למה כל זה קורה?
מצד אחד, חברה כמו Microsoft היא חברה ענקית, מכובדת, שהרבה פעמים הצליחה לספק תשתיות פיתוח טובות למפתחים. מצד שני, אני חושב שכבר מ 2008 היא הופכת להיות פחות ופחות אטרקטיבית במובן של תשתיות פיתוח (דוט-נט וכד'). גם עופר כותב שמהנדסים של סטארט-אפים פשוט מתעלמים ממה שיש ל-Microsoft להציע (במילים שלו: "לא אכפת להם"). למה זה קורה? להבנתי, יש כאן שני עניינים שמסבירים את זה:
Microsoft היא חברת תוכנה לשוק ה-Enterprise
כל עוד הדרישות היו צנועות, הפתרונות מבית Microsoft היו סבירים. אבל האינטרנט התעצם, ואיתו הצורך בפתרונות סקאלביליים. Microsoft היא חברה שמפתחת פתרונות לשוק ה Enterprise. תחשבו על זה רגע:
- כל הסיפור הזה שנקרא MS-SQL-Server הוא ל Enterprise, כיום בתחרות ישירה מול Oracle.
- כל הסיפור הזה שנקרא Windows Server – לשוק ה Enterprise.
- הסיפור עם Dynamics – שייך ל Enterprise.
- וגם SharePoint – שייך ל Enterprise.
על פי הערכה מ 2013, כל פריט מהרשימה הזו מכניס ל Microsoft למעלה ממיליארד דולר בשנה.
אז מה המקום של דוט-נט בכל זה? אפשר לטעון שדוט-נט זו סביבת פיתוח לשימושים מגוונים. זה טיעון לא רע. אבל הנה טיעון קצת פחות מלבב: דוט-נט זו מעטפת פיתוח סביב מוצרי ה-Enterprise של Microsoft. אני חוזר: Microsoft היא חברה ששייכת ל Enterprise. ולכן הפתרונות שהיא מספקת הם פתרונות Enterprise:
יש עומס? לא הבעיה שלנו. שימו load-balancer; יש ביקוש לפיצ'ר מסויים? חכו לגירסה הבאה, שתצא אולי עוד חצי שנה במקרה הטוב; יש באג? חכו ל-fix הבא. או גרוע מזה: חכו ל service-pack הבא. או גרוע מזה: זה מה יש.
כלומר, הדרישות לסקאלביליות גבוהה מקבלות פתרון Enterprise מצד Microsoft. או שפשוט תלכו על Azure (בהצלחה!); קצב האבולוציה של המוצרים של Microsoft הוא קצב של Enterprise.
הסטארט-אפים התרבו
הקלות הבלתי נסבלת לפתוח סטארט-אפ יוצרת פריחה ושגשוג בתחום, וסטארט-אפ זה מקום שבו צריך לחסוך בהוצאות. הפתרונות מעולם ה-open-source הם פתרונות טובים מאוד (גם אם לא מושלמים), ובדרך כלל מסופקים חינם, תחת תנאי רישוי מסויימים. אני לא טוען שאין עלויות נוספות לפתרונות מתחום ה open-source, אבל בסך הכל מדובר בניהול סיכונים סביר. במילים אחרות, ללכת על הפתרונות האלה זה הרבה יותר זול ועם סיכון די נמוך (לפחות במיינסטרים של מוצרי ה open-source) לעומת מה שיש ל Microsoft להציע.
אזור הנוחות של Microsoft
חברה רווחית כמו Microsoft יכולה להרשות לעצמה לעמוד מן הצד ולראות לאן השוק הולך. למעשה המודל הזה הצליח לה לא רע עד עכשיו: דוט-נט זו העתקה טובה של Java; תוכנת Excel זו העתקה טובה של Lotus 1-2-3; ואולי Windows זו גם העתקה של משהו?
לא פעם הדפוס של Microsoft הוא כזה. הבשלה: להמתין ולראות אם רעיון מסויים הוא רעיון רווחי; העתקה: להעתיק את הרעיון, לעיתים גם להשביח אותו; ליטוש: לכתוב תיעוד מצוין; שיווק ומכירות: לשווק אותו בצורה אגרסיבית; ככה יוצרים אזור נוחות למשתמשים של המוצרים עצמם. למעשה, ככה גם Microsoft יצרה לעצמה את אזור הנוחות שלה.
כיום, עם שגשוג סביבת ה open-source, המודל הזה לא עובד מספיק טוב עבור מתכנתים. סביבת ה open-source מכתיבה קצב שונה, מהיר הרבה יותר ממה ש-Microsoft יכולה לעמוד בו באופן מסורתי. שלב ההבשלה עצמו יכול להימשך שנתיים ומעלה. המשמעות היא שמי שמאמץ את הכלים של Microsoft הוא בסביבות שנתיים אחורה לעומת המוצרים הכי חדשים בשוק. אז שסטארט-אפ יקח על עצמו דווקא את הכלים האלה?!
התפכחות ושינוי כיוון
נכון להיום, רוב הפרויקטים המשמעותיים ב open-source מיועדים לריצה על מערכות לינוקס. חלק קטן מהם רץ גם על Windows (למשל Apache httpd). בשנים האחרונות יש מעבר של מתכנתים מסביבת Microsoft לסביבת open-source (כלומר, אני לא היחיד שעשה את המעבר הזה), ומכאן שיש גם מעבר של מתכנתים מ-Windows ללינוקס.
כדי לבלום את התנועה הזו, Microsoft פצחה במספר מהלכים של שחרור (איטי) של קוד ל open-source. המהלך הבולט מכולם הוא שהיא הוציאה את ה core של דוט-נט לקוד פתוח (בעיקר ברישוי MIT, אבל לא רק). לא סתם הוציאה ל open-source, אלא ל-github, ולא ל-CodePlex, האתר הרשמי שבבעלות Microsoft לאחסון פרוייקטים ב open-source. למה? כי לדבריהם שם נמצאת קהילת המקודדים של ה open-source. סוג של התפכחות?
המהלכים האלה הם בחזקת פעולות הצלה, לא פחות מזה. נותרה עוד מסה מספיק גדולה של מתכנתי דוט-נט ש-Microsoft עוד יכולה לשכנע להישאר. במיוחד בישראל, עם ביקוש של 30% למתכנתי דוט-נט מסך משרות הפיתוח בשנה שחלפה, על פי בדיקה של "דיאלוג".
[interaction id="54b25eadcd7e120f0d050091"]
אני סקפטי
לגבי פעולות ההצלה האלו, אומר רק שאני סקפטי. כל המעבר ל-open-source כאילו נכפה על Microsoft. זו אסטרטגיה כל כך שונה מהמהות של Microsoft שאני לא יודע עד כמה הם יכולים לעשות את השינוי הנדרש: האבולוציה של פרוייקטים בסביבת open-source מתרחשת בקצב מהיר. האם Microsoft תעמוד בו? לא בטוח; כל ה-eco-system שמתקיים באופן טבעי כבר שנים בסביבות שהן לא Microsoft, לדוגמה פייתון, רובי, Java וכד' – כבר התפתח מאוד. קשה מאוד להדביק את הפער הזה באופן מלאכותי. דוגמה לכך אפשר לראות מהנסיון של Microsoft ליצור eco-system סביב האפליקציות והחנות של Windows Phone – זה פשוט תהליך שקשה מאוד להאיץ אותו; כל ה-tooling מסביב לקוד ולאפליקציה עצמה – הרבה יותר עשיר בלינוקס מאשר ב Windows. אני מתייחס כאן לרכיבים הבאים: מערכת ההפעלה עצמה, ה shell (ויסלחו לי כולם, אבל PowerShell זה צעד חשוב אבל רחוק שנות אור מ-bash והכלים שבו), האוטומציה (גם של ה-deployment), כלי ה-monitoring ועוד.
אני יודע שמוצרי open-source הם לא תמיד הכי קלים לעבודה, ולא תמיד יש תיעוד מספיק טוב, ולעיתים יש להם באגים. רק המוצרים ה"ותיקים" יותר הם באמת מלוטשים. כל השאר זה בחזקת לקפוץ למים קרירים ולהתחיל לארגן את הקוד או את המוצר כך שיעבוד. אומר רק שמתרגלים לזה, וזה לא כל כך נורא.
יש "הייפ" סביב open-source, וזה לא דבר רע. הטיעון ש-open-source הוא cool אמנם מתבסס על ה"הייפ" הזה, אבל אם סביבת ה open-source הייתה רק cool, אז היא לא הייתה מצליחה כל כך, ולא הייתה מאיימת על חברות ענק כמו Microsoft.
אז מהי החזית הטכנולוגית?
נכון להיום בעולם התוכנה, החזית הטכנולוגית היא זו של האינטרנט להמונים, של סקאלביליות גבוהה, של throughput גבוה. נכון להיום, החזית הטכנולוגית קיימת וזמינה בסביבת open-source, הרבה יותר ממה שקיים בסביבת דוט-נט.
ברור לי שחברות תוכנה ענקיות כמו גוגל, פייסבוק, אמאזון וכד', נמצאות בחזית הטכנולוגית של ימינו, ומחזיקות כלים ייחודיים משלהן ולא חושפות אותן כ-open-source. זה הגיוני, כי זה הביזנס שלהן. יחד עם זאת, לעיתים החברות האלו משחררות כלים מסויימים החוצה ל open-source כדי "להחזיר משהו בחזרה" לקהילה עצמה, ואגב כך גם לזכות במוניטין. נכון לשנת 2014, גוגל שחררה מעל 900 פרוייקטים. גם אם רק חלק קטן מהם הוא רלוונטי וחדשני, זה נחמד.
מנגד, Microsoft היא חברת Enterprise. יכול להיות, ואפילו נשמע די הגיוני, שחברת Microsoft נמצאת בחזית הטכנולוגית של שוק ה-Enterprise, כלומר המוצרים שלה בשוק הזה הם מרשימים מאוד (את מי שאמור להתרשם מהם..). אבל חשוב להבחין: זו לא אותה חזית טכנולוגית של האינטרנט של ימינו. שוק ה-Enterprise הוא שוק של אתגרים אחרים, תקציבים אחרים, סיכונים אחרים, וקצב אבולוציוני אחר.
חברת Microsoft מנסה לשנות משהו במהות שלה ולהכניס דריסת רגל בעולם ה open-source. ההתפכחות של Microsoft, או ההכרה שלה (סוף סוף) בעולם ה-open-source נראית לי מגושמת. להבנתי, מדובר בשתי "תרבויות" שונות כל כך, שהמאמצים של Microsoft הם בחזקת "מעט מדי, מאוחר מדי".
אם זה יצליח, זה כנראה ידרוש מ-Microsoft שיווק אגרסיבי של האסטרטגיה החדשה (גם כלפי פנים), ובכל מקרה, זה יקח זמן.
המחבר הינו מפתח תוכנה בכיר, מתמחה בצד השרת ובמערכות מבוזרות. בעל נסיון של יותר מעשר שנים בפיתוח תוכנה בטכנולוגיות שונות. הפוסט פורסם לראשונה בבלוג try, catch, write
כתב אורח
אנחנו מארחים מפעם לפעם כותבים טכנולוגים אורחים, המפרסמים כתבות בתחומי התמחות שלהם. במידה ואתם מעוניינים לפרסם פוסט בשמכם, פנו אלינו באמצעות טופס יצירת קשר באתר.
הגב
73 תגובות על "האם ה-open source הוא המטאור שיכחיד את מיקרוסופט?"
* היי, אנחנו אוהבים תגובות!
תיקונים, תגובות קוטלות וכמובן תגובות מפרגנות - בכיף.
חופש הביטוי הוא ערך עליון, אבל לא נוכל להשלים עם תגובות שכוללות הסתה, הוצאת דיבה, תגובות שכוללות מידע המפר את תנאי השימוש של Geektime, תגובות שחורגות מהטעם הטוב ותגובות שהן בניגוד לדין. תגובות כאלו יימחקו מייד.
ראשית, קוד פתוח כשלעצמו לא מבטיח מוצר איכותי יותר.
שנית, קוד פתוח לא סותר מסחריות.
חברה מסחרית יכולה לשחרר מוצרים בקוד פתוח, בפרט אם אלו מיועדים לקהל המתכנתים, והמהלכים האחרונים של מיקרוסופט ממחישים זאת היטב.
חברה מסחרית יכולה ללטש מוצרים, ולספק חווית משתמש טובה, בניגוד לפתרונות קוד פתוח שלעתים קרובות לא בשלים, ולא מספקים.
כשפת תכנות, פייתון נחותה מ-C# מכיון שהיא דינמית, ומספקת יכולות וריפיקציית קוד נמוכות.
כמו כן, סביבות הפיתוח שלה נחותות משמעותית מ-Visual Studio.
מיקרוסופט היא לא זו שצריכה להתפכח.
קהילת הפנאטים של הקוד הפתוח, בראשות לינוס טורבאלדס היא זו שצריכה להתפכח, ולהתחיל לבחון פתרונות טכניים על פי מהותם, ולא על פי אידיאולוגים דתיים.
1. כמו אפל גם מיקרוסופט מנסה ליצור סביבה שתתקע מתכנתים אצלה.. זאת בגדול הסיבה לקיומן של c# ו- objc/swift.
2. למה להשתמש בעוד interpreter מעפן כשאפשר לכתוב בשפה האמיתית היחידה? זאת שמייצרת אפליקציות ממש ולא סקריפטים איטיים ומוגבלים?! עושה לכם את זה שאתם מכירים פייטון, רובי, גאווה, פרל, בלה בלה בלה? הרי רוב הקוד הפתוח באינטרנט, זה שעובד בכל מערכות ההפעלה והסביבות לא כתוב בגאווה סקריפט ולא משתמש בגורסי אשפה איטיים..
3. GPL זה שם נרדף לקומוניזם – ותודה לאל שיש רוב מוצק של קוד פתוח עם רישיונות Capitalism Friendly שם בחוץ
מצטער, לא שכנעת אותי.
C# שפה פרודקטיבית בהרבה משאר השפות, מה לעשות רוב העלות היום בפיתוח תוכנה היא בשעות פיתוח ושכר למפתחים.
מעדיף לשלם עוד קצת על פרימיום מאשר לשלם אח"כ ביוקר בגלל שחסכתי על open source.
קלה יותר לתחזוקה?
פונקציות בסיסיות של IDEs מודרניים, כמו Find All References, Rename וכד' בלתי אפשריים (בטח לא בצורה אמינה) בשפות דינמיות.
קשה מאוד לדעת אם שברת משהו, כי מבחינת הקומפיילר כל שם, סמל וקריאה כמעט הם תקינים.
בשפות סטטיות, אתה יודע בודאות שכל פניה ואזכור הם נכונים.
בשפה כמו פייתון, אתה יודע זאת רק לאחר בדיקה ספציפית של קטע קוד נקודתי במהלך הריצה, וגם זה נכון רק עד השינוי המינורי הבא.
אני חושב שהדיון גולש להבדלים בין שפות דינמיות לסטטיות. ברור שיש הבדלים, אבל לטעמי אין כאן שחור-לבן או טוב-רע.
ספציפית לגבי פייתון, אני עובד עם PyCharm, ודווקא יש לו מנגנון מצוין לביצוע rename או שינוי של חתימה של פונקציות. מובן מאליו, שכל הפרוייקטים הרלוונטיים צריכים להיות פתוחים באותו הזמן, כדי שהשינוי יוחל על כולם. אבל זה נכון גם לגבי ביצוע rename ב visual studio.
יחד עם כל זאת, מכיוון שפייתון היא שפה דינמית, בהחלט חשוב לדעת את המגבלות שלה, ולתכנן את המערכת בהתאם. כמו שכתבתי קודם, זה לא אומר שהיא "טובה" או "רעה" באופן מוחלט, אלא שצריך לדעת איך לעבוד איתה.
פייתון כשפה דינמית לא יכולה לקבוע בודאות (בזמן הקידוד) ששם פונקציה, או משתנה נתון שייך לסקוף מסוים, ולכן ה-IDE יצטרך לנחש, ויפספס מופעים.
למשל, העברת אוביקט כפרמטר מאבדת את כל המידע על ה-type שלו, ולכן ברור ש-refactoring יצטרך להתבסס על ניחוש, שיפול אם יש יותר מאפשרות אחת נכונה.
"חשוב לדעת את המגבלות שלה, ולתכנן את המערכת בהתאם"
למה לתכנן לפי מגבלות, ולא לפי יכולות?
עם פייתון אתה חופר לעצמך בור עמוק, שאתה צריך לתכנן איך תצא ממנו.
אם אתה נהנה מזה, שיערב לך.
1. אתה שוב הולך לדיון של שפות דינמיות לעומת סטטיות.
2. חשוב לדעת *בכל שפה ובכל סביבה* את המגבלות ואת היכולות. גם לדוט-נט יש מגבלות, שצריך לקחת בחשבון כשמתכננים מערכת.
יכול להיות שמהניסיון שלך עם פייתון יצא לך להכנס לבורות עמוקים. לי, באופן אישי, לא יצא כל כך, והרמתי מערכת מספיק מורכבת מאפס.
אכן ערב לי :-)
מאמר מצוין, תודה. עוד אמצא את הזמן לחפור בכל הקישורים ששיבצת בו.
מסכים ב-100%.
כל חסידי השפות קשקוש שרק יצאו, מתלהבים מה-buzzwords במקום להבין שכדי להוציא מוצר טוב ויציב, צריך שנים של בשלות וניסיון ועדיף גם חברה רצינית שמתחזקת את זה.
(אורקל חברה רצינית אבל ג'אווה ממש לא מעניינת אותה ורואים את ההזנחה רבת השנים של השפה מאז שסאן נקנתה)
לגבי עלות – מהניסיון שלי, פיתוח ב-C# רק חסך כסף והרבה.
יש ספרות מעולה, יש הרבה דוגמאות, יש הרבה מאוד ספריות עזר והשפה אינטואיטיבית.
תכנס ל NPM, הפער בינו לבין NUGET שנות אור
אז מבחינתך, או #C או Java ואין צידוק לבחור בשום שפה אחרת. אני מבין נכון?
ההערה האחרונה שלך לא מוסיפה לדיון עצמו. אני לא מבין למה אתה מנסה להקניט את (רוב) המתכנתים שבחרו לכתוב קוד בסביבת open-source.
הכוונה היא פיתוח תוכנה בכלים ובשפות שהם open-source, לעומת פיתוח תוכנה בדוט-נט. להזכירך, דוט-נט זו לא שפה, אלא סביבה שלמה, שעד היום היא עדיין פחות-או-יותר עדיין "כבולה" למערכת ההפעלה Windows.
זה לא מדוייק, .net רצה על לינוקס כבר שנים (פרויקט mono)
אני מסכים, אבל לפי פידבקים שקבלתי מקולגות, פרוייקט מונו לא ממש תפס. לכן כתבתי "פחות-או-יותר".
אין לי סטטיסטיקה, ואשמח לראות אם קיימת, אבל אני חושב שרוב החברות שכבר מפתחות בדוט-נט משתמשות בסופו של דבר בשרתי Windows ולא בפרויקט מונו על לינוקס.
כלומר, אם מישהו בא ואומר לך: "יצחק, בוא תהיה ה CTO שלנו, אנחנו פותחים סטארט-אפ שהוא הדור הבא של טוויטר", אתה תבחר בדוט-נט כדי לפתח את רכיבי הליבה? איך תתמודד עם C10K?
web api + async/tasks
אחרי שנה יבעטו כל CTO כזה במדרגות.
בכל פרמטר זה כושל.
עלות, זמן פיתוח, כוח עבודה זמין…
חברים במקום לפחד לצאת מה-COMFORT ZONE תעשו סיבוב על טכנולוגיות אחרות…
רובן המוחלט של חברות הסטארטאפ בעולם לא טועה, לא סתם הולכים על טכנולוגיות אחרות, זה מוכיח את עצמו.
פייסבוק וגוגל זה מספיק בשביל להשתיק את כולם, אין אף חברה שמתקרבת לסקייל שלהן.
חברות בסקלה שלהן בכל מקרה כותבות תשתיות מאפס.
פייסבוק נאלצה להמציא את PHP מחדש (פחות או יותר) ולהכניס שלל דטהבייסים שביחד בקושי מתמודדים עם האתגרים.
גוגל גם היא מנסה להמציא שפות תכנות.
כמו שאמרת, מעטות החברות שמתקרבות לסקייל שלהן, וטפשי שסטרטאפ שמתכוון לשרת 10K משתמשים (במקרה הטוב) יבחר בפתרונות שמיועדים למאות מיליוני משתמשים.
זה לא אפקטיבי, ולא ניצול יעיל במיוחד של זמן המפתחים.
חברות הסטרטאפ נעלמות ברובן בתוך שנה-שנתיים, יהיה לא חכם במיוחד ללמוד דוקא מהן.
עדיף ללמוד מחברות ותיקות יותר, שהוכיחו את הקייס הטכנולוגי שלהן.
ג׳אקו,
אתה יורה לעצמך ברגל, הניסוח שלך לא משאיר לקורא ספק אתה תומך ב net הצורה עיוורת ובדרך מעוות מציאות איך שנוח לך.
אל תזלזל באינטיליגנציה של אנשים.
שורה תחתונה, תעקם את זה איך שתרצה, כואב להודות באמת ואני מבין את זה
אבל איך שלא תסלף את המציאות, השרותים הכי אינטנסיביים היום יושבים על שרתים שהם לא של מייקרוסופט…
פייסבוק, גוגל, טוויטר ועוד רבים וטובים…
אז בנתיים ש ynet ימשיכו לספק לנו aspx מלא זבל שאנחנו לא צריכים עם כל כתבה שאנחנו קוראים…
דור שלם של מתכנתים צעירים באחוזים מוחלטים, הולך אחרי הטכנולוגיות החדשות… בעוד 10 שנים הם יהיו מקבלי ההחלטות…
רקר לשם ההגינות
האתר של ynet זוחל בגלל העיצובב הגרוע שלו ובגלל הפרסומות והבאנרים שבדף ממוצע.
כלומר, הבעיה האמיתית של ynet נעוצה ב-html/css/js ולא בצד שרת.
אני אעז ואומר יותר מזה – גם אם היית בונה את כל האתר ב-angular או בכל framework אחר – ynet היה קורס בדיוק כמו היום וזז לאט
שלומי, יוני צודק פה, ynet בכלל מוגש מ-Akamai – CDN
שהוא בין ה-CDNים המהירים בעולם (גם פייסבוק משתמשים בו),
כך שאת תגובת השרת, אתה מקבל כמעט בזמנים אפסיים, מה שלוקח זמן זה הפרסומות וקליינט מאוד ישן שעדיין צריך לתמוך ב-IE6
ו.net זה כבר מזמן לא דפי aspx, יש mvc ועוד הרבה דברים אחרים, אין טעם להשוות מה היה לפני 10 שנים.
(בלי קשר לעובדה שאפשר גם לשתמש ב-aspx כ-mvc)
לא מבין איך בדיוק nodejs הוא non blocking? מספיק שאתה נותן לו לעשות חישוב מסובך שלוקח זמן ועכשיו אתה צריך לחכות לו. יש לו thread אחד בלבד. אז כן, הוא יודע לצאת לרשת ולחכות ל event שיחזור וכו, אבל הוא ממש לא non blocking.
בוא נקרא ביחד:
non-blocking I/O
צודק, קראתי בריפרוף. עכשיו קראתי את הכל ויש הרבה דברים אחרים שאני לא מסכים איתם :)
ה-await ב-C# 5 הופך את כל ה-non-blocking של nodejs למיותר.
קוד ב-nodejs הוא ספגטי של callbacks, בניגוד ל-C# בו אפשר לכתוב קוד אסינכרוני קריא ובר תחזוקה.
בכל מקרה, שרת אסינכרוני היה אפשרי תמיד ב-C#, כפי שציינת בעצמך, וכתיבת שרת ב-JavaScript היא רעיון שתמיד היה, ותמיד יהיה מגוחך בעיני.
העבודה האסינכרונית ב ASP.NET היא פתרון חלקי (כפי שבודאי קראת בפוסט), כי ב ASP.NET עדיין דרוש thread לכל חיבור, בניגוד ל nodejs או ל Tornado. אגב, ניסית את טורנדו? בדקת את הטענות שלך על node עד הסוף?
עד היום, כל פתרון שמבוסס על ASP.NET כבול להנחת העבודה של thread לכל חיבור, ולכן לא פותר את בעיית C10K כפי שפתרו אותה כלים אחרים שצמחו ב open-source.
אם אתה חושב, כפי שכתב אייל באחת התגובות, ששימוש ב web api עם async/await יפתור את בעיית C10K – אתה טועה.
אתה טועה ומטעה.
עבודה עם await משחררת את ה-thread , מניסיון קוד שכתבתי רץ עם אלפי חיבורים לשרת בודד.
לא טוען שלא משחררת את ה thread, ולכן בהחלט מגדילה throughput.
אבל הפתרון של ASP.NET כבול ל thread-pool, כאשר כל חיבור חדש צריך thread מתוך ה pool. לפיכך, גודל ה thread-pool הוא מקסימום החיבורים החדשים שניתן לפתוח באותה שניה.
בתוכנה אופטימלית, מספר הת'רדים יהיה זהה למספר הליבות, מכיון שבכל מקרה לא ניתן לבצע יותר עבודה ממה שהליבות הפיזיות מאפשרות.
כך שמגבלת "מספר הבקשות שניתן לפתוח בזמן נתון" לא מאוד רלוונטית.
בסופו של דבר, המכונה מגיעה למיצוי היכולות שלה (מבחינת מעבד, זכרון, קריאות דיסק וכו') הרבה לפני שהיא מתקרבת למספר הזה.
גודל ה-thread pool כשלעצמו קונפיגורבילי, אבל זה לא אומר שהגדלה שלו תשפר אוטומטית את הביצועים.
זה מאוד תלוי מה הת'רדים עושים בכל רגע נתון, ומה תופס אותם.
"ב ASP.NET עדיין דרוש thread לכל חיבור"
זה לא נכון, ראה תגובתי למעלה.
אני לא חושב שזה פותר את הבעיה של asp.net. יש עדיין threadpool בגודל X = request current , ולא ניתן לדחוף יותר מX בקשות לIIS.
אם אני טועה, ויש בשורה ממיקרוסופט לגבי asp.net ממש אשמח לשמוע!
מגבלת ה-threadpool לא רלוונטית, מכיון שלא נוצר ת'רד לכל בקשה, אם אתה כותב IAsyncRequestHandler.
עוד מימי ה-TPL היה ניתן לכתוב tasks, כאשר ה-scheduler מפזר אותם בין מספר מוגבל של ת'רדים כראות עיניו.
ה-await גורם ל-continuation להמשיך לרוץ באותו ת'רד ממנו בוצע ה-await, אך הת'רד המקורי חופשי לבצע פעולות אחרות בינתיים. (תחשוב על משהו בסטייל ה-message queue של ווינדוס).
לצורך הענין, לא צריך אפילו להשתמש ב-IIS, או ב-ASP.Net. אני כתבתי שרת שעשה שימוש ב-Nancy, ועשה שימוש מינימלי ב-API של System.Web.
אני מתייחס ספציפית ל-C# ו-.Net מול סביבות אחרות, ומבחינתי הראשונה מנצחת.
ב"ה
" למגיב משהו", כשאומרים open source הכוונה בדרך כלל לכלים שרצים על לינוקס,
קרא לי דבר מאוד דומה בשנה האחרונה. אני עובד בחברה פיננסית, והגענו עם מוצרי מיקרוסופט לתקרת ביצועים (wcf, app fabric ועוד)
ואז הגענו למוצרי קוד פתוח …. אימצנו כמה מוצרים שחלקם מוזכר פה בכתבה, ובעיות הביצועים נפתרו כלא היו, ועלינו לup time של 100%.( בעזרת redis למשל במקום app fabric, שאגב מיקרוסופט הפסיקה לתחזק לאחר גרסא 1.1 )
במוצר הבא שהקמנו החלטנו חד משמעית: לא מיקרוסופט – אגב ללא נסיון קודם בלינוקס בסביבת פיתוח
(הלכנו על node.js , java ,linux )
על ההבדלים בין TFS לgit כבר באמת אין מה לדבר…
אז צר לי להגיד לך, כנראה שאין לכם מתכנתים מנוסים מספיק.
"קוד פתוח" לא מעלים בעיות ביצועים באופן קסום.
אם כתבתם קוד גרוע, תהיה לכם פלטפורמה גרועה, וזה נכון לכל שפה.
ייתכן שהשכתוב שלכם הוא זה שהעלים את הבעיות, ולא השפה הספציפית בה בחרתם.
ג'אוה ו-nodejs אגב שתיהן איטיות מ-C#.
StackOverflow, כדוגמא, משרתת מאות אלפי משתמשים, והיא כתובה ב-ASP.Net, עם SQL Server.
אין לי מושג מה עשיתם, .net מתמודדת בקלות עם אלפי בקשות ומשתמשים לשרת, היא מהירה בהרבה מ-node ופייתון וגם יותר מהירה מ-java.
לא משנה איך תהפוך את זה , שהתוכנה שלך רצה על מערכת הפעלה אחת, היא עוברת את כל האופטימיזציות מלמטה עד למעלה ברמת הדרייברים והחומרה. שהתוכנה צריכה לרוץ על הרבה פלטפורמות, אין לך את זה.
redis הוא שרת בפני עצמו שאין לו קשר לאיזה קליינט הוא מתחבר (כמובן שיש לו קליינט מצויין ל-C# של servicestack)
הכוונה היא לאו דווקא השוואה בין שפות, אלא בין frameworks, שבאות עם השפות האלה באופן טבעי יותר.
אגב בעית הביצועים הייתה אמיתית, ולא צריך ישר להקניט מתכנתים שאתה לא מכיר. קח לך כמה דקות ותחשוב איך אתה מעביר מאות ציטוטים פיננסיים למאה שרתים בערך, שכל אחד מהם מתעדכן מאות פעמים בשניה.
Stackoverflow עובד עם elasticsearch.
אני מתנצל אם התבטאתי בצורה מקניטה.
ניתן לבנות מערכות מבוזרות ב-C# או בכל שפה אחרת.
בעצמי בניתי כאלה, אם כי ככל שדרישות הסקלביליות עולות, הספריות המוכרות הפכו פחות רלוונטיות, ונדרשתי לכתוב קוד תשתיתי שהתאים לדרישות התובעניות.
כאן אני מסכים אתך, אך אציין שהרבה יותר קל לכתוב תשתיות אלה ב-C#, מאשר ב-JS (עבוד NODEJS) או ג'אוה נניח.
Elasticsearch משרת את החיפושים, אך SO (ו-SE) הם הרבה יותר מפונקציית החיפוש.
עכשיו תחשוב איזה כיף אם לא היית צריך לכתוב את זה מאפס, ולא רק זה: היו לך כמה אופציות לבחור ביניהן
אני לא מצליח לשייך את המילה "כיף" להקשר שכולל JS, רובי, או פייתון.
וזה לא שאין תשתיות. הצרכים שלי היו ספציפיים לפלטפורמה.
לגבי SOF, זה אתר שעלה בסביבות 2008. מאז עברו 6-7 שנים. השאלה היא באיזה technology-stack הם היו בוחרים כיום.
ועכשיו, ג'אקו, שלב השאלה הזהה: לו אתה ה CTO של סטארט-אפ שאמור להיות הטוויטר הבא, או "סתם" חברת ad-network שאמורה לטפל בסדר גודל של 100K בקשות לשניה, מה היה ה technology-stack של רכיבי הליבה? האם הוא כולל את דוט-נט? איך אתה פותר את בעיית C10K למשל? או C100K?
כותב המאמר הוא זה שהשווה בין C# לפייתון, ולכן התגובות נסובות על השוואה זו.
מה הקשר לדפדפנים?
ברור מדבריך שאתה שולל את טכנולוגיות MS כשלעצמן, ללא התייחסות למהותן, והקישור לדפדפנים מוכיח זאת.
בהשוואה ישירה של טכנולוגיות הפיתוח, אני מעדיף את .Net, ואין לי כוונה לשכנע אותך להסכים.
אני חושב שההמחשה שלך מוטעית מיסודה משתי סיבות עיקריות:
1. אי אפשר להתעלם מהעובדה שגם אפ תלך את בדיקות השוק הפסימיות ביותר IE עדיין מקום שני ולא אחרון כפי שמתשמע מהמילה כשלון
2. אני חושב אתה מאוד סובייקטבי שאתה בא לשפוט את IE11 ואני בכוונה מדבר על IE11 ולא על 10 או 9 או 8 כי אני בטוח שאתה לא מדבר על chrome20 או 10 או 2 אלא על הגרסה האחרונה. IE11 הוא דפדפן מהיר וכיף להשתמש בו, הוא נוח מאוד בגרסת mobile שלו וגם בגרסת המטרו שלו. אני חושב שאם היית יכול להשתחרר מהגישה הסובייקטיבית, היית נוכח לדעת את זה גם
אגב
אחד הדברים שלדעתי לא הודגש פה.
אין כיום חיה יותר יעילה לפיתוח WEB FRONTEND מ WEBSTORM.
החברה מ JetBrains הצליחו להביא את ה-IDE שלהם לרמה מאוד מאוד גבוהה.
הם מאמצים (הרבה יותר מהר ממיקרוסופט) את הדברים החמים בשוק.
לפתח ANGULAR ב VS זה לפתח עם יד קשורה מאחורי הגב.
אז כן בVS15 הדברים משתנים אבל לקח קצת זמן…
PHPSTORM, WEBSTORM, PYCHARM אלו כלים ברמה מאוד מאוד גבוהה, לא משנה איזה פלאג תתקינו ל VS, הם פשוט יותר טובים.
תגיד אתה איתנו?! WebStorm היא אחת הסביבות הכי מעיקות שיש.. איטית בצורה מזוויעה גם על מחשב על..
לא יודע על מה אתה מדבר….
סביבה מעולה.
בכל מקרה זו דעתך זו דעתי
לכמה כבר סטרארטאפים יש את הצורך לשנות את הקוד של מערכת ההפעלה?
סטארטאפ לא יודע בכלל אם הוא ישרוד בעוד כמה חודשים.
הענקיות שציינת ממילא פיתחו מערכות יחודיות להן, והם השתמשו בopen source כנקודת התחלה במקום לפתח מאפס.
דרך אגב, אין קשר לעניין הכספי, הרבה מאוד מהמוצרי open source עולים כסף ולא מעט.
להרבה יש צורך לשנות את הקוד? על מה אתה מדבר?
כמה כבר חברות אתה מכיר ששינו את ה-JIT של JAVA ?
פריימוורקים גם ככה כולם פתוחים וניתנים לעריכה
יש לי הרגשה שמבקום להתרכז בפיתוח ולהרים מוצר, כל חובבי הלינוקס מתמקדים במסביב וכמה זה מגניב ומה אני יכול לשנות
וכן, מוצרי אופן סורס עולים כסף. גם mysql וגם mongodb וכל שאר הדברים הטובים, שתצטרך אותם בscale גדול, יעלו כסף והרבה.
סטרטאפ צריך להרים מוצר מהר, לא משנה הדרך. מחר לא בטוח אם הוא ישרוד.
נו באמת, זה טופ?
תעשה לי טובה, אני מחשיב את עצמי כפנאט תכנות אמיתי, את הסטראטאפ שלי (אתר שבו משתמשים יכולים להציע הצעות לשיפור המוצרים האהובים עליהם) בניתי באמת נקי מכל השטויות הללו, כתבתי אותו בשפה שאני פיתחתי (yonium) שמקומפל בעזרת קומפיילר שבניתי בעצמי (הוא ממש שולט על מצבי כל אחד מהטרנזיסטורים במעבד) ב-נחש מה – ב-IDE שבניתי בעצמי (yoni-code)
בניתי את האתר כל כך רזה שהוא טס
אתה ממש חובבן, משתמש עם frameworks או בשפות פיתוח שאיזה חברה או קבוצת מפתחים כתבה, זו די עצלנות לפי דעתי ונראה לי שאתה לא שואף למצוינות כמו שאתה מציג את עצמך
וואו. איזה דה ז'ה וו. ברוכים הבאים לעשור השני במאה ה21
סוף סוף כתבה ברמה!