C En İyisidir (2025)

(sqlite.org)

7 puan yazan GN⁺ 2026-01-07 | 8 yorum | WhatsApp'ta paylaş

SQLite, 2000 yılından beri C diliyle uygulanmış hafif bir veritabanı motoru ve başka bir dile yeniden yazılması planlanmıyor
C; performans, uyumluluk, asgari bağımlılık, kararlılık açısından SQLite için en uygun dil olarak görülüyor
Nesne yönelimli diller (C++, Java vb.) diller arası çağrı kısıtları yüksek olduğundan, yordamcı yaklaşım bazen daha basit ve daha hızlı olabiliyor
Rust veya Go gibi “güvenli diller” henüz yeterince olgun değil ve SQLite'ın kalite stratejisiyle (ör. %100 dal kapsama testi, OOM kurtarma) örtüşmüyor
Gelecekte Rust'a taşınma olasılığı açık olsa da, bunun için olgunluk, uyumluluk, performans, araç desteği gibi birçok koşulun sağlanması gerekiyor

1. C neden en iyi seçenek

SQLite, 29 Mayıs 2000'de en başından itibaren standart C diliyle uygulanmıştır ve bugün de başka bir dile geçme planı yoktur
SQLite uygulaması için C'nin uygun olma nedenleri olarak performans, uyumluluk, düşük bağımlılık, kararlılık gösteriliyor

1.1 Performans

SQLite, yoğun biçimde kullanılan düşük seviyeli bir kütüphane olduğundan yüksek hız zorunludur
- Örnek olarak “Internal Versus External BLOBs” ve “35% Faster Than The Filesystem” belgelerinde performans gösteriliyor
C, “taşınabilir assembly dili” denecek kadar donanıma yakın denetim sunarken platformlar arası taşınabilirliği de korur
Diğer diller “C kadar hızlıyız” iddiasında bulunsa da, C'den daha hızlı olduğunu söyleyen bir dil yoktur

1.2 Uyumluluk

Neredeyse tüm sistemler, C ile yazılmış kütüphaneleri çağırma yeteneği sunar
Örneğin Android, Java uygulamalarının SQLite'ı bir bağdaştırıcı üzerinden çağırmasına izin verir
Eğer SQLite Java ile yazılmış olsaydı, Objective-C veya Swift tabanlı iPhone uygulamalarında kullanılamazdı

1.3 Düşük bağımlılık

C ile yazılmış kütüphanelerin çalışma zamanı bağımlılıkları çok azdır
En küçük yapılandırmada SQLite yalnızca standart C kütüphanesindeki şu işlevlere ihtiyaç duyar
- memcmp(), memcpy(), memmove(), memset(), strcmp(), strlen(), strncmp()
Tam derlemede bile yalnızca malloc(), free() ve dosya girdi/çıktısı düzeyinde kullanıma ihtiyaç vardır
Buna karşılık modern diller, megabaytlarca çalışma zamanı ve binlerce arayüz gerektirir

1.4 Kararlılık

C, eski ve az değişen bir dil olarak açık ve öngörülebilir davranış sunar
SQLite gibi küçük, hızlı ve güvenilir bir veritabanı motoru geliştirirken, dil tanımının sık sık değişmemesi önemlidir

2. Neden nesne yönelimli bir dille yazılmadı

Bazı geliştiriciler karmaşık sistemlerin yalnızca nesne yönelimli dillerle uygulanabileceğini düşünür, ancak SQLite buna katılmaz
C++ ya da Java ile yazılmış kütüphaneler genelde yalnızca aynı dille yazılmış uygulamalarda kullanılabilir
- Buna karşılık C kütüphaneleri neredeyse tüm dillerden çağrılabilir
Nesne yönelimlilik, bir tasarım desenidir; dilin kendisi değildir, C içinde de nesne yönelimli yapılar kurulabilir
Nesne yönelimlilik her zaman en iyi seçenek değildir; bazı durumlarda yordamcı kod daha basit olup bakım ve performans açısından daha avantajlıdır
SQLite'ın ilk geliştirme döneminde (2000'lerin başı) Java olgun değildi, C++ ise derleyiciler arası uyumluluk sorunları yaşıyordu
- O dönemde C açıkça daha iyi bir seçimdi ve bugün de yeniden yazımın getirisi neredeyse yoktur

3. Neden “güvenli bir dil” ile yazılmadı

Son yıllarda Rust ve Go gibi “güvenli diller” ilgi görüyor olsa da SQLite hâlâ C ile sürdürülüyor

SQLite'ın ilk 10 yılında güvenli diller yoktu
- Go veya Rust ile yeniden yazmak mümkün olabilir, ancak yeni hata üretme ve hız kaybı riski vardır
Güvenli diller, dizi sınırı denetimi gibi ek dallar (branch) ekler
- Doğru çalışan kodda bu dallar hiç yürütülmeyeceği için, %100 dal testi mümkün olmaz
Güvenli dillerin çoğu, bellek yetersizliği (OOM) durumunda programı durdurur
- SQLite ise OOM durumunda da düzgün toparlanacak şekilde tasarlanmıştır; bu da söz konusu davranışla çelişir
Mevcut güvenli dillerin hepsi yenidir ve hızla değişmektedir
- SQLite ise eski ve kararlı dilleri tercih eder

4. Rust'a taşınma olasılığı

SQLite'ın Rust ile yeniden yazılma ihtimali vardır, ancak Go'ya taşınması neredeyse imkânsızdır
- Gerekçe: Go, assert() kullanımını sevmez
Rust'a taşınma için gereken ön koşullar
1. Rust'ın daha olgun hale gelmesi ve değişim hızının yavaşlayarak “eski ve kararlı bir dil” niteliği kazanması
2. Rust'ın her dilden çağrılabilen genel amaçlı kütüphaneler üretebilmesi
3. İşletim sistemi olmayan gömülü aygıtlarda da çalışabilecek nesne kodu üretebilmesi
4. %100 dal kapsama testi destekleyen bir araç ekosistemine sahip olması
5. OOM kurtarma mekanizması sunması
6. C düzeyinde performans kaybı olmadan uygulama yapılabildiğini kanıtlaması
Rust'ın bu koşulları sağladığını düşünen geliştiriciler, SQLite ekibiyle doğrudan iletişime geçip bunu tartışabilir

5. Sonuç

SQLite, küçük, hızlı ve güvenilir bir veritabanı motorudur; C dilinin özellikleri bu hedefle uyumludur
Nesne yönelimli ya da güvenli dillere geçişin uyumluluk, performans ve kalite yönetimi açısından somut bir faydası yoktur
C'nin sadeliği ve kararlılığı, SQLite'ın uzun vadeli bakımını ve güvenilirliğini destekler

8 yorum

ndrgrd 2026-01-10

Zaten PR da kabul etmeyen bir proje, yani... Kendi kullanmak istediklerini kullanıyorlar işte.

skrevolve 2026-01-09

Eğer durum compact ise, C, C++ ve Rust’ın yerini alacak bir dil yok. Yapılarda veya map’lerde bit düzeyinde overflow ya da hacklenme endişesiyle geliştirme yapmayı anlayışla karşılayacak geliştirici sayısı da pek fazla değil zaten.

2026-01-08

[Bu yorum gizlendi.]

aqqnucs 2026-01-08

Başlık fazla kışkırtıcı. Orijinal yazıya bakarsanız, neden C'nin sqlite geliştirmek için en uygun dil olduğuna dair bir yazı olduğunu görürsünüz. Herkes sakin olsun.

aqqnucs 2026-01-08

Yok artık, hatta yazının kendisi bile 7 yıl önce yazılmış galiba? Sonradan içeriğe bir şeyler ekleyip 2025'te kısmen güncellemişler gibi duruyor... 🤦

wahihi 2026-01-08

Farklı geliştirme durumlarında uygun dili kullanabilmek, böyle bir değerlendirme yapabilmek önemlidir; sanki belirli bir dil her zaman iyiymiş gibi böyle bir başlık atmak ise düşünce seviyesinin ortaokul mezunu düzeyinde olduğunu gösterir...

m00nny 2026-01-08

Bence C'nin en büyük avantajı, "bilgisayar bir bit dizisidir" özüne doğrudan temas etmesinden geliyor. C'nin basit felsefesi ve agresif reinterpret cast kullanımı sayesinde, kullanıcı neredeyse her zaman bunun hangi makine diline çevrileceğini tahmin edebiliyor; çekiciliği de burada yatıyor. Her dil C olduğu için her dilden çağrılabilir değildir; çağrılabilir olan şey ABI'dir ve C'de bunun nedeni sadece girdinin ve çıktının hangi bit dizisi olduğunun öngörülebilir olmasıdır (ya da öyle olması gerekmesidir). Uygulanabilirlik hakkında tartışırken de, bunun Turing makinesinde mi imkânsız olduğu yoksa şu anda kullandığımız dilde ya da framework'te mi imkânsız olduğu ayrımının önemli olduğunu düşünüyorum.

GN⁺ 2026-01-07

Hacker News görüşleri

Her projenin ya da programcının neden Rust veya Zig kullanmadığını özellikle gerekçelendirmesi gerekmediğini düşünüyorum
Hacker News ve diğer platformlarda bu dillerin gereğinden fazla öne çıkarılma eğilimi var
C ile yeterince iyi sonuçlar alınıyor ve kullanıcılar da memnunsa, dışarıdan birilerinin buna karışması için sebep yok
- Yeni dillerin ilgi görmesi elbette doğal
  Teknolojik gelişmeyle ilgilenen insanların yeni dillerin potansiyelini keşfetmesi doğal bir akış
  Ama dışarıdan fikir belirtmek serbest olsa da, projelerin bunları dinleme zorunluluğu yok
- Rust'ın tasarım felsefesi ve yakın zamandaki Linux çekirdeğindeki Rust hata örnekleri düşünüldüğünde, Rust kusursuz bir çözüm değil
  Rust hataların ortaya çıkmasını azaltıyor ama aynı tür hatalar hâlâ varlığını sürdürüyor
  C geliştiricileri yarış durumlarına karşı daha hassas tepki verme eğilimindeyken, Rust'ta 'güvenli' etiketlerine aşırı güvenme riski var
  Ayrıca Rust'ta düzeltmeler her zaman basit olmadığından refactoring yükü daha büyük olabilir
  Sonuçta Rust ilginç bir dil ama her derde deva değil ve dayatılmamalı
- Bugünlerde OOP'ye yönelik şüphecilik daha da artıyor
  Rust ve Zig gibi diller, geleneksel nesne yönelimli kalıplardan uzaklaşma niyeti taşıyor
  OOP bir zamanlar bir 'aydınlanma' sağlayan kavramsal çerçeve olarak cazipti, ama pratikte çoğu zaman karmaşıklığı artırıyor ve modülerliğe zarar veriyor
- Eğer Rust her açıdan daha iyiyse ve hataları azaltıyorsa, insanların onu övmesi garip değil
  El matkabı yerine elektrikli matkap kullanmanın doğal olması gibi, daha iyi bir araç varsa onu kullanmak da doğal
- ABD hükümeti yakın zamanda bellek güvenli olmayan dillerin (C vb.) kullanımının bırakılmasını tavsiye etti
  Ama güvenli C kodu yazmayı sağlayacak araçların ve eğitimin de yeterince gelişmesi gerekiyor
Ben oldukça ciddi bir Rustacean'ım ama her projeyi Rust ile yeniden yazmanın mantıklı olduğunu düşünmüyorum
Zaten iyi doğrulanmış bir C projesini Rust'a taşımak, kısa vadede hatta hata sayısını artırabilir
Yine de bazıları Rust ile yeniden yazımı deniyor; örneğin Limbo: SQLite'ın Rust ile tamamen yeniden yazıldığı proje var
- Limbo ilginç ama çoklu süreç erişimi olmaması büyük bir kısıt
  SQLite'ın başlıca avantajlarından biri birden fazla süreçten aynı anda erişilebilmesi; bu olmayınca kullanım alanı daralıyor
- Rust geliştiricilerinin özellikle SQLite'ın onayını beklemesi gerekmiyor
  Doğrudan yeni bir sürüm yapıp başarılı olup olmayacağını deneyebilirler
- Kişisel olarak SQLite'ı port etmektense Rust ile yeni bir embedded DB yapmanın daha mantıklı olduğunu düşünüyorum
- Limbo'nun nasıl gelişeceğini izlemeyi düşünüyorum
RediSearch'i Rust'a taşıma deneyimim oldu
Bunun nedeni son dönemde çok sayıda CVE zafiyeti görülmesiydi
SQLite'ta böyle bir sorun yoksa, onu Rust'a taşımanın gerekçesi zayıf kalır
Rust'ın güçlü ve zayıf yönlerini gerçekten anlamak için onlarca yıl gerekecek gibi görünüyor
Özellikle GUI uygulamalarında Rust'ın ne kadar faydalı olduğu henüz net değil
- C'nin istikrarı ve 'sıkıcılığı', onlarca yıllık deneme-yanılmanın sonucunda elde edildi
  Rust'ın aynı düzeyde güven kazanması için belki 2040'ları beklemek gerekecek
- SQLite gibi sistemler için Ada/SPARK gibi diller daha uygun olabilir
Linus'un da belirttiği gibi, Rust'ta OOM (Out of Memory) kurtarma mekanizmasına ihtiyaç var
İlgili içerik için LKML tartışma bağlantısına bakılabilir
- Ancak Rust'ın dil özellikleri temelde zaten stack allocation odaklı; doğrudan malloc çağırmıyor
  Embedded veya kernel kodunda allocation işlevleri tamamen kapatılabiliyor da
  Yani Rust zaten bellek üzerinde tam kontrol sağlıyor
- (Küçük not) O sayfanın CSS'ini iyileştiren kod da paylaşıldı
- Linus'un eleştirisi doğru ama kendi tarafındaki sorunların da toparlanması gerekiyor
“C'den daha hızlı genel amaçlı dil yok” iddiası, geliştirici zamanını yok sayan eksik bir karşılaştırma
C ile 5 saatte 4 saniyelik bir program yazmak yerine, başka bir dille 5 dakikada 5 saniyelik bir program yazmak daha gerçekçi olabilir
- Ama SQLite gibi kullanıcı CPU zamanının ezici biçimde baskın olduğu yazılımlarda C'nin verimliliği çok daha önemli
  Kullanıcı sayısı arttıkça küçük hız farklarının bile biriken değeri büyür
- Sonuçta kullanıcı zamanını önemsiyorsanız, C'nin performans optimizasyonu hâlâ büyük anlam taşıyor
Rust'ın 'sıkıcı ve kararlı' bir dil hâline gelmesine daha çok var
C, muhafazakâr bir komite tarafından yönetiliyor ve uyumluluğu titizlikle koruyor; Rust ise sorunları çözmek için uyumluluktan çok yeniliğe öncelik veriyor
- Rust, dilin kendisinde zaman zaman uyumluluğu bozsa da araç zinciri kararlı
  Eski sürümlerle yazılmış kodlar yeni derleyicilerle de derlenmeye devam edebiliyor
- Rust, eski kodu eski derleyicilerle otomatik olarak ele alıp legacy yükünü azaltan bir yaklaşım benimsiyor
  Bunun, C++ gibi geçmişteki özellikleri sürekli sırtında taşıyan yaklaşımdan daha iyi olduğunu düşünüyorum
- C'nin muhafazakârlığı 'garip' değil, istikrarın simgesi
- C başlangıçta güçlü görüşleri olan tek bir kişi tarafından tasarlandığı için net bir yönü vardı
  Buna karşılık C++ veya Common Lisp gibi komite tasarımı dillerde karmaşıklık arttı
  Rust da ölçek olarak büyük olduğundan embedded veya çekirdek sistemlerde dikkatli kullanılmalı
- Rust da bir gün istikrar dönemine girebilir gibi görünüyor
“İyi çalışan şeyi gereksiz yere bozmayalım” yaklaşımına katılıyorum
Dil gelişiminin tarihi, problemleri çözmeye çalışırken yeni karmaşıklıklar üretmenin tekrarından ibaret gibi
- Mozilla'nın Rust'ı yaratma nedeni C++'ın sorunlarıydı, ama Rust sadece C++'ın yerine geçen bir şey değil
  C, “Worse is Better” felsefesinin en tipik örneklerinden biri ve sadeliği sayesinde onlarca yıl başarılı oldu
  Rust ise tersine “Right Thing™” yaklaşımını hedefliyor
  Bugün çoğu ortamda doğrudan uygulama yükü azaldığı için artık daha iyi bir seçenek olabilir
  Ama zaten başarılı olmuş projeleri sırf bunun için taşımak gerekmiyor
  Yeni projelerde ise Rust'ın daha iyi tercih olma ihtimali yüksek
C'nin sadeliği ve istikrarı yeterince takdir edilmeyen avantajlar
Dili sürekli değiştirmektense standart kütüphaneyi veya ekosistemi iyileştirmenin daha iyi olduğunu düşünüyorum
- Yine de C'de hâlâ çok fazla UB (undefined behavior) var; dikkatli olmak gerekiyor
  Sadece sadelik değil, deterministik davranış garantisi de önemli
- Clojure gibi sade, zarif ve kararlı dilleri tercih ediyorum
- C yeni özellikler eklese bile bunların çoğu tartışmasız pratik iyileştirmeler oluyor
  Örneğin designated initializer, compound literal, alignas, memset_explicit gibi özellikleri beğeniyorum
Kişisel olarak C'nin hâlâ en iyisi olduğunu düşünüyorum
Rust'ta çok sayıda iyi fikir var ama dezavantajları da belirgin bir dil
Şimdilik Rust'ın sorunlarını soğukkanlı biçimde tartışmanın zor olduğu bir atmosfer var
- Rust'ın eksilerinin ne olduğuna daha somut biçimde işaret edilirse tartışma daha verimli olabilir
  Örneğin öğrenme eğrisi veya paketleme karmaşıklığı gibi alanlar sayılabilir
- “Rust korkunç bir dil” iddiası somut gerekçeler gerektiriyor
“Her sistem C kütüphanelerini çağırabilir” sözü artık doğru değil
Rust ve Zig de bu gereksinimi karşılıyor
Ancak Rust'ın standart kütüphanesi OOM durumunda kurtarma yerine panic etme eğiliminde ve belgelendirmesi de yetersiz
- Rust ve Zig'de C ABI uyumluluğu için açıkça extern "C" veya export kullanmak gerekiyor
  Aksi hâlde ABI tanımlı olmadığından durum C++'tan bile daha kararsız olabilir
  Özellikle Rust crate dağıtan Linux dağıtımlarında bu sorun daha da büyüyebilir