OCaml के लिए बेहतर build system बनने तक Dune की यात्रा

 (blog.janestreet.com)
1 पॉइंट द्वारा GN⁺ 2025-02-01 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • Jane Street ने OMake से असंतोष के कारण Jenga बनाया, लेकिन बाहरी अपनापन कम रहा; संगतता के लिए बनाया गया Jbuilder अप्रत्याशित रूप से OCaml समुदाय का आधारभूत टूल बन गया
  • Jbuilder की शुरुआती सबसे बड़ी ताकत फीचर्स नहीं बल्कि गति और portability थी, और Jane Street प्रोजेक्ट्स में OCamlbuild की तुलना में लगभग 5 गुना तेज compilation ने अपनाने को बढ़ावा दिया
  • Jbuilder, OCaml Labs के साथ सहयोग में एक पूर्ण build system में विकसित हुआ, और पुराने Borland Java IDE के साथ नाम टकराव के कारण सामुदायिक चर्चा के बाद इसका नाम Dune रखा गया
  • Jane Street ने कुछ समय तक Jenga और Dune दोनों को साथ बनाए रखा, लेकिन codebase 65M lines of OCaml और 5M lines of Python तक बढ़ने से आंतरिक migration की कठिनाई बहुत बढ़ गई
  • एक साल से अधिक के केंद्रित काम के बाद अब Jane Street का codebase Dune से build होता है, और जब cache पहले से अधिकांश भरा हो तो build 2–3 गुना तेज हो जाता है

OMake से असंतोष से शुरू हुआ Jenga

  • Build system वह रोज़मर्रा का developer tool है जो कई source files से executable program बनाता है, compiler invocations और test runs तक संभालता है
  • Jane Street ने लगभग 2012 में OCaml के मानक build systems में से एक OMake से असंतुष्ट होकर अपना build system Jenga बनाया
  • अंदरूनी उपयोग में Jenga अच्छी तरह काम कर रहा था, इसलिए Jane Street ने सोचा कि समुदाय भी इसे उपयोगी पाएगा और इसे सार्वजनिक करने का फैसला किया
    • उम्मीद थी कि बाहरी उपयोगकर्ता Jenga इस्तेमाल करेंगे और इसमें योगदान देंगे
    • Jane Street के code को open source के रूप में जारी करना भी आसान हो जाएगा
  • वास्तविक बाहरी अपनापन उम्मीद से कम रहा
    • यह Windows पर काम नहीं करता था
    • Jenga अपनाने का मतलब लगभग पूरा Jane Street तरीका अपनाना था जिससे OCaml build किया जाता था
  • बाहरी उपयोग न बढ़ने पर Jane Street ने Jenga को फिर से निजी कर दिया, लेकिन open source code को build करने की समस्या बनी रही

Compatibility layer के रूप में बना Jbuilder

  • 2016 में Jane Street ने तय किया कि वह एक सरल cross-platform tool Jbuilder बनाएगा, ताकि बाहरी उपयोगकर्ताओं को Jenga पूरा अपनाए बिना भी उसका code build करने में मदद मिले
  • इसका एक उद्देश्य यह भी था कि उस समय OCaml projects के build के नए standard के रूप में उभर रहे OCamlbuild के अनुसार build scripts दोबारा लिखने का बोझ कम किया जाए
  • Jbuilder, Jenga के build configuration में उपयोग होने वाली jbuild files को समझता था और ज़रूरी compilation commands को topological sort order में चलाता था
  • शुरुआती Jbuilder सामान्य अर्थ में build system से कुछ दूर था
    • यह सिर्फ बदले हुए inputs वाले commands चुनकर दोबारा नहीं चलाता था
    • हर बार सभी commands फिर से चलाने का तरीका अपनाता था

Jbuilder से Dune बनने की प्रक्रिया

  • Jbuilder मूल रूप से एक छोटा compatibility layer बनने के लिए बनाया गया था, लेकिन उपयोगकर्ताओं ने इसे Jane Street packages से आगे बढ़कर अपने प्रोजेक्ट्स के build में भी इस्तेमाल करना शुरू कर दिया
  • अपनाने का सबसे बड़ा कारण गति था
    • Jane Street projects के compilation में यह OCamlbuild से लगभग 5 गुना तेज था
    • इसकी portability अच्छी थी
    • इसकी संरचना सरल थी, इसलिए इसे बदलना आसान था
  • Jane Street ने OCaml Labs, जो अब Tarides है, के साथ मिलकर Jbuilder को एक अधिक पूर्ण build system में विकसित करना शुरू किया
  • नाम भी एक अलग समस्या बन गया
    • पहले से Borland का Java IDE JBuilder मौजूद था
    • वह system बहुत पहले व्यावहारिक रूप से गायब हो चुका था, लेकिन नाम उपयोग की अनुमति के लिए copyright holder से संपर्क करने पर भी मंज़ूरी नहीं मिली
  • सामुदायिक चर्चा के बाद नया नाम Dune चुना गया

दो build systems को साथ बनाए रखने की लागत

  • Dune की लोकप्रियता बढ़ने के साथ Jane Street को अपने बनाए दो पूर्ण build systems, Jenga और Dune, दोनों को एक साथ maintain और support करना पड़ रहा था
  • Dune ने फिर से डिज़ाइन की गई संरचना, अधिकांश user builds में तेज प्रदर्शन, व्यापक अपनापन, और बेहतर API व user experience वाले system के रूप में अपनी जगह बना ली
  • अंदरूनी सिस्टम को Dune पर कब ले जाना है, यह स्वाभाविक अगला प्रश्न बन गया, लेकिन build system team बढ़ते codebase के साथ कदम मिलाने में ही व्यस्त थी
    • 2016 में जब Dune शुरू हुआ तब OCaml code 4M lines का था
    • अब यह 65M lines of OCaml और 5M lines of Python तक पहुँच चुका है
  • Dune migration इतना भारी काम था कि इस पर गंभीरता से शुरुआत नहीं हो पाई, और बस यही आशावादी अनुमान दोहराया जाता रहा कि “शायद अगले 6–12 महीनों में यह संभव हो सके”
  • पिछले साल Jane Street ने build system team को बढ़ाकर 5 full-time engineers किया, जिसके बाद लंबे समय से टल रहे migration काम की शुरुआत हुई

Jane Street के अंदर Jenga की जगह Dune

  • सबसे बड़े कामों में से एक यह सुनिश्चित करना था कि Dune, Jane Street के विशाल codebase के हिसाब से scale कर सके
  • बाहर Dune के तेज दिखने का एक कारण यह था कि अधिकांश उपयोगकर्ता Jane Street के 70M-line repository की तुलना में कहीं छोटे projects build कर रहे थे
  • Jenga भी 10 साल तक जड़ नहीं रहा था
    • Jane Street codebase की वृद्धि के साथ Jenga के implementation में लगातार सुधार करता रहा था
    • Jenga बड़े monorepo की ज़रूरतों के अनुसार काफ़ी optimized हो चुका था
    • इस optimization का बड़ा हिस्सा Dune में लाना पड़ा
  • रोज़मर्रा के integration काम भी कम चुनौतीपूर्ण नहीं थे
    • Build system कई workflows से कॉल किया जाता था
    • Vim, Emacs, और VSCode — इन तीनों editors में Jenga के लिए custom integrations थीं
    • हर integration को एक-एक करके Dune पर migrate करना पड़ा
  • एक साल से अधिक के केंद्रित काम के बाद अब Jane Street का codebase Dune से build होता है
    • transition के समय Dune का प्रदर्शन कुल मिलाकर Jenga जितना या उससे बेहतर था
    • कुछ मामलों में यह कहीं बेहतर साबित हुआ
    • जब अधिकांश build work पहले से cache में हो, तो build 2–3 गुना तेज हो जाता है

एकल system पर संभव अगला सुधार

  • Jane Street, Dune के performance improvements का बड़ा हिस्सा open source के रूप में जारी करने की योजना बना रहा है, और कुछ हिस्सा पहले ही जारी किया जा चुका है
  • Jane Street के लिए अलग Dune fork और बाहरी Dune जैसे दो system फिर से न बनें, इसके लिए जहाँ संभव हो बदलावों को upstream करने पर ध्यान दिया जा रहा है
  • Dune नए features बनाने के लिए बेहतर आधार बन गया है
    • codebase अधिक सरल है और उस पर काम करना आसान है
    • अब एक ही system पर ध्यान केंद्रित किया जा सकता है
  • अब ये अगले features भी अधिक नज़दीक लगते हैं

    • Distributed builds

      • shallow builds, यानी “builds without the bytes”
      • build graph का cache loading
      • build system team अब न्यूयॉर्क, लंदन और सिंगापुर में 12 full-time engineers तक बढ़ चुकी है, और Dune improvements की रफ़्तार भी तेज हुई है

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

1 टिप्पणियां

 
GN⁺ 2025-02-01
Hacker News की राय

  • Dune का क्रैश मैसेज:

    मैं segfault नहीं करूँगा। अनिश्चितता मन को मारने वाली है। exception वह छोटी मौत है जो पूर्ण विनाश लाती है। मैं हर case को पूरी तरह व्यक्त करूँगा। execution मेरे पास से और मेरे भीतर से गुजरेगा। उसके गुजरने के बाद मैं उसके path के साथ stack को rewind करूँगा। जहाँ cases handle हो चुके होंगे, वहाँ कुछ नहीं होगा। सिर्फ मैं बचूँगा

    • वाह, यह सच में था
      https://github.com/ocaml/dune/issues/2767
    • ऐसा लग रहा है जैसे किसी पंथ में दीक्षा मिल गई हो

  • Jane Street के technical podcast Signals and Threads में 2020 में build systems पर एक episode था, और मैं उसे जोरदार recommend करता हूँ
    बाकी episodes भी अच्छे हैं, खासकर Richard Eisenberg वाला The Future of Programming और Anil Madhavapeddy वाला What is an Operating System? भी recommend करता हूँ
    ¥https://signalsandthreads.com/build-systems/
    °https://signalsandthreads.com/future-of-programming/
    §https://signalsandthreads.com/what-is-an-operating-system/

    • यह footnote notation का तरीका दिलचस्प है। सोच रहा हूँ कि यह बस मज़े और aesthetics के लिए है, या इसके पीछे कोई गहरी origin या purpose है
    • अच्छी recommendation है, और Multicast and the Markets भी वाकई अच्छा था
      https://signalsandthreads.com/multicast-and-the-markets/

  • Jane Street ने यह साबित किया है कि HM-typed functional programming भी अगर पर्याप्त मेहनत की जाए तो production-ready और बहुत तेज़ हो सकती है, यह सम्मान की बात है
    आज भी कभी-कभी सुनने को मिलता है कि ज़्यादा academic style की functional languages production में इस्तेमाल नहीं की जा सकतीं, लेकिन OCaml दिखाता है कि high-performance requirements होने पर भी यह पूरी तरह संभव है

    • Mercury भी backend में Haskell इस्तेमाल करता है
      https://mercury.com/
    • सही। production में F# भी काफ़ी इस्तेमाल होता है
      existing systems के साथ व्यापक interoperability रखते हुए high-quality programs बनाने के लिए यह बेहतरीन option है
    • NoRedInk भी backend के कुछ हिस्सों में Haskell इस्तेमाल करता है, और frontend के ज़्यादातर हिस्से में Elm
      कुछ साल पहले के blog post के मुताबिक उन्होंने Roc भी आज़माया था, लेकिन अब इस्तेमाल करते हैं या नहीं, पता नहीं
      [0] https://blog.noredink.com
    • pandoc भी Haskell में लिखा गया है। Facebook ने भी एक समय spam prevention में Haskell इस्तेमाल किया था, अब भी करता है या नहीं, पता नहीं
    • क्या मतलब है कि type system execution speed को प्रभावित करता है? मेरी जानकारी में type system बस static analysis है, इसलिए runtime speed पर उसका असर नहीं होता

  • Janestreet के blog posts जब भी देखता हूँ, मन ही मन हँसी आती है कि Jane में finance industry का काम करना तथाकथित tech industry jobs के 90% से ज़्यादा मज़ेदार और बेहतर reward वाला लगता है

    • Jane Street और कुछ elite companies, finance industry के tech workforce का बहुत छोटा हिस्सा ही हैं
      finance tech jobs में बहुत-सी roles ऐसी हैं जो Jane Street तो दूर, average tech company जितनी भी दिलचस्प या अच्छी paying नहीं होतीं
    • दूसरों की घास हमेशा ज़्यादा हरी दिखती है
      finance में बहुत-सा काम 20 साल पुराने Java code को ठीक करना, या custom reports के लिए Excel files में data डालने-निकालने के नए तरीके ढूँढना होता है
    • proof नहीं, बस anecdote है, लेकिन मेरे एक colleague ने JS में 6 महीने काम करने के बाद काम बहुत boring लगने के कारण FAANG join कर लिया। salary ज़्यादा थी, फिर भी ऐसा किया
      और मैंने सुना है कि JS में जाना Google/Meta से कहीं ज़्यादा मुश्किल है
      मैंने भी पहले apply किया था, interviewer काफ़ी unpleasant था, और big tech interviews में मेरे साथ ऐसा कभी नहीं हुआ, इसलिए impression अच्छा नहीं रहा
    • क्या सच में? working hours लंबे होते हैं, standards बहुत सख्त होते हैं, और आखिरकार profit के लिए numbers manipulate करने का काम है, इसलिए ज़्यादातर लोगों के लिए यह बहुत meaningful काम नहीं है
      फिर भी, लोगों से ads click करवाने वाले काम से इसे ऊपर रखूँगा
    • Jane Street या इसी तरह की selective high-frequency trading firms में होने वाले काम को लोग बहुत overestimate करते हैं
      बाकी companies की तरह यहाँ भी interesting projects और boring work का mix होता है

  • complex codebase से भी बुरा सिर्फ complex build system है। CMake घिनौना है
    यह ऐसा है जैसे “इस language को compile करने के लिए एक और नई language सीखो!”

    • complex build system से भी बुरा है ऐसा simple build system जो ज़रूरी चीज़ें build ही न कर सके :(
    • यह “यह घटिया नई language सीखो” के ज़्यादा करीब है
    • मुझे CMake से नफ़रत नहीं है। यह भयानक तो है, लेकिन जब आप पहले से C या C++ इस्तेमाल कर रहे हों तो standards काफ़ी नीचे set हो जाते हैं
      यह कुछ चीज़ें सही भी करता है, और जिन चीज़ों में गलत है उनमें से कुछ manageable हैं
      अगर human-editable config files के एक set से कई platforms के build procedures मिल जाएँ, तो कुछ हद तक pain सहा जा सकता है
    • modern target-oriented CMake में मौजूद ideas valuable हैं
      भयानक scripting language उसे पीछे खींचती है, लेकिन पर्याप्त motivation हो तो इसे improve किया जा सकता है

  • पहले Lisp के बाद अपने पहले functional अनुभव के तौर पर मैंने Haskell में कुछ साल बिताए थे
    OCaml मुझे खास समझ नहीं आया था, और मुझे एक दुर्लभ किस्म की semicolon allergy थी, इसलिए Haskell देखने में कहीं बेहतर लगता था
    लेकिन हाल में Reason इस्तेमाल करके देखा तो बहुत अच्छा लगा, और अचानक OCaml से जुड़ी हर चीज़ दिलचस्प लगने लगी

    • F# में OCaml की कुछ ज़्यादा दिलचस्प खूबियाँ, जैसे module system की expressiveness, नहीं हैं, लेकिन इसकी syntax indentation-sensitive है, इसलिए ज़्यादातर मामलों में semicolon समेत कई संरचनाएँ हट जाती हैं
      https://learn.microsoft.com/en-us/dotnet/fsharp/language-ref...
    • “अगर मकसद फाइल को script के रूप में compile या interpret करना है, तो OCaml में double semicolon से बचा जा सकता है और बचना चाहिए। इसे छोड़ भी दें तो error नहीं आएगा, लेकिन यह बेकार है। Compiler इसे इसलिए allow करता है ताकि UTop से फाइल में copy-paste करते समय इसे हटाना न पड़े।”
      https://ocaml.org/docs/toplevel-introduction#loading-librari...
      https://reasonml.github.io/ बढ़िया दिखता है, और JavaScript जैसी feeling वाला OCaml लगता है
    • मजेदार बात यह है कि Haskell में जो चीज़ मुझे हमेशा खटकती थी, वह यह थी कि यह structure पहचानने के visual cues के बिना whitespace और identifiers के flow जैसा महसूस होता था
      वह रेखा समझ में आ जाए तो ठीक होगा, लेकिन लगता है कि Lisp की तरह उस structure में सोचना सीखना पड़ता है। फिर भी screen भर Haskell code दिखे तो डर लगता है
      उनमें SML/NJ सबसे पढ़ने में आसान लगा
    • काश Reason syntax ही default syntax होती

  • जानना चाहूँगा कि क्या किसी ने Jane Street की open-source OCaml libraries और tools को किसी हद तक serious project में इस्तेमाल किया है
    थोड़ी देर देखने पर impression यह था कि उन्होंने ecosystem बनाने और code को open source में जारी करने में काफी मेहनत की है, लेकिन Jane Street के बाहर लोगों के इस्तेमाल के लिए यह “ready” हालत में नहीं लगता था

    • इस्तेमाल कर रहा हूँ। जिस project में पहली बार OCaml सीखा, उसमें उनके standard library replacement का इस्तेमाल किया था, इसलिए तब से use करता आ रहा हूँ
      कुछ ढूँढना हो तो function signatures पढ़ने में काफी माहिर होना पड़ता है, लेकिन इसके अलावा कोई शिकायत नहीं है। उदाहरण के लिए, सभी basic types के लिए s-expressions में convert करने और वापस लाने वाले functions का होना, अगर आपको उनके बारे में पता हो और पहले से plan करें, तो बहुत समय बचाता है
      दूसरी libraries भी इस्तेमाल की हैं, और logging व unit test ppx, OCaml world में अगर ऐसी चीज़ का होना संभव है, तो लगभग de facto standard के करीब हैं। Code formatter, एक test framework, और advanced data structures implementations भी इस्तेमाल किए हैं
      कभी-कभी, दूसरे comments की तरह, वाकई कुछ ऐसा मिलता है जो काम नहीं करता। जैसे किसी अलग से distribute की गई undocumented चीज़ पर dependency, या कोई secret configuration चाहिए। इसमें दुर्भावना नहीं है; issue खोलकर 1–2 साल बाद लौटें तो अक्सर वह काम करने लगता है
      frustration बिल्कुल नहीं है ऐसा नहीं, लेकिन कम releases को test और polish करने पर resources लगाने के बजाय सब कुछ公開 करने वाले approach की मैं सराहना करता हूँ। Code quality आम तौर पर बहुत ऊँची है, और अगर खुद run न करा पाऊँ तो भी यह rigorous और verified example implementation बन जाता है
    • serious project तो नहीं, लेकिन अपने personal static site generator में उनकी stdlib इस्तेमाल करता हूँ
      मेरे हिसाब से API standard stdlib से कहीं बेहतर है
    • magic-trace tool आज़माने की कोशिश की थी, लेकिन एक मामूली dotnet program पर भी कम से कम 4 अलग-अलग crashes हुए
    • Bloomberg में इस्तेमाल किया था
    • एक complex math research project के tests चला रहा हूँ, और runtime हैरानी की बात है कि अब तक Lean 4 << Haskell << OCaml क्रम में है
      मुझे Lean 4 पसंद है, लेकिन AI से मदद लेना आसान नहीं है। आज जिस काम पर लगा हूँ, वह reference manual को इस तरह digest करना है कि वह 200K context window में ठीक से फिट हो जाए। देखूँगा मदद मिलती है या नहीं

  • यह काफी हैरान करता है कि अपना नया build system develop करके उस पर migrate करना, buck2 या bazel जैसे ready-made tools अपनाने की तुलना में अब भी reasonable है
    इसका मतलब यह नहीं कि ऐसे advanced build tools अपनाना आसान है, लेकिन खुद बनाने से तुलना करें तो कैसा है? जानना चाहता हूँ कि क्या कोई खास बात है जो dune को बहुत अलग बनाती है

    • specifics पर experienced लोग बेहतर बता सकेंगे, लेकिन जब JS ने 2012 में अपना tool बनाना शुरू किया था, तब न buck था न bzl
      Bazel की पहली release 2015 में आई, Buck 2013 में
      JS में थोड़ा NIH culture तो है, लेकिन यहाँ वह factor था या नहीं, नहीं जानता। उस समय अच्छे build tools बहुत ज्यादा नहीं थे, खासकर ऐसी company के लिए जो non-mainstream tech stack इस्तेमाल कर रही हो
    • OCaml का कोई खास expert नहीं हूँ, लेकिन मेरी समझ में जिनका उल्लेख हुआ है, उनमें OCaml को सही semantics के साथ compile करने वाला build system असल में सिर्फ buck2 है
      खास तौर पर, पहले से ocamldep चलाने की क्षमता चाहिए होती है या दो बार compile करना पड़ता है, ऐसा मुझे पता है; buck2 यह कर सकता है और Bazel में याद पड़ता है कि hack चाहिए
    • हमारी team के पास बड़ा OCaml codebase और dual build system है, यानी buck2 और dune
      दोनों मोटे तौर पर समान हैं। OCaml build tools को invoke करने की raw speed में dune तेज है, और जब बहुत कुछ फिर से build करना हो तथा distributed build system इस्तेमाल हो रहा हो, तो buck2 जीतता है
      बड़ा दर्द LSP integration है। LSP server के पास file की dependencies जानने का इकलौता तरीका build है, इसलिए उसे build system से करीबी से जुड़ा होना पड़ता है। dune में सब कुछ साफ-सुथरे तरीके से मिलता है। buck2 के साथ भी हमने किसी तरह जोड़ रखा है, लेकिन वह उतना अच्छा नहीं है

  • Dune build system के नाम के तौर पर सबसे बेहतरीन है, और कोई उसके आसपास भी नहीं आता

    • सही। “जो build system को नियंत्रित करता है, वही ब्रह्मांड को नियंत्रित करता है”
    • क्या इसलिए कि software चलती रेत पर बना होता है?

  • बेहतर build system बनाने की शुरुआत की और “संयोग से” बेहतर build system बना दिया—ऐसे संयोग कैसे होते हैं, यह वाकई अजीब है