Geri Dön

Go'dan Rust'a geçiş: backend ekipleri için gerçekte ne değişiyor
SiTech AI Team3 dk okuma

Go'dan Rust'a geçiş: backend ekipleri için gerçekte ne değişiyor

corrode.dev, servisleri Go'dan Rust'a taşımaya odaklanan bir rehber yayımladı. Temel savı şu: soru Rust'ın daha hızlı olup olmadığı değil, derleyicinin hangi garantileri verdiği; değişen şey doğruluk garantileri ve geliştirici ergonomisidir.

corrode.dev, servisleri Go'dan Rust'a taşımaya odaklanan bir rehber yayımladı. Rehberin temel savı şu: çoğu ekip için soru Rust'ın daha hızlı olup olmadığı değil — Go tipik backend yükleri için zaten yeterince hızlı — derleyicinin hangi garantileri verdiğidir. Gerçekte değişen şey doğruluk garantileri, çalışma zamanı davranışı ve geliştirici ergonomisidir.

Pratikte ne değişiyor

Araç zinciri neredeyse bire bir örtüşüyor: cargo build, run, fmt, test ve doc, Go'nun karşılık gelen komutlarıyla aynı işi yapıyor. Asıl değişim, kontrollerin nerede yapıldığında. nil yönetimi, hata yayılımı, veri yarışları ve kaynak ömürleri geleneklerden tip sistemine taşınıyor: Option ve Result, nil kontrollerinin ve if err != nil kalıbının yerini alıyor; değiştirilebilir durumun iş parçacıkları arasında paylaşılması ise Send ve Sync tiplerini gerektiriyor. İş parçacıkları arasında paylaşılan sade bir hash tablosu derlenmez — kilitli bir tipe sarılması ya da bir kanalla değiştirilmesi gerekir.

Ekipler neden bu geçişi düşünüyor

Rehber, Go servislerinde biriken sorunları sıralıyor: ayrıntılı hata yönetimi, üretimde ortaya çıkan nil işaretçi panikleri ve çalışma zamanı yarış dedektörünün sınırları — go test -race yalnızca test sırasında gerçekten çalışan yarışları bulur; kilitsiz değiştirilen bir map ise derlenip yük altında çöker. InfluxData'nın kurucusu ve CTO'su Paul Dix'in, InfluxDB'nin Go'dan Rust'a yeniden yazılmasının ekibine kazandırdıklarına dair sözleri alıntılanıyor: "korkusuz eşzamanlılık — daha önce yaşadığımız veri yarışlarını fiilen ortadan kaldırmak."

Yeniden yazmadan geçiş

Önerilen yol, baştan sona yeniden yazmak yerine aşamalı ilerlemek: tek bir sıcak yolu veya arka plan sürecini aynı API sözleşmesinin arkasında ayırın ya da bir API geçidinin arkasında strangler deseniyle seçili uç noktaları yeni bir Rust servisine yönlendirin. Sınırları net ve etki alanı küçük bir servisle başlayın; yolları, JSON biçimlerini ve hata zarfını aynı tutun; Go tadında Rust yazmaktan kaçının — tek metotlu arayüzler genellikle dinamik dağıtım yerine generic üzerinde trait sınırına dönüşür. Rehber, eğitimin erkenden ve gerçek kod üzerinde yapılması gerektiği uyarısında bulunuyor, çünkü Rust'ta derleme süreleri Go'ya kıyasla gerçekten kötüleşiyor.

Ekipler ne kazanıyor, Go nerede kalıyor

Beklenen kazanımlar vaat değil, yaklaşık rakamlar olarak veriliyor: CPU kullanımında %20–40 azalma, bellekte %30–50 düşüş, yük altında daha istikrarlı p99 gecikmesi ve çok daha az üretim olayı; çünkü go test -race'ten sağ çıkan hata sınıfları — veri yarışları, nil başvuruları, atlanan hata yolları — Rust'ta derlenmiyor. On kat verim artışı ise gündemde değil. Aynı netlikle nelerin Go'da kalması gerektiği de söyleniyor: Kubernetes operatörleri ve kontrolörleri, CLI ve geliştirici araçları, ayrıca ince API ve biçim dönüştürme servisleri. Canonical mühendislik başkan yardımcısı Jon Seager, Go'nun "ağ servisleri için çok iyi bir seçim" olduğunu söylüyor. Birçok ekip çok dilli bir backend'e varıyor: sıkıcı servisler için Go, güvenilirliğin ve performansın ek emeği karşıladığı yerde Rust.

SiTech

SiTech — AI destekli web geliştirme

Hızlı ve modern web siteleri kuruyor, AI'yı gerçek iş akışlarına taşıyoruz. Projeniz veya sorunuz mu var? Yardımcı olmaktan mutluluk duyarız.