Go-დან Rust-ზე გადასვლა: რა იცვლება რეალურად ბექენდ გუნდებისთვის

corrode.dev-მა გამოაქვეყნა ბექენდზე ორიენტირებული გზამკვლევი სერვისების Go-დან Rust-ზე გადაყვანის შესახებ. მისი მთავარი არგუმენტია, რომ გუნდების უმეტესობისთვის საკითხი იმაში არ არის, სწრაფია თუ არა Rust — Go ტიპური ბექენდ დატვირთვისთვის საკმარისად სწრაფია — არამედ იმაში, თუ რა გარანტიებს იძლევა კომპილატორი. რეალურად იცვლება სისწორის გარანტიები, რანტაიმის ქცევა და დეველოპერის ერგონომიკა.

რა იცვლება პრაქტიკაში

ინსტრუმენტების ნაკრები თითქმის ერთი-ერთში ემთხვევა: cargo build, run, fmt, test და doc იგივე საქმეს აკეთებენ, რასაც Go-ს ბრძანებები. მთავარი ცვლილება ისაა, თუ სად ხდება შემოწმებები. nil-ის დამუშავება, შეცდომების გავრცელება, მონაცემთა რბოლები და რესურსების სიცოცხლის ციკლი კონვენციებიდან ტიპების სისტემაში გადადის: Option და Result ცვლის nil-ის შემოწმებასა და if err != nil-ს, ხოლო ნაკადებს შორის მონაცემების გაზიარება Send და Sync ტიპებს მოითხოვს. უბრალო hash ცხრილის ნაკადებს შორის გაზიარება არ კომპილირდება — ის ან ბლოკირებად ტიპში უნდა შეიფუთოს, ან არხით ჩანაცვლდეს.

რატომ განიხილავენ გუნდები ამ გადასვლას

გზამკვლევი ჩამოთვლის იმ პრობლემებს, რომლებიც Go-ს სერვისებში გროვდება: შეცდომების დამუშავების სიჭარბე, nil-პოინტერის პანიკის რისკი, და რანტაიმზე დაფუძნებული რბოლების დეტექტორის შეზღუდვები — go test -race პოულობს მხოლოდ იმ რბოლებს, რომლებიც ტესტირების დროს რეალურად სრულდება, სანამ დაბლოკვის გარეშე შეცვლილი ცხრილი მშვიდად კომპილირდება და დატვირთვის ქვეშ ვარდება. InfluxData-ს დამფუძნებელი და CTO პოლ დიქსი ციტირებულია იმაზე, თუ რა მისცა გუნდს InfluxDB-ის Go-დან Rust-ზე გადაწერამ: „უშიშარი კონკურენტულობა — პრაქტიკულად მონაცემთა რბოლების აღმოფხვრა, რომლებიც ადრე გვქონდა.“

გადასვლა გადაწერის გარეშე

გზამკვლევი ეტაპობრივ მიდგომას გვირჩევს და არა სრულ გადაწერას: გამოყავით ერთი ცხელი გზა ან ფონური პროცესი იმავე API კონტრაქტის მიღმა, ან API-გეითვეის მიღმა strangler-ის პატერნით ცალკეული ენდპოინტები ახალ Rust სერვისზე გადაამისამართეთ. დაიწყეთ სერვისით, რომელსაც მკაფიო საზღვრები და მცირე გავლენის არეალი აქვს, შეინარჩუნეთ ბილიკები, JSON სტრუქტურა და შეცდომების ფორმატი უცვლელად, და თავი შეიკავეთ Go-ს სტილში დაწერილი Rust-ისგან — ერთმეთოდიანი ინტერფეისები ჩვეულებრივ გენერიკის trait-ის შეზღუდვად იქცევა. ტრენინგი ადრე და რეალურ კოდზე უნდა მოხდეს, რადგან Rust-ის კომპილაციის დრო Go-სთან შედარებით ნამდვილად უარესდება, ხოლო borrow checker-თან პირველი თვე ყველაზე რთულია.

რას იძლევა და სად რჩება Go

მოსალოდნელი სარგებელი მიახლოებით ციფრებადაა მოცემული და არა დაპირებად: CPU-ის მოხმარება 20–40%-ით მცირდება, მეხსიერება 30–50%-ით, p99 დაყოვნება დატვირთვის ქვეშ უფრო სტაბილური ხდება, ხოლო პროდაქშენის ინციდენტები საგრძნობლად მცირდება, რადგან ის ხარვეზები, რომლებიც go test -race-ს გადაურჩება — მონაცემთა რბოლები, nil-ის დერეფერენსირება, გამოტოვებული შეცდომის გზები — Rust-ში უბრალოდ არ კომპილირდება. გზამკვლევი ასევე ცხადად ამბობს, რა უნდა დარჩეს Go-ზე: Kubernetes-ის ოპერატორები და კონტროლერები, CLI და დეველოპერის ინსტრუმენტები, ასევე თხელი API და ფორმატების კონვერტაციის სერვისები. Canonical-ის ინჟინერინგის ვიცე-პრეზიდენტი ჯონ სიგერი ციტირებულია: Go რჩება „ძალიან კარგ არჩევანად ქსელური სერვისებისთვის“. ბევრი გუნდი პოლიგლოტ ბექენდით სრულდება: Go მოსაწყენი სერვისებისთვის, Rust იქ, სადაც საიმედოობა და წარმადობა დამატებით ძალისხმევას იხდის.