Postgres Rust ile yeniden yazıldı, artık Postgres regresyon testlerinin %100’ünü geçiyor

 (github.com/malisper)
1 puan yazan GN⁺ 5 시간 전 | 1 yorum | WhatsApp'ta paylaş
  • pgrust, Postgres 18.3 uyumluluğunu hedefleyen bir Rust ile yeniden yazım projesi ve 46.000’den fazla regresyon sorgusunda Postgres’in beklenen çıktısıyla eşleşiyor
  • Mevcut Postgres 18.3 veri dizininden önyükleme yapabilen disk uyumluluğuna sahip ve gerçek Postgres testlerini davranış ölçütü olarak kullanıyor
  • Şu anda prodüksiyona hazır değil ve performans optimizasyonu da henüz yapılmadı; mevcut Postgres eklentileri ile PL/Python, PL/Perl, PL/Tcl gibi prosedürel dil eklentileri genel olarak uyumlu değil
  • WebAssembly demosu ve Docker imajı malisper/pgrust:v0.1 ile denenebiliyor; latest şu anda aynı sürümü işaret etse de sabit çalıştırma imajı v0.1
  • Yol haritasında çok iş parçacıklı Postgres iç yapısı, yerleşik bağlantı havuzu, JSON odaklı iş yükü iyileştirmeleri, no-vacuum depolama denemeleri ve yapay zeka tarafından üretilen SQL için çalışma zamanı guardrail’leri yer alıyor

pgrust’ün hedefi ve uyumluluğu

  • pgrust, Postgres’i Rust ile yeniden yazan bir proje
  • Hedef sürüm Postgres 18.3 ve 46.000’den fazla regresyon sorgusunda Postgres’in beklenen çıktısıyla eşleşiyor
  • Mevcut Postgres 18.3 veri dizininden önyükleme yapabilen disk uyumluluğu sunuyor
  • Projenin amacı, Postgres’i içeride daha kolay değiştirilebilir hale getirmek
    • Davranışı Postgres biçiminde korumak
    • Gerçek Postgres testlerini ölçüt olarak kullanmak
    • Rust ve yapay zeka destekli programlama ile daha derin sunucu değişikliklerini araştırmak

Mevcut durum ve sınırlamalar

  • pgrust henüz prodüksiyona hazır değil
  • Henüz performans optimizasyonu yapılmadı
  • Mevcut Postgres eklentileri ve prosedürel dil eklentileri genel olarak henüz uyumlu değil
    • PL/Python
    • PL/Perl
    • PL/Tcl
  • Bazı paketlenmiş contrib modülleri zaten port edildi ve zaman içinde daha fazla uyumluluk mümkün olabilir

Çalıştırma yöntemi

  • WebAssembly demosu https://pgrust.com adresinde denenebilir
  • Docker ile çalıştırmak için malisper/pgrust:v0.1 imajı kullanılıyor
    • İmajın içindeki psql istemcisi kullanılıyor
    • malisper/pgrust:latest şu anda aynı sürümü işaret ediyor
    • Sabit sürüm imajı v0.1
docker run -d --name pgrust -e POSTGRES_PASSWORD=secret malisper/pgrust:v0.1 && until docker exec -e PGPASSWORD=secret pgrust psql -h 127.0.0.1 -U postgres -c '\q' >/dev/null 2>&1; do sleep 1; done && docker exec -it -e PGPASSWORD=secret pgrust psql -h 127.0.0.1 -U postgres; docker rm -f pgrust

Kaynaktan derleme ve çalıştırma

  • macOS’ta icu4c, openssl@3, libpq gerekiyor
brew install icu4c openssl@3 libpq

export LIBRARY_PATH="$(brew --prefix openssl@3)/lib:${LIBRARY_PATH:-}"
export PKG_CONFIG_PATH="$(brew --prefix openssl@3)/lib/pkgconfig:$(brew --prefix icu4c)/lib/pkgconfig:${PKG_CONFIG_PATH:-}"
export PATH="$(brew --prefix libpq)/bin:$PATH"
  • Debian/Ubuntu’da derleme araçları ile ICU, OpenSSL, LDAP, PAM ve Postgres 18 istemcisi kuruluyor
sudo apt-get update
sudo apt-get install -y build-essential pkg-config libicu-dev libssl-dev libldap2-dev libpam0g-dev postgresql-client-18
  • Derleme, vendored Postgres 18.3 shared directory belirtilerek cargo build ile yapılıyor
PGRUST_PGSHAREDIR="$PWD/vendor/postgres-18.3/share" \
cargo build --release --locked --bin postgres
  • Veri dizini, pgrust’ün --initdb seçeneğiyle oluşturuluyor
target/release/postgres --initdb \
  -D /tmp/pgrust-data \
  -L "$PWD/vendor/postgres-18.3/share" \
  --no-locale \
  --encoding UTF8 \
  -U postgres
  • Çalıştırırken yığınla ilgili ayarlar ve senkron I/O ayarı birlikte kullanılıyor
ulimit -s 65520

RUST_MIN_STACK=33554432 target/release/postgres \
  -D /tmp/pgrust-data \
  -F \
  -c listen_addresses= \
  -k /tmp \
  -p 5432 \
  -c io_method=sync \
  -c max_stack_depth=60000

Regresyon testleri ve doğrulama sonuçları

  • Postgres regresyon testleri scripts/run-regression ile çalıştırılıyor
PGRUST_BIN="$PWD/target/release/postgres" \
scripts/run-regression
  • Test çalıştırıcısı, pgrust’ün kendi --initdb seçeneğini ve depoya dahil edilen Postgres 18.3 test dosyalarını kullanıyor
  • PATH içinde Postgres 18 psql istemcisi gerekiyor
    • Farklı bir konumdaysa PGRUST_PSQL=/path/to/psql ayarlanıyor
  • Doğrulanan sürüm sonucu, pgrust’ün 46.000’den fazla regresyon sorgusunda Postgres’in beklenen çıktısıyla eşleştiğini gösteriyor

Yol haritası ve proje geçmişi

  • Yol haritasında şu maddeler yer alıyor

    • Çok iş parçacıklı Postgres iç yapısı

      • Yerleşik bağlantı havuzu
      • JSON odaklı iş yükleri için destek iyileştirmeleri
      • Hızlı fork ve branching iş akışları
      • no-vacuum tasarımı içeren depolama denemeleri
      • Hatalı sorgular ve yapay zeka tarafından üretilen SQL için çalışma zamanı guardrail’leri
      • Ani kötü yürütme planı geçişlerini azaltma
      • Mevcut depo, regresyon testi kilometre taşına ulaşmış daha yeni pgrust uygulamasını içeriyor
      • Önceki genel uygulama archive/pre-fabled-2026-06-23 içinde arşivlenmiş durumda
      • İlgili arka plan bağlantıları
      • Original pgrust launch
      • 67% regression update
      • Four Horsemen roadmap
      • Lisans AGPL-3.0

İlgili okumalar

1 yorum

 
GN⁺ 5 시간 전
Hacker News yorumları

  • Orijinal yazar benim. Bunun buraya düşeceğini bilmiyordum. Özetle, LLM ile daha iyi bir Postgres yapmayı denediğim bir deney yürütüyordum ve Postgres 30 yıllık olduğundan, bu süre içinde veritabanları hakkında çok şey öğrendiğimizi düşünüyorum
    Yeniden yazımda işe yarayan pek çok teknik, yeniden tasarımda da işe yarıyor. Henüz yayımlamadığım yeni pgrust sürümü şu anda Postgres regresyon testlerini %100 geçiyor, Postgres'in süreç-başına bağlantı modeli yerine bağlantı başına thread modeli uyguluyor ve işlem iş yüklerinde Postgres'ten %50 daha hızlı, analitik iş yüklerinde ise yaklaşık 300 kat daha hızlı
    Şu anda clickbench'te ClickHouse'tan 2 kat daha yavaş, ama ClickHouse'tan daha hızlı olabileceğini düşünüyorum. Sorunuz varsa yanıtlarım

    • Bağlantı başına thread performans açısından neredeyse her zaman doğru seçimdir, ancak Postgres'in bağlantı başına süreç seçmesi sayesinde şüpheli eklentileri istediğiniz gibi yükleyebiliyorsunuz. En kötü durumda tüm veritabanı değil sadece o süreç çöküyor. Eklentide segmentasyon hatası olsa bile tüm sistem yerine yalnızca bazı bağlantıların ölmesi gibi bir denge noktası olsa güzel olurdu
    • OLTP'de %50 iyileşme biraz şüpheli geliyor. Kanıtsızca yüklenmek istemiyorum ve ben de sık sık benchmark iddiaları ortaya atarım, ama standart benchmark kullanıldığını bilsem de içime bir kurt düşüyor
      Bir yerlerde MVCC'yi bozup üretimde kullanılamayacak bir ödün vermiş olabilirsiniz. Regresyon testlerini geçtiğini gördüm. Acaba fsync açık mı? Bildiğim kadarıyla regresyon testleri kötü I/O kalıplarını yakalamakta iyi değil. Yine de eğlenceli bir proje gibi görünüyor
    • Postgres ve genel olarak veritabanları konusunda gerçek geçmişinizi ve uzmanlığınızı merak ediyorum. Sonuçta ne yaptığınızı gerçekten tam olarak bilip bilmediğinizi, yoksa farkında olmadığınız dev mayınların mı gizlendiğini anlamak istiyorum
    • Bu bir ürün lansmanından çok bir deney gibi duruyordu, ama biri sizi HN spot ışıklarının altına itmiş gibi görünüyor. Bunun LLM kodlamayla nereye kadar gidilebileceğini görmeye yönelik bir deney mi, yoksa önce bir şey inşa edip ardından LLM'in yazdığı kodun ne kadarını kabul edebileceğinizi görmeye yönelik bir deney mi olduğunu merak ediyorum
    • Analitik iş yüklerinde Postgres'ten yaklaşık 300 kat hızlı ve ClickHouse'tan 2 kat yavaş olması, verileri kolon odaklı biçimde sakladığınız anlamına mı geliyor? Yoksa hem satır odaklı hem kolon odaklı yapıyı birlikte mi kullanıyorsunuz?
      Ben de benzer ama farklı bir iş olarak δx geliştiriyorum. Bu, sıradan Postgres tablolarının içinde kolon odaklı sıkıştırılmış veri saklayan bir Postgres eklentisi; bu sayede replikasyon, felaket kurtarma, pg_dump vb. aynen çalışıyor: https://github.com/xataio/deltax
      Şu anda tek düğümde ClickHouse'tan %30-40 daha yavaş. clickbench'e ekleyen PR yeni kabul edildi, karşılaştırmayı burada görebilirsiniz: https://benchmark.clickhouse.com/#system=+liH|_etx|gQ|saB&ty...

  • Bu tür yeniden yazımları pek anlamıyorum. Genelde tek bir kişi tarafından sürükleniyorlar ve bu da kolayca tek hata noktası yaratıyor; ayrıca çok kısa sürede ortaya çıkıyorlar, bu yüzden projeyi istikrarlı biçimde geliştirecek disiplini edinmiş olduklarını düşünmek zor
    Orta ve uzun vadede yaşama şansları da düşük görünüyor. Katkı yapmak isteyenlerin de token maliyeti ödemesi gerekiyor. Çünkü AI olmadan bu tür projeleri sürdürmek giderek zorlaşıyor. Bunu üretime koymak isteyen biri olur mu? Pek mantıklı gelmiyor

    • Bu sadece basit bir yeniden yazım değil, iyileştirmeler de var. Ben de eğlence olsun diye benzer bir şey yaptım; eski tasarımı ve özellikle PostgreSQL tarafındaki insanların “başka türlü yapılamaz” dediği kısımları iyileştirmenin mümkün olup olmadığını görmek istedim. Gerçekten de farklı yapılabiliyor
      Bunu üretime koymam ama veritabanı iç işleyişi hakkında çok şey öğrendim. LLM çağında bile zihnimi canlı tutmak için, kendi üretim veritabanımızda da LLM kullanmadan veritabanı özellikleri geliştiriyorum. Şu sıralar Flexible Paxos ile uğraşıyorum; muhtemelen eski, kararlı ve basit Raft'ı kullanmaya devam edeceğiz ama yine de ilginç
    • Bunu ilginç bir kavram kanıtı olarak görüyorum. Mesele yalnızca PostgreSQL'i Rust ile yeniden yazmak değil; seçilen bağımlılıkları, thread modelindeki değişikliği ve diğer mimari değişikliklerin olasılığını da test ediyor
      LLM'ler prototipleri inanılmaz hızlı çıkarmakta çok iyiler ve çalışan bir prototip pek çok varsayımı ortadan kaldırabiliyor. Orijinal ekip ya da ona yakın büyüklükte ciddi bir ekip desteği olmadan ve özgün kodun kalite ile bakım seviyesine ulaştığına ya da onu aştığına dair güvenilir bir açıklama bulunmadan, böyle devasa bir projenin yeniden yazılmış sürümünü kullanacağımı sanmıyorum
      Genel olarak LLM ile lisans aklama yapmanın hukuken ve etik olarak savunulmasının zor olduğunu düşünüyorum. Ama bu örnek farklı, çünkü burada daha kısıtlayıcı bir lisans seçilmiş. Avukat değilim ama PostgreSQL'i indirip s/MIT/AGPL/ yaparak dağıtmanın yasal olarak mümkün olduğunu anlıyorum. Orijinal MIT lisanslı sürüm zaten var olmaya devam ediyor; bu yüzden ikna edici yeni özellikler ortaya çıkana kadar özellikle bu sürümü tercih etmek için bir neden yok
    • Tam olarak aynı değil ama, mevcut plan setine bakarak 3D modeli yeniden oluşturmak, sıfırdan yapmaktan çok daha hızlı ve kolaydır. Çünkü pek çok karar zaten verilmiştir
    • Postgres ölçeğinde bir projeyi AI olmadan sürdürmek fiilen neredeyse imkânsız. Yanlış hatırlamıyorsam Postgres 1 milyondan fazla satır kod içeriyor

  • Bunu test etmenin en iyi yolu, yoğun bir üretim veritabanının önüne PgBouncer gibi bir proxy koyup sorguları hem mevcut Postgres'e hem de Rust sürümüne eşzamanlı olarak yansıtmak gibi görünüyor
    Böylece gerçek yük altında çıktıları ve performansı karşılaştırabilirsiniz. Bir süre çalıştırdıktan sonra normal Postgres örneğiyle tabloları tek tek de karşılaştırabilirsiniz

  • Böyle bir kod nasıl incelenmeli? Normalde commit geçmişine göz gezdirip insanların neyi nasıl yaptığını görürsünüz, ama bir LLM bir aydan kısa sürede 7101 commit oluşturduysa bu imkansız
    Sadece bir günlük geçmişe bakmak bile fazla [1]. Zaten commit içerikleri de çok şey anlatmayabilir. GitHub'da bir deponun ilk commit'ine kolayca gitmenin yolu olup olmadığını merak ediyorum. Commit geçmişinde gezinmek epey zahmetli geliyor
    [1] - https://github.com/malisper/pgrust/commits/main/?since=2026-...

    • pgrust'ta malisper ile birlikte çalışıyorum. Bu tür projelerde odak, her bir commit'i incelemekten çok test ve fuzzing sürecini incelemeye kayacak gibi görünüyor
      PostgreSQL'in regresyon, izolasyon ve hata testlerinin de çok ötesine geçmek gerekiyor. İlgili danluu yazısı: https://danluu.com/ai-coding/
    • github cli içinde commit'leri artan/azalan sıralama bayraklarıyla sorgulayabilen bir komut var: https://cli.github.com/manual/gh_search_commits
      before x date gibi sözdiziminin belgeleri burada: https://docs.github.com/en/search-github/searching-on-github...
      Gelişmiş arama sayfası da var ama commit'ler için tarih filtresini desteklemiyor: https://github.com/search/advanced
      Arama aracında tarihler üzerinde ikili arama da yapabilirsiniz; commit bulunan ilk gün de şu: https://github.com/malisper/pgrust/commits/main/?since=2026-...
      İlk commit: https://github.com/malisper/pgrust/commit/22113dc36b02973060...
    • Genel olarak bakınca, prompt geçmişi yoksa ve LLM “derlemesini” doğrudan yeniden çalıştıramıyorsanız bunun açık kaynak olup olmadığı belirsiz. Kodu okuyabiliyorsunuz ama build sistemine erişemediğiniz “kaynağı açık” bir projeye daha çok benziyor
      Öte yandan, commit mesajları dışında insan geliştiricilerin iç düşünce süreçlerine de hiçbir zaman erişmedik; bu yüzden gizli prompt'ların doğrudan kapalı kaynak olduğu da tamamen aynı şey olmayabilir
    • GitHub'da ilk commit'e kolayca gitmek için github.com/user/repo/commits/?after=last_commit_hash+number_of_commits-2 sözdizimini kullanabilirsiniz. En yeni commit ve son commit nedeniyle -1, -1 yapılıyor
      Örnek: https://github.com/malisper/pgrust/commits/?after=3646a73515...
    • İncelemiyorum. Regresyon testlerinden geçmesi, orijinaliyle tamamen uyumlu olduğu anlamına geliyor diye güvenmekten başka çare yok

  • Etkileyici ama lisans değişikliği var: PostgreSQL lisansından [0] AGPL'ye [1] geçilmiş
    AGPL'yi seviyorum ve gerçek özgür açık kaynak lisansları arasında en iyilerden biri olduğunu düşünüyorum, ama uyumluluk konusunda endişeliyim. Orijinal kaynaktan yeniden yazıldıysa orijinal lisansın geçerli olması gerekmez mi? Bana öyle geliyor. Rust'ın coretools'unda olduğu gibi, açık kaynak yazılımı daha kısıtlayıcı bir lisansla yeniden yazma yönünde bir eğilim vardı. AGPL seçilmiş olması bunu çok daha etik gösteriyor ama hiç değiştirmemek daha güvenli olmaz mıydı?
    [0] https://www.postgresql.org/about/licence/
    [1] https://github.com/malisper/pgrust?tab=AGPL-3.0-1-ov-file

    • Kısıtlayıcılık yönünü ters anlamış gibisiniz. MIT lisanslı uutils coreutils, GPL lisanslı GNU coreutils'ten daha az kısıtlayıcıdır; AGPL de PostgreSQL lisansından daha kısıtlayıcıdır
      Yeniden yazılmış sürümü daha kısıtlayıcı bir lisansla dağıtmak PostgreSQL lisansını ihlal etmez. MIT benzeri lisansların GPL veya AGPL'den daha az kısıtlayıcı olmasının nedeni zaten daha kısıtlayıcı yeniden lisanslamaya izin vermeleridir
    • Lisansı beğenmediyseniz LLM'ye birkaç gün boyunca “port” ettirip sonra istediğiniz lisansı koyabilirsiniz. Görünüşe göre bugünlerde yapılan şey bu
    • PostgreSQL lisansı, BSD lisansının bir türevi olduğu için (A)GPL ile uyumlu
      Şöyle düşünün: Boş bir (A)GPL projesi oluşturup upstream BSD kod tabanını içe aktarıyorsunuz. Orijinal upstream dosyaları başlangıçtaki izin verici lisansları altında kalır, ama proje bütünü upstream lisansının atıf gerekliliklerini de içerecek şekilde (A)GPL'ye tabi olur. GPL buna izin verir. Sonra kendi kodunuzu AGPL altında ekleyip birleşik eseri AGPL olarak dağıtabilirsiniz
      Birisi sizin yazdığınız kısımları tek başına alırsa sadece AGPL'ye uyması yeterlidir. Ama upstream kaynak da dahilse upstream lisansının atıf şartlarını karşılamaya devam etmesi gerekir
    • Postgres lisansı zaten AGPL ile tamamen uyumlu. BSD/MIT daha izin vericidir

  • unsafe { sayısı 2664, unsafe fn sayısı 1835. Bu hiç de tamamen güvenli değil. Gerçekte ne olup bittiğini ve Rust’ın avantajlarından yararlanmak için mimarinin nasıl yeniden tasarlanması gerektiğini anlamış bir yeniden yazım gibi görünmüyor
    Bunun yerine ham işaretçileri geniş çapta kullanan, yapay zeka tarafından üretilmiş bir dönüşüm gibi görünüyor

    • unsafe’lerin çoğu, Postgres ayrıştırıcısına c2rust çalıştırılarak üretilen ayrıştırıcının içinde hapsolmuş durumda. Postgres ayrıştırıcısının kendisi de yacc/bison ile üretildiği için, bunu idiomatik Rust’a taşımak yerine mekanik olarak port etmeyi seçtik
      Özellikle ciddi bulduğunuz unsafe örnekleri varsa paylaşmanız iyi olur
    • Rust ile yazdığım tüm LLM projelerinde unsafe=deny ayarlı. Herkesin neden böyle bir tepkiyi öngörmediğini bilmiyorum
    • Bu inceleme yorumunu doğrudan prompt’a kopyalayıp yapıştırmak yeterli olur. Birkaç saat sonra “düzeltildi!” olabilir

  • Yeniden yazım ile yapay zeka yeniden yazımı arasında net bir ayrım yapmak gerekiyor gibi görünüyor

    • Örneğin TypeScript’in Go ile yeniden yazımı büyük ölçüde insanlar tarafından yapıldı ve kamuya açılması 1 yıl sürdü. İnsanların güvenebildiği yazılım yeniden yazımları bu şekilde yapılır
    • O kadar basit görünmüyor. Yeni ve iddialı projelerin neredeyse %100’ü bir ölçüde yapay zekadan yararlanacak gibi duruyor. Zig gibi katı biçimde yapay zeka kullanmama politikası olan birkaç proje biliyorum ama bunların çok küçük bir azınlık olduğunu düşünüyorum
      O halde ne kadar yapay zeka kullanımı olursa buna “yapay zeka yeniden yazımı” denir?
    • Yeniden yazım, LLM’lerin insanlardan daha uygun olduğu bir alan gibi geliyor. Büyük kısmı basit tekrar eden iş ve LLM’ler çeviri işlerine iyi uyuyor. Yanlış hatırlamıyorsam transformer mimarisi de başlangıçta çeviri için icat edilmişti
    • Bakımı yapılmayan insan yeniden yazımı sadece bir hobi projesidir. Yapay zeka yeniden yazımında ise token’ların tam olarak ne için yakıldığını bilmiyorum
    • Artık bu sadece bir build aşaması haline gelmiş gibi

  • Bu tür yeniden yazım projelerinin testlere dayanarak çalıştığını iddia ettiğini sıkça görüyorum. Ancak Postgres ya da SQLite gibi yazılımları güvenilir kılan şey, testlerin kendisinden çok üretim ortamında biriken yaralardır
    Güvenilirlik, yıllar boyunca gerçek ortamda çalışarak birikir

    • Devasa test paketinin büyük kısmı zaten üretimde alınan yaralardan oluşur. Çünkü her hata veya regresyon ortaya çıktığında, doğru davranışı doğrulayan bir test yazılır
      SQLite buna iyi bir örnek. SQLite’ın devasa özel testleri, insanların fork üretmesini zorlaştıran bir unsur olarak sıkça anılır. Turso bunu başardı ama aynı düzeyde titizliği garanti etmek için bir şirket gerekir. Elbette yıllar süren üretim deneyimi de gerekir
    • Bu belirli yeniden yazım hakkında bir yargı değil ama testler, yazılımın doğru çalıştığını belirleyen bir spesifikasyondur. Herhangi bir davranış otomatik testlerle kapsanmıyorsa, belirli bir değişikliğin o davranışı bozmadığını iddia edemezsiniz
      Mevcut, değiştirilmemiş test paketini kullanarak bir şeyin çalıştığını söylemek tamamen makuldür. Bence proje büyüdükçe bu daha da geçerlidir. Üretimde edinilen yaralar test paketinde belgelenmeli ve korunmalıdır; aksi halde o dersler kaybolur
      SQLite, devasa test paketi ve kapsamlı fuzzing’i ile tanınır. Normal koda kıyasla 590 kat daha fazla test kodu ve script’e sahiptir. Kaynak: https://sqlite.org/testing.html
    • O halde bu güvenilirliği upstream’e geri taşımayı kolaylaştırmak gerekir
      Şu anda bu tür bir LLM dönüşümünün en faydalı kullanımı, dönüşüm orijinal testlerin hepsini geçiyorsa, kendi uygulama test paketimi bunun üzerinde çalıştırarak orijinaldeki test kapsamı eksiklerini bulmaktır
      Dönüştürülmüş sürüm çöküyor ya da gözlemlenebilir biçimde yanlış davranıyorsa, bu gerçek projede eksik bir regresyon testi olduğu anlamına gelir. Bu tür dönüşüm projeleri günlük entegrasyon test matrisinde tek bir satır olarak güvenli ve kolay biçimde çalıştırılabilirse, upstream’in gelecekteki güncellemelerde bir şeyi yanlışlıkla bozmasını çok daha iyi engelleyebilir
    • Katılıyorum. Her hata veya regresyon ortaya çıktığında doğru davranışı doğrulayan testler yazıldığına dair yan yorumla da aynı fikirdeyim
      Ancak bu tür yeniden yazımlarda görünmeyen nokta, yeniden yazım nedeniyle yeni eklenen hataların ne yapılacağıdır. Sonuçta bunun da gerçek dünya senaryolarında kendi sınavını vermesi gerekmiyor mu?
    • Yeniden yazımı doğrulamanın başka yolları da var. Sadece pgrust ile postgres’i birlikte çalıştırıp çıktıları karşılaştırabilirsiniz
      Uç durumları biliyorsanız onları da çalıştırırsınız; bilmiyorsanız da fuzzer ya da otomasyon araçlarıyla ilginç girdiler bulursunuz. Tutarsızlık bulduğunuzda, o girdi/çıktı çifti artık bir test vakası olur. Böyle araçlar var mı bilmiyorum ama varsa Claude’a verip geliştirme döngüsüne dahil ettirebilirsiniz

  • Tarayıcıda çalışan WebAssembly demosu gerçekten çok temiz: https://pgrust.com

  • İnsanların neden bu kadar olumsuz olduğunu anlamıyorum. Bence bu tür projeler öğrenme amacı ve yeni yaklaşımları keşfetme açısından ilgi çekici. Bunun nesi sorun?

    • Muhtemelen sebep şu olabilir: yerleşik bir marka adı olan Postgres + Rust'ın sırtına binmesi, ortada pratik bir fayda ya da ilerleme olmaması ve güvenilirlik eksikliği
      Özellikle başlıkta Postgres gibi güçlü çağrışımı olan bir ad geçip bunun öne çıkarılması, ama kısa ve uzun vadeli pratiklik, toplumsal güven ve ağ etkisi gibi nedenlerle bariz biçimde kullanışsız olması, insanlarda kolayca ters tepki yaratıyor gibi görünüyor
    • On yılların emeğinin böyle kolayca kopyalandığını görmek rahatsız edici
    • Bir LLM'e yeniden yazdırmaktan tam olarak ne öğrenildiğini merak ediyorum
    • İnsanlar, kendi beceri ve yeteneklerinin gerekli olduğunu düşündükleri işleri LLM'in iyi yaptığını görünce tehdit hissediyor gibi
      Anlaşılır bir durum ama ne üretken ne de tamamen rasyonel bir olumsuz duygu. Bu başlıkta bunun iyi olamayacağını, iyi karşılanmaması gerektiğini ve sonunda kesin olarak felaketle biteceğini savunmaya çalışan yorumlar dolu. Oysa bu şeyin onlarca yıl boyunca birikmiş on binlerce ayrıntılı testi geçtiği gerçeği aksini düşündürüyor. Buna karşı çıkmak zor
      Elbette yeni sorunların ortaya çıkma ihtimali yüksek, ama yine de etkileyici bir başarı
    • Kalite konusunda endişeliyim. Koda üstünkörü göz atınca bile aptalca görünüyor. Kodun dahiyane yanını benim fark edemiyor olmam durumu değilse
      https://github.com/malisper/pgrust/blob/3646a73515a5e4ac7d0b...
      https://github.com/malisper/pgrust/blob/3646a73515a5e4ac7d0b...