Go fix का उपयोग करके Go कोड को आधुनिक बनाना

• Go 1.26 वर्ज़न में पूरी तरह से दोबारा लिखा गया go fix कमांड पेश किया गया है, जो नवीनतम भाषा और लाइब्रेरी फीचर्स का उपयोग करके कोड को अपने-आप बेहतर बना सकता है
• यह टूल दर्जनों analyzers के ज़रिए कोड पैटर्न पहचानता है, और minmax, rangeint, stringscut जैसे कई modernizers लागू करके दोहराव वाले या पुराने कोड को आधुनिक रूप में बदलता है
• नए new(expr) सपोर्ट के लिए newexpr analyzer जोड़ा गया है, जो newInt जैसे helper functions को अपने-आप सरल बना सकता है
• go fix कई बार चलाने पर synergy effect देता है, जहाँ अलग-अलग analyzers लगातार सुधार सुझा सकते हैं, और टकराव होने पर automatic merge तथा अनावश्यक import हटाने की सुविधा भी शामिल है
• Go टीम भविष्य में 'Self-service' analysis paradigm के ज़रिए इसे इस तरह बढ़ाने की योजना बना रही है कि डेवलपर्स अपने API के लिए modernizers परिभाषित और वितरित कर सकें

---

go fix कमांड का अवलोकन

• Go 1.26 में go fix को पूरी तरह से नए सिरे से implement किया गया है, जो codebase को नवीनतम Go style में अपने-आप बदलने की सुविधा देता है
  • go fix ./... कमांड से मौजूदा डायरेक्टरी के नीचे के सभी packages में बदलाव किया जा सकता है
  • -diff ऑप्शन से बदलावों का preview देखा जा सकता है
• रजिस्टर किए गए analyzers की सूची go tool fix help से देखी जा सकती है, जिसमें any, forvar, mapsloop, minmax जैसी कई transformation rules शामिल हैं
• केवल किसी खास analyzer को चलाने के लिए -any जैसे flag का उपयोग करें, और उसे बाहर रखने के लिए -any=false दें
• प्लेटफ़ॉर्म-विशिष्ट कोड के अंतर को ध्यान में रखते हुए इसे GOOS, GOARCH संयोजनों के अनुसार कई बार चलाया जा सकता है

Modernizers — कोड को आधुनिक बनाने वाले टूल

• Go 1.18 के बाद generics आने से कोड को सरल बनाने की संभावना बहुत बढ़ गई है
  • उदाहरण: map keys इकट्ठा करने के लिए maps.Keys, और string split करने के लिए strings.Cut
• LLM-आधारित code generation tools पुराने पैटर्न बनाए रखने की समस्या पैदा करते हैं, इसलिए नवीनतम Go idioms को दर्शाने वाले open source code को अपडेट करने की ज़रूरत पर ज़ोर दिया गया है
• go fix और gopls में शामिल modernizers कोड की readability और learning effect दोनों बढ़ाते हैं
• उदाहरण modernizers:
  • minmax: if statements को min/max functions से बदलता है
  • rangeint: 3-clause for loop को range-over-int में बदलता है
  • stringscut: strings.Index आधारित कोड को strings.Cut से सरल बनाता है

Go 1.26 का new(expr) फीचर

• new function को value argument स्वीकार करने लायक बढ़ाया गया है, जिससे new("go1.26") जैसे रूप में initialization संभव है
• newexpr analyzer newInt जैसे helper functions को ढूँढकर उन्हें return new(x) में सरल बनाता है, और call sites को new(expr) से बदल देता है
• यह केवल तब लागू होता है जब minimum Go version (जैसे go 1.26 directive) पूरा हो
• $ go fix -newexpr ./... कमांड से इसे पूरे codebase पर लागू किया जा सकता है
• उपयोग के बाद अनावश्यक helper functions को deadcode टूल से पहचाना जा सकता है

Synergy और conflict handling

• एक बदलाव दूसरे बदलाव के अवसर पैदा कर सकता है, यानी synergy effect मौजूद है
  • उदाहरण: minmax लागू होने के बाद अतिरिक्त transformation सुझाव मिल सकते हैं
  • stringsbuilder → fmt.Fprintf जैसी लगातार optimization भी संभव है
• go fix 3-way merge algorithm से modification conflicts को अपने-आप merge करता है
  • syntax conflict होने पर उस बदलाव को छोड़कर warning दिखाई जाती है
  • semantic conflicts (जैसे variable removal, unused import) में manual adjustment की ज़रूरत हो सकती है
  • अनावश्यक imports अपने-आप हटा दिए जाते हैं

Go analysis framework के साथ एकीकरण

• go vet और go fix को एक साझा analysis framework इस्तेमाल करने के लिए एकीकृत किया गया है
  • vet का फ़ोकस errors पहचानने पर है, जबकि fix सुरक्षित automatic fixes पर केंद्रित है
• analyzers को unitchecker, multichecker, gopls, staticcheck, Tricorder जैसे कई drivers में चलाया जा सकता है
• fact system के ज़रिए packages के बीच जानकारी साझा की जा सकती है
  • उदाहरण: यह निष्कर्ष निकाला जा सकता है कि log.Printf, fmt.Printf का wrapper है
• gopls real-time diagnostics और automatic fix suggestions देता है

Analysis infrastructure में सुधार

• inspector package के विस्तार से AST traversal अधिक कुशल हुआ है, और Cursor type ऊपर-नीचे-बाएँ-दाएँ traversal को सपोर्ट करता है
• typeindex के ज़रिए function call indexing से analysis speed में 1000 गुना तक सुधार हुआ है
• अतिरिक्त सुधार:
  • standard library का dependency graph उपलब्ध कराना
  • फ़ाइल-स्तरीय Go version query सपोर्ट
  • refactoring primitives का विस्तार, जिससे comments जैसे सुरक्षित code modifications संभव हों
• कुछ modernizers को सूक्ष्म behavior changes के कारण बाहर रखा गया है (append([]string{}, slice...) → slices.Clone(slice) वाला मामला)
• आगे pattern matching engine, automatic test harness, और सटीक modification operator library विकसित करने की योजना है

Self-service paradigm

• Go 1.26 से Self-service analysis model लाने का संकेत दिया गया है
  • डेवलपर्स अपने API के लिए modernizers परिभाषित और वितरित कर सकेंगे
  • केंद्रीकृत approval process के बिना इसे project स्तर पर चलाया जा सकेगा
• पहले चरण के रूप में annotation-driven inliner फीचर preview रूप में शामिल है
• आगे की योजना:
  • dynamic loading के ज़रिए user-defined analyzers चलाना (go fix या gopls के भीतर)
  • control-flow आधारित checks का सामान्यीकरण, जैसे “open के बाद close”, “lock के बाद unlock” जैसी invariant conditions की जाँच
• लक्ष्य है maintenance efficiency बढ़ाना और नवीनतम Go फीचर्स को तेज़ी से अपनाने में मदद करना

[GN⁺]

Hacker News टिप्पणियाँ

• 2024 के अंत में जब LLM code assistant तेज़ी से फैल रहे थे, यह दिलचस्प था कि ऐसे tools अपने training data की मौजूदा Go code style को ही दोहराने की प्रवृत्ति रखते हैं
  नई syntax इस्तेमाल करने को कहने पर भी वे उसे नज़रअंदाज़ कर देते थे, या कभी-कभी यह तक कह देते थे कि वह मौजूद ही नहीं है
  आगे के models में अगर नवीनतम Go 1.25 idioms दिखने हैं, तो पूरे open source code को उसी style में update करना होगा

  • PHP में भी पहले Stack Overflow की पुरानी सलाह (जैसे magic_quotes) को साफ़ करने की कोशिश हुई थी
    लेकिन LLM में एक बार गलत data चला जाए तो उसे ठीक करना लगभग असंभव होता है
    model ने किस आधार पर निष्कर्ष निकाला, यह ट्रैक करना मुश्किल है, और बस यही उम्मीद की जा सकती है कि अगला model इसे सुधार दे
  • LLM द्वारा बनाया गया Go concurrency code खास तौर पर खतरनाक होता है
    वह देखने में simple लगता है, इसलिए review पास कर जाता है, लेकिन असल में उसमें error handling और edge cases गायब होते हैं
    review के बाद उसे फिर LLM में डालो तो ऊपर-ऊपर से ठीक किया हुआ code निकलता है, लेकिन उसके अंदर data race या deadlock पैदा हो जाते हैं
    यह लगभग हर model में बार-बार दिखने वाली समस्या है
  • मुझे भी यह समस्या अक्सर हुई है
    Go की backward compatibility अच्छी है, इसलिए code compile तो हो जाता है, लेकिन code style बहुत अलग हो जाती है
    Python में API changes की वजह से असली compatibility breakage हो जाती है
    फिर भी Go, language stability और standard library की वजह से, code generation language के रूप में बेहद शानदार है
  • LLM का उपयोग आखिरकार एक जैसे और साधारण code की बाढ़ ला देगा
  • मेरा मानना है कि LLM से code लिखवाने का विचार ही छोड़ देना चाहिए
    Rob Pike की चेतावनी की तरह, यह तकनीक software ecosystem का प्रदूषण है
    बहुत से लोग ‘सुविधा’ वाला slop चाहते हैं, लेकिन समस्या की जड़ वही है

• ऐसा tool जो source code को अपने-आप latest style में बदल दे, वाकई बहुत शानदार है
  Java का OpenRewrite इसका बड़ा उदाहरण है, लेकिन दूसरी languages में ऐसा कुछ तुरंत याद नहीं आता
  Go की तरह अगर यह सुविधा language में built-in हो, तो language maturity काफी बढ़ जाती है
  लगता है आगे आने वाली नई languages, Go के इस integrated approach से सीखेंगी

  • C language में Coccinelle है, और 2009 के LWN लेख में इसका परिचय भी दिया गया था
    JetBrains IDEs एक साथ लाखों lines of code को refactor कर सकते हैं या नई syntax में auto-convert कर सकते हैं
    ConvertToPrimaryConstructor जैसी सुविधा भी है
    और Structural Search and Replace साधारण text नहीं, बल्कि language syntax level पर काम करता है
    .NET के Roslyn analyzers भी IDE में code fix suggestions देते हैं
    tutorial link
  • Rust का clippy नई syntax सुझाता है, और कुछ मामलों में auto-fix भी कर सकता है
    इसकी वजह से code काफी साफ़-सुथरा हो गया है
  • Haskell का hlint भी बहुत पहले से मौजूद है
    यह concat और map को concatMap में बदल देता है, या अनावश्यक if expressions को सरल बना देता है
  • जानना चाहता हूँ कि किसी ने TypeScript codebase को इस तरह convert किया है या नहीं
    LSP server में features की कमी है, और argument हटाने जैसी basic refactoring भी supported नहीं है
    सोच रहा हूँ कि jscodeshift और Claude को मिलाकर यह संभव हो सकता है या नहीं

• ऐसे auto-fix tools (go fix) की वजह से Go सच में एक बेहतरीन language है
  नई feature rangeint भी go fix से अपने-आप लागू होगी, यह सोचकर उत्साह है
  Go team को बधाई

  • कई बार दूसरी languages इस्तेमाल करने का मन होता है, लेकिन Go के build·test·linter tools इतने अच्छे हैं कि आखिर में Go ही चुनना पड़ता है
    compile speed भी यकीन न होने जितनी तेज़ है
  • पहले मैं खुद regex से for loops ढूँढकर बदलता था, लेकिन अब यह tool उसे कहीं ज़्यादा परिष्कृत तरीके से कर देता है

• लेख में इसका ज़िक्र नहीं था, लेकिन मेरी पसंदीदा feature //go:fix inline directive है
  यह एक line वाले function को caller में inline कर देता है
  इससे library authors पुरानी version के function को नई version में स्वाभाविक रूप से auto-migrate करा सकते हैं
  semver बदल जाए तब भी go fix से auto-upgrade संभव है

• हाल में देखे Wes McKinney podcast में
  कहा गया कि Go, तेज़ compile-run cycle, strong type system, और multithread safety की वजह से coding agents के लिए आदर्श है
  यह सुनकर Go में फिर से दिलचस्पी जगी

• Go का स्थापित tooling ecosystem और conventions agent-based development में बहुत मदद करते हैं
  go run main.go से development environment तुरंत खड़ा किया जा सकता है, और कई worktrees, central config, और migrated DB तक support किए जा सकते हैं
  housecat-inc/cheetah में ऐसे tools साझा किए गए हैं
  go generate, go build, go test, go vet वाले तेज़ loop में go fix भी जोड़ने का सोच रहा हूँ

  • बेहद तेज़ compile speed LLM के iterative experiments में भी बड़ा फ़ायदा देती है

• Python सीखते हुए लगा कि एक ही काम करने के बहुत ज़्यादा तरीके हैं और consistency नहीं है
  C की तरह अगर सिर्फ़ एक ही तरीका हो तो शायद वह बेहतर लगे
  सोचता हूँ क्या Go उस मुकाम पर पहुँच चुका है
  जानना चाहता हूँ कि क्या यह ऐसी language है जिसमें LLM की मदद के बिना भी best practices का पालन किया जा सके

  • Go काफ़ी opinionated language है, इसलिए ज़्यादातर चीज़ों के लिए एक ही तरीका होता है
    यह जटिलता से बचते हुए simplicity बनाए रखने की अच्छी कोशिश लगती है
    Python की अव्यवस्था से थक चुके लोगों को इसे recommend करूँगा

• Self-service analyzer का विचार वाकई बहुत दिलचस्प है
  लगता है बड़ी libraries या infra teams इसे सक्रिय रूप से इस्तेमाल करेंगी

• ऐसा tool हो तो लगता है backward compatibility के बिना language भी संभव हो सकती है

• TypeScript की दुनिया में biome यह भूमिका निभाता है
  उदाहरण के लिए यह forEach की जगह for...of सुझाता है, और ultracite के साथ इस्तेमाल करने पर workflow कहीं ज़्यादा smooth हो जाता है
  agents.md फ़ाइल में “fix के बाद biome fix चलाओ” लिख रखा है, और इससे code quality अपने-आप बनी रहती है
  eslint की तुलना में यह कहीं ज़्यादा हल्का और कुशल अनुभव है