Ninja(2020) की सफलता और असफलता

 (neugierig.org)
2 पॉइंट द्वारा GN⁺ 2024-11-30 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • 2011 में जारी Ninja Make जैसे build system से शुरू हुआ और Chrome, Android के कुछ हिस्सों, Meson, और CMake-based projects तक फैलकर open source की एक प्रतिनिधि सफलता की कहानी बन गया
  • सफलता और असफलता को तय करने वाली धुरी code से ज्यादा architecture, और उससे भी आगे maintenance व user expectations जैसी सामाजिक समस्याएं थीं
  • Ninja ninja.build में लिखे commands, inputs और outputs पढ़ता है, files के modification time जांचता है, फिर जरूरी tasks को parallel में चलाता है; इसका focus बड़े projects के incremental builds को तेज बनाना है
  • सबसे बड़ा design choice यह था कि इसने high-level build features को अपने अंदर नहीं रखा और action graph executor तक सीमित रहा; जटिल फैसले generator पर छोड़कर अलग कर दिए गए
  • CMake integration, Windows support, और parallel execution के defaults ने adoption बढ़ाया, लेकिन design goals से टकराने वाली मांगें और contributions open source maintenance पर बड़ा बोझ बनी रहीं

Ninja के व्यापक इस्तेमाल का संदर्भ

  • Ninja करीब 9 साल पहले जारी हुआ Make जैसा build system है; शुरुआत में यह संकोच के साथ share किया गया side project था, लेकिन बाद में व्यापक रूप से इस्तेमाल होने लगा
  • प्रमुख use cases इस प्रकार हैं
    • Chrome ने अंततः सभी non-Ninja builds हटा दिए
    • Android system के बड़े components में से कुछ के लिए Ninja का उपयोग करता है
    • Meson project Ninja का उपयोग करता है, और free software दुनिया में यह तेजी से ज्यादा इस्तेमाल होने वाला build system लगता है
    • CMake के साथ Ninja इस्तेमाल करने वाले projects भी कई हैं, और Swift build guide भी Ninja install करने को कहती है
  • Ninja 2011 में release हुआ, 2014 में project ownership transfer हुई, और फिर बाद में तीसरे main maintainer तक पहुंची
  • इस retrospective से सामने आने वाला मुख्य अनुभव यह है कि code से ज्यादा architecture, और architecture से ज्यादा social issues असर डालते हैं

तेज build के लिए बुनियादी behavior

  • Ninja जो करता है वह अपेक्षाकृत सरल है
    • user ninja.build file में चलाए जाने वाले commands, हर command जिन files को consume करता है, और जिन files को generate करता है, उन्हें लिखता है
    • Ninja इस file को पढ़ता है और कई files के modification time जांचता है
    • up-to-date state बनाने के लिए जरूरी commands को parallel में चलाता है
  • Make की तुलना में input build language में features कम हैं, और structure कम features को बेहद तेजी से perform करने पर focused है
  • execution flow तीन steps में बंटा है
    • build file parsing और interpretation
    • input files के modification time की जांच
    • जरूरी commands का execution
  • लक्ष्य यह है कि 100,000 से ज्यादा input files वाले बड़े projects में भी तीसरे step तक जितनी जल्दी हो सके पहुंचा जाए
  • optimization के उदाहरण के तौर पर, Ninja input file paths को जितना जल्दी संभव हो unique memory objects में map करता है और बाद में path identity comparison के लिए pointer comparison का उपयोग करता है
  • lower-level performance details The Performance of Open Source Software के Ninja chapter में cover किए गए हैं
  • कई वर्षों में Ninja reimplementations भी आए
    • llbuild और Shake Ninja files को input के रूप में support करते हैं
    • samurai लगभग file-by-file reimplementation project है; code कम है, लेकिन features भी कम हैं और tests नहीं हैं
  • मजेदार 20% implementation आसान है, लेकिन बाकी 80% में बहुत details हैं, और कोई ज्यादा तेज implementation ज्ञात नहीं है

design में महत्वपूर्ण choices

  • graph representation

    • Make उस case को अच्छी तरह handle नहीं कर पाता जहां एक build rule कई files generate करता है
    • Ninja files के बीच graph नहीं, बल्कि files और commands के बीच bipartite graph का उपयोग करता है
    • file nodes, command nodes में जाने वाली edges बनते हैं, और command nodes फिर output files की ओर जाने वाली edges रखते हैं
    • यह structure build के वास्तविक रूप को बेहतर तरीके से capture करता है
    • inputs में से कोई एक बदल जाए तो command stale हो जाता है, और command चलने पर सभी outputs update होते हैं
    • किसी specific file में अधिकतम एक input edge हो सकती है
    • command line खुद भी command node के input जैसी मानी जा सकती है, इसलिए command-line flags बदलने पर command और outputs stale हो जाते हैं

  • deps log और C header dependencies

    • C header dependencies को सही ढंग से handle करने के लिए C compiler द्वारा बनाया गया अतिरिक्त dependency data consume करना जरूरी है
    • database introduce करने या simplicity बनाए रखने के बीच सोचते हुए deps log representation format बनाया गया
    • यह format काफी compressed है, लेकिन महत्वपूर्ण तरीके से अब भी कुछ हिस्सों में गलत है

  • end-to-end / crash-only design

    • Ninja कोई लंबे समय तक चलने वाला daemon process नहीं है; हर execution में यह शुरुआत से काम करता है
    • यह choice end-to-end principle और crash-only software से प्रभावित structure है
    • अगर शुरुआत से चलने वाला path तेज बना दिया जाए, तो अलग “online” code path बनाने की जरूरत नहीं रहती
    • जो projects memory में resident रह सकते हैं, उनमें अंततः startup performance की उपेक्षा होने लगती है

  • file state check

    • build tool के memory में resident होने की अपेक्षा रखने की एक वजह disk file state को cache करना है
    • असल में kernel पहले से ही यह information memory में cache करता है, और user space में दोबारा cache करने से बहुत बचत नहीं होती
    • Linux में file state लाना बहुत तेज है, और Ninja इसे single thread में handle करता है
    • 10 साल पहले के standards के हिसाब से “fast” machine पर भी 30,000 files का stat कुछ दसियों milliseconds में किया जा सकता था

  • scale और specification का trade-off

    • अनुभवजन्य rule के तौर पर 2x scale expansion optimization से संभव है, लेकिन 10x scale expansion के लिए re-architecture चाहिए
    • Ninja उस समय लगभग 30,000 build steps वाले Chrome build को ध्यान में रखकर design किया गया था
    • आज यह छोटे environments में भी इस्तेमाल होता है, लेकिन ऐसे cases में speed advantage की जरूरत नहीं हो सकती
    • Android build जैसे बड़े environments में scale limits सामने आ रही हैं, और संभव है कि दूसरे approach की जरूरत हो
    • Ninja parallel execution के लिए user से पर्याप्त information देने की अपेक्षा करता है, लेकिन यह enforce नहीं करता कि build के बारे में सब कुछ पूरी तरह ज्ञात हो
    • correctness, convenience और performance के बीच trade-off होता है; ज्यादा correct लेकिन inconvenient tool की तुलना में convenience के लिए कुछ correctness छोड़ने वाला tool पूरे ecosystem में ज्यादा सही results दे सकता है

“assembler” metaphor से बनी separation

  • build systems कई तरह के high-level features देते हैं, और अलग-अलग tools खुद को जिस तरह describe करते हैं वह इतना व्यापक है कि तुलना करना भी मुश्किल हो जाता है
  • Ninja की मुख्य insight यह थी कि चाहे जो high-level feature दिया जाए, अंततः build system को files को up-to-date रखने के लिए action graph बनाना ही पड़ता है
  • Ninja केवल इस action graph को execute करता है, और उसके ऊपर कौन सा generator रखना है यह user पर छोड़ता है
  • इन दो programs की separation मूल रूप से Chrome project के लिए सही fit होने के कारण बनाई गई थी, लेकिन बाद में यह Ninja का सबसे महत्वपूर्ण contribution बन गई
  • इसके दो फायदे हैं
    • Ninja खुद simple और fast बना रहता है
    • *.c को glob करने जैसे expensive tasks generator की तरफ धकेल दिए जाते हैं
  • दूसरे build systems जहां एक बार में सभी tasks handle करते हैं, वहीं Ninja का structure calculated action graph को disk पर snapshot के रूप में store कराता है
  • परिणामस्वरूप build के बीच action graph cache होने जैसा रूप बनता है
  • generator जितना चाहे high-level हो सकता है
    • उदाहरण के लिए, पूरे source tree को glob करके नाम में test वाली files को tests के रूप में ढूंढना भी संभव है
  • developer को खुद तय करना होता है कि वह किस चीज की कीमत चुकाएगा
    • generator अगर पूरी disk glob करता है तो यह संभव है, लेकिन फिर build धीमा क्यों है यह भी ज्यादा स्पष्ट हो जाता है
  • generator और action graph के बीच separation वास्तव में सरल नहीं है, और Ninja में भी इस बात को लेकर कई details हैं कि कौन सा layer कौन सा काम संभाले
  • Xcode या Visual Studio build systems भी सिद्धांततः इसी तरह pre-compute करके result snapshot कर सकते हैं, लेकिन layers मिलाने के आकर्षण के कारण यह अच्छी तरह नहीं हो पाता, ऐसा माना जाता है
  • Make ने globbing, variable expansion, substring, functions जैसे programmer-oriented features सब शामिल करने की कोशिश की, और यह ऐसी language बन गई जो सभी जरूरी features express करने के लिए कमजोर है, लेकिन धीमा Makefile लिखने के लिए पर्याप्त शक्तिशाली है
  • Ninja ने इस दिशा से बचने की कोशिश की

defaults perceived performance पर हावी होते हैं

  • Ninja default रूप से इच्छित commands को parallel execute करता है
  • Make में भी -j flag से parallel execution संभव है, लेकिन default serial execution है
  • Makefile अक्सर dependencies को पर्याप्त रूप से specify नहीं करते, जिससे parallel execution safe न रहने की स्थिति में लिखे जाना आसान है
  • Ninja single-core systems पर भी हमेशा parallel execute करता है, इसलिए ऐसी errors जल्दी सामने आती हैं
  • Ninja के अनुकूल programs आमतौर पर parallel builds के लिए भी safe हो जाते हैं
  • Ninja के पास गलत dependencies detect करने वाला advanced system नहीं है; गलत builds ज्यादा बार होते हैं और इससे समस्या सामने आती है
  • users अक्सर Make का parallel execution flag भूल जाते हैं या जानते नहीं हैं, इसलिए केवल default से भी real usage में Ninja Make से “दोगुने से ज्यादा तेज” महसूस हो सकता है
  • जिस optimization का user वास्तव में अनुभव नहीं करता, उसका महत्व कम है

speed में महत्वपूर्ण metrics

  • build system की performance के कई मतलब होते हैं
    • scratch से full build में कितना समय लगता है
    • पहले build करने के बाद एक file बदलकर दोबारा build करने में कितना समय लगता है
  • Ninja बड़े codebases में incremental build के edit-compile loop को तेज करने पर focused है
  • जब पहली बार Ninja बनाया गया, तब blaze, यानी bazel, बहुत तेज होने की याद के कारण उसकी speed match करने की कोशिश की गई
  • बाद में देखने पर, जिन metrics में दिलचस्पी थी उनमें blaze खास तेज नहीं था, और Java program होने से help output भी धीमा था
  • incremental build पर obsession की वजह यह थी कि iteration time programmer satisfaction पर बड़ा असर डालता है
  • Ninja edit-compile loop में इस्तेमाल होता है, और 1 second व 4 seconds का अंतर महत्वपूर्ण है
  • “fast” का meaning users तक पहुंचाना मुश्किल है, और Ninja manual चेतावनी देता है कि छोटे projects में speed effect शायद ही महसूस हो
  • लेकिन “fast” एक बिकने वाला expression है, इसलिए feature की कमी से निराश छोटे app users भी Ninja इस्तेमाल करना चाहते हैं
  • Ninja incremental rebuild पर focused था, लेकिन कुछ users ने full build performance भी बेहतर होने की report की
    • क्योंकि Ninja लगभग कुछ नहीं करता, build के दौरान CPU कम use करता है, और real build tasks से CPU कम छीनता है
  • output भी बहुत concise है
    • successful build अधिकांशतः सिर्फ एक line output करता है
    • दूसरे build systems कई steps और timing information ज्यादा output करके heavy महसूस हो सकते हैं
  • कम बोलने वाला structure Ninja को और ज्यादा “मौजूद न होने जैसा” महसूस कराता है

adoption बढ़ाने वाला CMake integration और Windows support

  • CMake

    • Ninja मूल रूप से Chrome के special build system के साथ इस्तेमाल के लिए बनाया गया था
    • Peter Collingbourne ने Ninja को अधिक व्यापक रूप से इस्तेमाल होने वाले CMake build system से जोड़ने का काम किया
    • यह integration LLVM work के लिए शुरू हुआ था, और CMake के साथ-साथ Ninja की तरफ भी नई semantics जोड़नी पड़ी
    • real world में Ninja की सफलता का सबसे बड़ा credit Peter को जाता है
    • बाद में CMake authors ने integration संभाल लिया, लेकिन requests और concerns पर पर्याप्त response नहीं दिया
    • developer ने अब तक CMake को सीधे इस्तेमाल नहीं किया है

  • Windows

    • क्योंकि Chrome Windows को भी target करता था, Ninja भी Windows पर चलने लगा
    • Windows support का बड़ा हिस्सा एक contributor ने लिखा
    • तकनीकी रूप से Windows support बड़ा झंझट है
    • process execution और output capture ऐसे differences हैं जिनके लिए platform-specific APIs नए सिरे से सीखने पड़ते हैं
    • Ninja का design इस property पर निर्भर करता है कि kernel द्वारा cached files के last modification time तेज़ी से लाए जा सकते हैं, लेकिन Windows में यह लागू नहीं होता
    • फिर भी Windows developers के बड़े scale वाला platform है
    • Linux के लिए अच्छे tools share करने की इच्छा मजबूत होती है, लेकिन Windows tools को बेचने की इच्छा मजबूत होती है, इसलिए freely available tools अपेक्षाकृत कम हैं
    • शुरुआती Ninja users में Windows users की संख्या उस समय आश्चर्यजनक थी, लेकिन Windows developers की संख्या बड़ी है, इसलिए उनमें से थोड़ा हिस्सा भी रुचि ले तो users के रूप में दिखता है

related work को समझना

  • Ninja शुरुआत में weekend demo hack की तरह शुरू हुआ था, इसलिए बनाने से पहले related work को पर्याप्त रूप से research न कर पाने का अफसोस है
  • कुछ बनाते समय design space को सच में समझना महत्वपूर्ण है
  • “action graph” शब्द Ninja बनाते समय इस्तेमाल किया गया expression नहीं था, बल्कि Google के build system blaze/bazel से लिया गया था
  • bazel बताता है कि “library”, “binary” जैसे high-level target graph commands के graph, यानी action graph generate करते हैं
  • command-line text को file जैसे input के रूप में देखने का विचार incremental computation का एक उदाहरण है
  • incremental computation build systems के अलावा UI की incrementality से भी जुड़ता है
  • Jane Street blog पर Incremental introduction post है, और यह React जैसी UI composition methods से भी जुड़ता है
  • "Build Systems à la Carte" एक paper है जो build system context में incremental computation पर चर्चा करता है, और इसे ऐसा material माना गया है जो Ninja लिखने से पहले मौजूद होता तो अच्छा होता

open source maintenance का बोझ

  • open source maintainer experience खास सुखद नहीं था
  • project को लेकर भावना किसी के अच्छे शब्द कहने पर गर्व और उससे बड़ी निराशा का मिश्रण है
  • मुफ्त में release करने के परिणामस्वरूप, कभी-कभी विनम्रता से request करने वाले लोग थे, लेकिन ज्यादा बार नाराज users demand करते थे, और धन्यवाद दुर्लभ था
  • demand न मानने पर fork करने की धमकी देने वाले लोग भी बार-बार मिले
  • design goals से टकराने वाले reasonable contributions भी एक अलग कठिनाई थे
    • किसी दयालु और smart व्यक्ति के contribution को reject करते समय पर्याप्त explanation देकर जवाब देना चाहा, और वह explanation खुद थकाने वाला काम था
  • free software के जरिए programming में प्रवेश किया और जो मिला था उसे लौटाना चाहता था, इसलिए code लिखा; लेकिन आज का free software बराबरी के लोगों के बीच sharing से ज्यादा ऐसा trend लगता है जहां users खुद को customers समझते हैं और author को ऐसे व्यक्ति की तरह देखते हैं जिसके बारे में manager से शिकायत की जा सकती है
  • आज की motivation व्यापक success से ज्यादा उन कुछ hackers को impress करने या उनकी expectations पर खरा उतरने के करीब है जिनका सम्मान है
  • Ninja की सफलता ने बहुत कुछ सिखाया, लेकिन लगता है कि छोटी सफलता से भी वैसी ही सीख मिल सकती थी

maintainers और contributors

  • Nico Weber एक सावधान collaborator थे और कई वर्षों तक Ninja maintainer रहे
  • Jan Niklas Hasse ने Nico के बाद project संभाला, और लगता है कि वे अच्छा कर रहे हैं
  • इसके अलावा भी कई Ninja contributors ने project में हिस्सा लिया

संबंधित पढ़ाई

1 टिप्पणियां

 
GN⁺ 2024-11-30
Hacker News की राय

  • “Programming को अक्सर code लिखने जैसा कहा जाता है, लेकिन असल में code से ज़्यादा architecture महत्वपूर्ण होता है, और architecture से भी ज़्यादा social issues महत्वपूर्ण हो जाते हैं” — यह वाक्य मेरे मन में लंबे समय से रहे विचार को बिल्कुल सटीक ढंग से कहता है

    • पूरी तरह सहमत। Peopleware 1987 [1] में भी यही बात कही गई है
      किताब का अध्याय 1 दावा करता है कि “हमारे काम की मुख्य समस्याएं तकनीकी से ज़्यादा sociological प्रकृति की हैं”, और team chemistry व cohesion, “flow time”, शांत work environment, attrition cost जैसे social और political मुद्दों पर बात करता है
      [1] https://en.wikipedia.org/wiki/Peopleware:_Productive_Project...
    • Programming और उसके tools computer के लिए नहीं, लोगों के लिए होते हैं, और बहुत मामूली कामों को छोड़ दें तो computer पर चलने वाली कोई चीज़ बनाने के लिए कई लोगों की ज़रूरत होती है
      इसलिए मुझे लगता है कि software engineering, जितना बहुत लोग मानना या सहज महसूस करना चाहेंगे, उससे कहीं ज़्यादा social science के करीब है। Social science, natural science की तुलना में ज़्यादा fluid और कम predictable होती है, इसलिए लगता है कि लोग social हिस्से से बचने या उसे बहुत primitive तरीके से ही handle करने की प्रवृत्ति रखते हैं। Technology की atomic details पर तो obsession रहता है, लेकिन team द्वारा बनाया गया product बहुत बार खराब निकलता है
    • https://en.wikipedia.org/wiki/Conway's_law
      “Systems design करने वाले organizations अनिवार्य रूप से ऐसे designs बनाते हैं जो उन organizations की communication structures की copy होते हैं।” — Melvin E. Conway, How Do Committees Invent?
    • मेरे अनुभव में technical problems में से लगभग 80% इसलिए पैदा होती हैं क्योंकि दो लोग या दो teams बस आमने-सामने बैठकर बात करने से कतराती हैं
    • इसका मतलब यह dichotomy नहीं है। अच्छा architecture लोगों की system से अपेक्षाओं को पूरा करते हुए भी उसे इंसानों के समझने लायक बनाए रखता है

  • उस समय भी चर्चा हुई थी:
    The Success and Failure of Ninja - https://news.ycombinator.com/item?id=23157783 - मई 2020, 38 comments
    करीब एक साल बाद repost ठीक है, और पुराने thread का link उन readers के लिए है जो और जानना चाहते हैं

  • “Android system के किसी बड़े component में Ninja इस्तेमाल करता है, लेकिन मैंने ठीक-ठीक कभी नहीं समझा” वाला हिस्सा मज़ेदार है
    Ninja असल में AOSP में बड़ी भूमिका निभाता है। Build system ने शुरुआत में Makefile इस्तेमाल किया था, लेकिन custom declarative build system soong और असफल/रुके हुए Bazel migration की वजह से यह जल्दी ही complex हो गया। Google ने kati(https://github.com/google/kati) बनाया, जो Makefile को Ninja build files में बदलता है, और उसका output वाकई बहुत बड़ा होता है:
    λ wc -l out/build-qssi.ninja
    3035442 out/build-qssi.ninja
    Makefile/soong से Ninja तक जाने की प्रक्रिया दर्दनाक है और modern machines पर भी कुछ मिनट लेती है, लेकिन Ninja के हाथ में आते ही यह बेहद तेज़ी से चलता है

    • मैंने Ninja कभी इस्तेमाल नहीं किया, इसलिए जानना चाहता हूं कि Makefile की तुलना में इसके क्या फायदे हैं
      एक tool से दूसरे tool में translate करने के लिए एक और tool लाने लायक है या नहीं, इस पर भी संदेह है। खासकर अगर Ninja file इतनी बड़ी और इंसानों के लिए पढ़ने में मुश्किल हो सकती है, तो और भी

  • “मेरा मानना है कि programmers latency महसूस करते हैं, और भले ही उन्हें पता न चले, उसका असर उनके mood पर पड़ता है। Google ने हाल ही में इस क्षेत्र में research की और मेरे विश्वास की कुछ हद तक पुष्टि की” — इस हिस्से को लेकर जिज्ञासा है कि वह latency research सच में public हुई है या नहीं

    • पता नहीं लेखक जिस exact research की ओर इशारा कर रहे थे वह यही है या नहीं, लेकिन यह paper हो सकता है: https://www.computer.org/csdl/magazine/so/2023/04/10176199/1...
    • 400ms Doherty Threshold builds पर भी लागू होता है

  • Ninja game developers के बीच काफी popular है
    “Windows अब भी developers के लिहाज़ से एक विशाल platform है, और वे developers tools के लिए तरस रहे हैं” — यह sentence दिलचस्प लगा। मुख्य रूप से Windows पर develop करने वाले के तौर पर, मुझे उल्टा Linux developers tools के लिए तरसते हुए लगते हैं, जो Visual Studio जैसे अच्छे debugger या Superluminal जैसे profiler के बिना रहते हैं। हाल में दोनों platforms के बीच gap धीरे-धीरे घटता दिख रहा है, और broadly cross-platform चलने वाली Rust utilities भी मुझे पसंद हैं

    • जब भी कोई Visual Studio और “अच्छा” को एक ही sentence में रखता है, तो मुझे अजीब सा अहसास होता है कि universe एक simulation है और बाकी लोग किसी दूसरे universe से आए हैं
      Visual Studio के साथ interaction में मुझे ऐसा कुछ याद नहीं आता जिसे “अच्छा” कहा जा सके। “बस किसी तरह ठीक” वाली कुछ चीजें याद आती हैं, लेकिन debugging उनमें शामिल नहीं है। हालांकि 2022 में debugger अब bugs से भरा नहीं है, तो शायद बात वही हो
    • पता नहीं किस दुनिया में Visual Studio debugger को अच्छा माना जाता है। अगर उन्होंने आखिरकार इसे ठीक कर दिया हो तो अलग बात है, लेकिन जब मैंने आखिरी बार इस्तेमाल किया था, तो एक line step execute करने में कई seconds लगते थे—इतना slow कि सहना मुश्किल था
    • एक community है जो UNIX को ही developer tools का सब कुछ मानती है, और लगता है कि इसी चक्कर में वे पूरा जंगल देखकर पेड़ों को miss कर देते हैं
      1993 में Xenix से परिचय होने के बाद से मैंने कई variants इस्तेमाल किए हैं, इसलिए UNIX को अच्छी तरह जानता हूं, लेकिन WSL को मैं Linux Docker containers चलाने के अलावा लगभग इस्तेमाल नहीं करता

  • Ninja का इस्तेमाल कर रही कुछ चीज़ों को अभी samurai पर बदला गया है, और हर संभव पहलू में सुधार हुआ है
    फिर भी मुझे लगता है कि इस तरह के build system की दिशा गलत है। build system से मैं जो चाहता हूँ वह यह है कि सभी transitive inputs की सामग्री को hash करे, और देखे कि वह result registry में मौजूद है या नहीं

    • सही। distributed cache सपोर्ट करने वाले build systems मूल रूप से बदलाव की जाँच के लिए timestamps की जगह digest इस्तेमाल करते हैं: Bazel, Pants, Buck वगैरह ऐसे ही हैं
      हालांकि ये सभी बेहद जटिल हैं। सिर्फ local builds की बात करें तो मेरी जानकारी में SCons और Waf भी change detection के लिए hash इस्तेमाल करते हैं
    • आपको Ninja के लेखक द्वारा बनाए गए n2 में रुचि हो सकती है
    • लगता है यही NetKernel का idea था
      इसी तरह मैंने Deno library “TDAR”[1] बनाई थी और वह अच्छी तरह काम करती है, लेकिन उन command-line tools को, जो mutable filesystem पर चलने की धारणा रखते हैं, pure functions की तरह call करने का ढोंग करते हुए wrap करना थोड़ा मेहनत वाला है
      [1] अभी इसे parent project[2] से अलग नहीं निकाला है, लेकिन इस YouTube video में इसके बारे में बात की थी: https://youtu.be/sty29o8sUKI
      [2] अगर ऐसी चीज़ों में रुचि है तो source सार्वजनिक करने के लिए मुझे टोका जा सकता है। togos zero zero at gee mail dot comb
    • सोच रहा हूँ Samurai किस तरह बेहतर है। मैंने इसे Ninja का compatible subset माना था
      और “यह वह नहीं है जो मैं चाहता था” का मतलब “गलत” नहीं होता। क्योंकि दुनिया में अलग-अलग पसंद वाले लोग भी होते हैं
    • पता नहीं Samurai अभी भी alive है या नहीं। मैंने signal handling सुधारने के लिए pull request भेजा था, लेकिन वह आधे साल से ज़्यादा समय से अनदेखा पड़ा है

  • CMake में C++20 modules इस्तेमाल करने के लिए Ninja चाहिए, इसलिए Ninja काफी लंबे समय तक बना रहेगा

  • सबसे दिलचस्प हिस्सा यह था: “correctness और convenience या performance के बीच अक्सर समझौता करना पड़ता है, और उस continuum में आप कहाँ खड़े हैं, इसके प्रति सचेत रहना चाहिए”
    कुछ programmers इस dynamic को बहुत कठोर ढंग से देखते हैं, और मानते हैं कि एक value को स्वाभाविक रूप से प्राथमिकता मिलनी चाहिए। लेकिन वास्तव में interaction काफी nuanced होता है। उदाहरण के लिए, कोई tool जो correctness का थोड़ा त्याग करके convenience चुनता है, पूरे ecosystem में उस alternative से ज़्यादा सही results दे सकता है जो ज़्यादा correct लेकिन कम convenient है। ऐसा तब होता है जब programmers बाद वाले से बचने लगते हैं

    • यह सचमुच सोने की खान जैसा insight है। इसी वजह से Python, Go, TypeScript/JavaScript Haskell/OCaml से कहीं ज़्यादा लोकप्रिय हैं

  • “शर्मनाक नाम के लिए माफ़ करें” — नाम तो बढ़िया है
    पुनश्च: इसे implement करने पर इसे और तेज़ बनाया जा सकता है: https://github.com/ninja-build/ninja/issues/2157 हालांकि लेख में बताया गया है कि यह tool पिछले runs से आए बेहद छोटे hints तक सहित, जानबूझकर कोई state नहीं रखता