Postgres Ditulis Ulang dalam Rust, Kini Lulus 100% Uji Regresi Postgres

 (github.com/malisper)
1 poin oleh GN⁺ 5 jam lalu | 1 komentar | Bagikan ke WhatsApp
  • pgrust adalah proyek penulisan ulang Postgres dalam Rust yang menargetkan kompatibilitas dengan Postgres 18.3, dan hasilnya cocok dengan keluaran yang diharapkan Postgres pada lebih dari 46.000 kueri regresi
  • Memiliki kompatibilitas disk sehingga dapat melakukan boot dari direktori data Postgres 18.3 yang sudah ada, dan menggunakan pengujian Postgres asli sebagai acuan perilaku
  • Saat ini belum siap untuk produksi dan juga belum dioptimalkan untuk performa, serta ekstensi Postgres yang ada dan ekstensi bahasa prosedural seperti PL/Python, PL/Perl, dan PL/Tcl umumnya belum kompatibel
  • Dapat dicoba melalui demo WebAssembly dan image Docker malisper/pgrust:v0.1; latest saat ini menunjuk ke rilis yang sama, tetapi image rilis yang dipatok adalah v0.1
  • Roadmap mencakup arsitektur internal Postgres multithread, connection pooling bawaan, peningkatan untuk workload berfokus JSON, eksperimen storage tanpa vacuum, dan guardrail runtime untuk SQL yang dihasilkan AI

Tujuan dan kompatibilitas pgrust

  • pgrust adalah proyek untuk menulis ulang Postgres dalam Rust
  • Targetnya adalah Postgres 18.3, dan hasilnya cocok dengan keluaran yang diharapkan Postgres pada lebih dari 46.000 kueri regresi
  • Menyediakan kompatibilitas disk yang memungkinkan boot dari direktori data Postgres 18.3 yang sudah ada
  • Tujuan proyek ini adalah membuat Postgres lebih mudah diubah di bagian internal
    • Perilakunya tetap dipertahankan seperti Postgres
    • Menggunakan pengujian Postgres asli sebagai acuan
    • Mengeksplorasi perubahan server yang lebih mendalam dengan Rust dan pemrograman berbantuan AI

Status saat ini dan keterbatasan

  • pgrust masih belum siap untuk produksi
  • Belum dioptimalkan untuk performa
  • Ekstensi Postgres yang ada dan ekstensi bahasa prosedural umumnya masih belum kompatibel
    • PL/Python
    • PL/Perl
    • PL/Tcl
  • Beberapa modul contrib bawaan sudah dipindahkan, dan lebih banyak kompatibilitas mungkin akan tersedia seiring waktu

Cara menjalankan

  • Demo WebAssembly dapat dicoba di https://pgrust.com
  • Menjalankan lewat Docker menggunakan image malisper/pgrust:v0.1
    • Menggunakan klien psql di dalam image
    • malisper/pgrust:latest saat ini menunjuk ke rilis yang sama
    • Image rilis yang dipatok adalah 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

Build dari source dan menjalankan

  • Di macOS diperlukan icu4c, openssl@3, dan libpq
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"
  • Di Debian/Ubuntu, instal tool build serta ICU, OpenSSL, LDAP, PAM, dan klien Postgres 18
sudo apt-get update
sudo apt-get install -y build-essential pkg-config libicu-dev libssl-dev libldap2-dev libpam0g-dev postgresql-client-18
  • Build dilakukan dengan cargo build sambil menunjuk ke direktori share Postgres 18.3 yang di-vendor
PGRUST_PGSHAREDIR="$PWD/vendor/postgres-18.3/share" \
cargo build --release --locked --bin postgres
  • Direktori data dibuat dengan --initdb milik pgrust
target/release/postgres --initdb \
  -D /tmp/pgrust-data \
  -L "$PWD/vendor/postgres-18.3/share" \
  --no-locale \
  --encoding UTF8 \
  -U postgres
  • Saat dijalankan, gunakan pengaturan terkait stack dan I/O sinkron secara bersamaan
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

Uji regresi dan hasil verifikasi

  • Uji regresi Postgres dijalankan dengan scripts/run-regression
PGRUST_BIN="$PWD/target/release/postgres" \
scripts/run-regression
  • Test runner menggunakan --initdb milik pgrust sendiri dan file uji Postgres 18.3 yang disertakan dalam repositori
  • Klien Postgres 18 psql harus tersedia di PATH
    • Jika berada di lokasi lain, setel PGRUST_PSQL=/path/to/psql
  • Hasil rilis yang telah diverifikasi menunjukkan bahwa pgrust cocok dengan keluaran yang diharapkan Postgres pada lebih dari 46.000 kueri regresi

Roadmap dan riwayat proyek

  • Roadmap mencakup item berikut

    • Arsitektur internal Postgres multithread

      • connection pooling bawaan
      • peningkatan dukungan untuk workload berfokus JSON
      • workflow fork dan branch yang cepat
      • eksperimen storage termasuk desain no-vacuum
      • guardrail runtime untuk kueri yang salah dan SQL yang dihasilkan AI
      • pengurangan perpindahan mendadak ke execution plan yang buruk
      • repositori saat ini berisi implementasi pgrust yang lebih baru yang telah mencapai tonggak uji regresi
      • implementasi publik sebelumnya diarsipkan di archive/pre-fabled-2026-06-23
      • tautan latar belakang terkait
      • Original pgrust launch
      • 67% regression update
      • Four Horsemen roadmap
      • Lisensinya adalah AGPL-3.0

Bacaan terkait

1 komentar

 
GN⁺ 5 jam lalu
Pendapat Hacker News

  • Saya penulis aslinya. Saya tidak menyangka ini akan muncul di sini. Singkatnya, saya sedang bereksperimen membuat Postgres yang lebih baik dengan LLM, dan karena Postgres sudah berusia 30 tahun, saya rasa kita juga sudah belajar banyak tentang database selama itu
    Banyak teknik yang berguna untuk penulisan ulang juga berguna untuk perancangan ulang. Versi pgrust baru yang belum saya publikasikan saat ini lulus 100% uji regresi Postgres, mengimplementasikan model thread per koneksi alih-alih model koneksi per proses milik Postgres, dan pada beban kerja transaksi 50% lebih cepat daripada Postgres, sementara pada beban kerja analitik sekitar 300 kali lebih cepat
    Saat ini di clickbench masih 2 kali lebih lambat daripada ClickHouse, tetapi saya rasa bisa menjadi lebih cepat daripada ClickHouse. Kalau ada pertanyaan, saya akan menjawabnya

    • Thread per koneksi hampir selalu merupakan pilihan yang benar dari sudut pandang performa, tetapi berkat pilihan Postgres untuk memakai proses per koneksi, kita bisa memuat ekstensi yang mencurigakan sesuka hati. Dalam skenario terburuk, yang mati hanya proses tersebut, bukan seluruh database. Akan bagus jika ada titik keseimbangan ketika segmentation fault di ekstensi hanya mematikan sebagian koneksi, bukan semuanya
    • Peningkatan 50% pada OLTP agak mencurigakan. Saya tidak ingin menuduh tanpa dasar, dan saya sendiri sering membuat klaim benchmark, tetapi meski saya tahu mereka memakai benchmark standar, tetap ada yang terasa mengganjal
      Bisa saja di suatu tempat MVCC dikorbankan lewat kompromi yang tidak bisa masuk produksi. Saya sudah melihat bahwa uji regresinya lulus. Apakah fsync aktif? Setahu saya uji regresi tidak terlalu baik menangkap pola I/O yang buruk. Meski begitu, proyek ini terlihat menarik
    • Saya penasaran dengan latar belakang dan keahlian nyata terkait Postgres dan database secara umum. Pada akhirnya saya ingin tahu apakah mereka benar-benar tahu persis apa yang sedang mereka lakukan, atau ada ranjau besar yang belum mereka ketahui tersembunyi di sana
    • Ini tampaknya lebih seperti eksperimen daripada peluncuran produk, tetapi seseorang seperti mendorongnya ke bawah bus sorotan HN. Saya penasaran apakah ini eksperimen untuk melihat sejauh apa coding dengan LLM bisa dilakukan, atau eksperimen untuk membuatnya lebih dulu lalu melihat seberapa banyak kode yang ditulis LLM bisa diterima
    • Jika pada beban kerja analitik sekitar 300 kali lebih cepat daripada Postgres dan 2 kali lebih lambat daripada ClickHouse, apakah itu berarti datanya disimpan dalam format berorientasi kolom? Atau memakai baik orientasi baris maupun kolom?
      Saya sedang membuat δx, sesuatu yang mirip tetapi berbeda. Ini adalah ekstensi Postgres yang menyimpan data terkompresi berorientasi kolom di dalam tabel Postgres biasa, sehingga replikasi, pemulihan kegagalan, pg_dump, dan sebagainya tetap berfungsi apa adanya: https://github.com/xataio/deltax
      Saat ini, untuk node tunggal, 30–40% lebih lambat daripada ClickHouse. PR untuk menambahkannya ke clickbench baru saja diterima, jadi perbandingannya bisa dilihat di sini: https://benchmark.clickhouse.com/#system=+liH|_etx|gQ|saB&ty...

  • Saya kurang memahami penulisan ulang seperti ini. Biasanya dipimpin oleh satu orang, sehingga mudah menjadi single point of failure, dan dibuat dalam waktu sangat singkat sehingga sulit mengatakan bahwa pembuatnya sudah mempelajari disiplin untuk membangun proyek secara berkelanjutan
    Dalam jangka menengah hingga panjang, kemungkinan untuk dipelihara juga terlihat rendah. Orang yang ingin berkontribusi pun harus membayar biaya token. Ini karena menjaga proyek seperti ini tanpa AI menjadi makin sulit. Apakah ada orang yang ingin memasukkan hal seperti ini ke produksi? Rasanya tidak terlalu masuk akal

    • Ini bukan sekadar penulisan ulang, ada juga perbaikan. Saya pernah melakukan hal serupa untuk bersenang-senang, karena ingin melihat apakah desain lama, khususnya bagian-bagian yang menurut orang-orang PostgreSQL “tidak bisa dilakukan dengan cara lain”, bisa diperbaiki. Ternyata memang bisa dilakukan dengan cara lain
      Saya tidak akan memasukkannya ke produksi, tetapi saya belajar banyak tentang bagian dalam database. Bahkan di era LLM, demi menyenangkan otak, saya mengimplementasikan fitur database tanpa LLM di database produksi kami. Saat ini saya sedang bergulat dengan Flexible Paxos; mungkin pada akhirnya kami akan tetap memakai Raft yang lama, stabil, dan sederhana, tetapi tetap saja menarik
    • Saya melihatnya sebagai bukti konsep yang menarik. Bukan hanya menulis ulang PostgreSQL dalam Rust, tetapi juga menguji dependensi yang dipilih, perubahan model threading, dan kemungkinan perubahan arsitektur lain
      LLM sangat kuat untuk menghasilkan prototipe dengan sangat cepat, dan prototipe yang berjalan bisa mengakhiri banyak spekulasi. Tanpa dukungan tim asli atau jumlah orang yang cukup sebanding, serta tanpa penjelasan yang meyakinkan bahwa kualitas kode dan pemeliharaannya menyamai atau melampaui kode asli, saya rasa saya tidak akan memakai versi penulisan ulang dari proyek sebesar ini
      Secara umum, menurut saya pencucian lisensi dengan LLM sulit dipertahankan baik secara hukum maupun moral. Namun kasus ini berbeda karena mereka memilih lisensi yang lebih membatasi. Saya bukan pengacara, tetapi sejauh yang saya pahami, secara hukum dimungkinkan untuk mengunduh PostgreSQL, melakukan s/MIT/AGPL/, lalu mendistribusikannya. Versi asli berlisensi MIT tetap ada, jadi sampai ada fitur baru yang meyakinkan, tidak ada alasan khusus untuk lebih memilih versi itu
    • Tidak sepenuhnya sama, tetapi membuat ulang model 3D berdasarkan satu set gambar teknis yang sudah ada jauh lebih cepat dan mudah daripada membuatnya dari nol. Karena sudah banyak keputusan yang diambil
    • Untuk proyek sebesar Postgres, mempertahankannya tanpa AI secara praktis hampir mustahil. Kalau ingatan saya benar, Postgres berisi lebih dari 1 juta baris

  • Cara terbaik untuk mengujinya sepertinya adalah menaruh proxy seperti PgBouncer di depan database produksi yang sibuk, lalu mencerminkan kueri secara bersamaan ke Postgres yang ada dan versi Rust
    Dengan begitu, keluaran dan performa bisa dibandingkan di bawah beban nyata. Setelah dijalankan beberapa waktu, tabelnya juga bisa dibandingkan satu per satu dengan instance Postgres biasa

  • Bagaimana kode seperti ini sebaiknya ditinjau? Biasanya orang menelusuri riwayat commit untuk melihat apa yang dikerjakan orang dan bagaimana caranya, tetapi kalau LLM membuat 7101 commit dalam waktu kurang dari sebulan, itu mustahil.
    Melihat satu hari saja sudah terlalu banyak [1]. Lagi pula isi commit belum tentu memberi banyak informasi. Saya juga penasaran apakah ada cara mudah di GitHub untuk langsung menuju commit pertama sebuah repositori. Menjelajahi riwayat commit terasa cukup merepotkan.
    [1] - https://github.com/malisper/pgrust/commits/main/?since=2026-...

    • Saya sedang bekerja dengan malisper di pgrust. Untuk proyek seperti ini, fokus sepertinya akan bergeser dari meninjau tiap commit ke meninjau proses pengujian dan fuzzing.
      Ini harus jauh melampaui pengujian regresi, isolasi, dan kegagalan milik Postgres. Tulisan danluu terkait: https://danluu.com/ai-coding/
    • github cli punya perintah untuk mengkueri commit dengan flag pengurutan naik/turun: https://cli.github.com/manual/gh_search_commits
      Dokumentasi sintaks seperti before x date ada di sini: https://docs.github.com/en/search-github/searching-on-github...
      Ada juga halaman pencarian lanjutan, tetapi tidak mendukung commit dengan filter tanggal: https://github.com/search/advanced
      Anda juga bisa melakukan binary search tanggal di widget pencarian, dan hari pertama yang memiliki commit ada di sini: https://github.com/malisper/pgrust/commits/main/?since=2026-...
      Commit pertama: https://github.com/malisper/pgrust/commit/22113dc36b02973060...
    • Secara umum, jika tidak ada riwayat prompt dan kita tidak bisa menjalankan ulang “kompilasi” LLM secara langsung, agak ambigu apakah ini benar-benar open source. Kodenya bisa dibaca, tetapi rasanya lebih mirip proyek “source available” yang sistem build-nya tidak bisa diakses.
      Sebaliknya, selain pesan commit, kita juga tidak pernah punya akses ke proses berpikir internal pengembang manusia, jadi mengatakan bahwa prompt rahasia sama dengan source tertutup mungkin juga tidak sepenuhnya sama.
    • Untuk menuju commit pertama dengan mudah di GitHub, Anda bisa memakai sintaks github.com/user/repo/commits/?after=last_commit_hash+number_of_commits-2. Karena commit terbaru dan commit terakhir, hitungannya seperti melakukan -1, -1.
      Contoh: https://github.com/malisper/pgrust/commits/?after=3646a73515...
    • Tidak ditinjau. Kita hanya bisa percaya bahwa lolos pengujian regresi berarti sepenuhnya kompatibel dengan aslinya.

  • Memang mengesankan, tetapi ini adalah perubahan lisensi dari lisensi PostgreSQL [0] menjadi AGPL [1].
    Saya suka AGPL dan menganggapnya salah satu lisensi open source bebas sejati yang terbaik, tetapi saya khawatir soal kompatibilitasnya. Jika ditulis ulang dari source asli, bukankah lisensi asli seharusnya tetap berlaku? Menurut saya begitu. Ada tren menulis ulang software open source dengan lisensi yang lebih restriktif, seperti coretools di Rust. Karena memilih AGPL, ini memang terlihat jauh lebih etis, tetapi bukankah lebih aman jika tidak mengubahnya sama sekali?
    [0] https://www.postgresql.org/about/licence/
    [1] https://github.com/malisper/pgrust?tab=AGPL-3.0-1-ov-file

    • Sepertinya arah restriktifnya dipahami terbalik. uutils coreutils yang berlisensi MIT kurang restriktif daripada GNU coreutils yang berlisensi GPL, dan AGPL lebih restriktif daripada lisensi PostgreSQL.
      Mendistribusikan versi tulis ulang dengan lisensi yang lebih restriktif tidak melanggar lisensi PostgreSQL. Alasan lisensi keluarga MIT kurang restriktif dibanding GPL atau AGPL adalah justru karena lisensi itu mengizinkan pelisensian ulang yang lebih restriktif.
    • Kalau tidak suka lisensinya, tinggal suruh LLM “mem-porting” selama beberapa hari lalu tempelkan lisensi yang Anda inginkan. apparently sekarang tampaknya begitu caranya.
    • Lisensi PostgreSQL adalah varian lisensi BSD, jadi kompatibel dengan (A)GPL.
      Cara memahaminya seperti ini: buat proyek (A)GPL kosong lalu ambil codebase BSD upstream. File upstream asli tetap berada di bawah lisensi permisif aslinya, tetapi proyek secara keseluruhan berada di bawah (A)GPL, termasuk kewajiban atribusi dari lisensi upstream. GPL mengizinkan kewajiban semacam itu. Setelah itu Anda bisa menambahkan kode Anda sendiri sebagai AGPL dan mendistribusikan karya gabungannya sebagai AGPL.
      Jika seseorang hanya mengambil bagian kode Anda yang Anda tulis sendiri, mereka cukup mematuhi AGPL. Namun jika mereka juga menyertakan source upstream, mereka tetap harus memenuhi kewajiban atribusi dari lisensi upstream.
    • Lisensi Postgres sudah sepenuhnya kompatibel dengan AGPL. BSD/MIT lebih permisif.

  • Ada 2664 kemunculan unsafe { dan 1835 unsafe fn. Ini sama sekali tidak aman. Ini tidak terlihat seperti penulisan ulang yang memahami apa yang sebenarnya terjadi dan bagaimana arsitekturnya harus didesain ulang agar bisa memanfaatkan keunggulan Rust
    Sebaliknya, ini terlihat seperti konversi yang dihasilkan AI dengan penggunaan raw pointer secara luas

    • Sebagian besar unsafe terkurung di dalam parser yang dihasilkan dengan menjalankan c2rust pada parser Postgres. Parser Postgres sendiri juga dihasilkan dari yacc/bison, jadi mereka memilih mem-porting secara mekanis alih-alih memindahkannya ke Rust yang idiomatis
      Kalau ada unsafe yang menurut Anda sangat bermasalah, beri tahu
    • Semua proyek LLM yang saya tulis dengan Rust saya setel ke unsafe=deny. Saya tidak mengerti kenapa semua orang tidak mengantisipasi reaksi seperti ini
    • Sepertinya komentar review ini tinggal disalin begitu saja ke prompt. Beberapa jam lagi mungkin akan jadi “sudah diperbaiki!”

  • Sepertinya kita harus membedakan dengan tegas antara penulisan ulang dan penulisan ulang oleh AI

    • Misalnya, penulisan ulang TypeScript ke Go sebagian besar dilakukan manusia, dan butuh 1 tahun sampai dipublikasikan. Penulisan ulang software yang bisa dipercaya orang dilakukan dengan cara seperti itu
    • Tampaknya tidak sesederhana itu. Hampir 100% proyek baru yang ambisius sepertinya akan memanfaatkan AI sampai tingkat tertentu. Saya tahu beberapa proyek dengan kebijakan ketat tanpa AI seperti Zig, tapi menurut saya itu minoritas yang sangat kecil
      Kalau begitu, seberapa besar penggunaan AI sampai sesuatu disebut “penulisan ulang AI”?
    • Penulisan ulang terasa seperti area yang LLM lebih cocok daripada manusia. Sebagian besarnya adalah pekerjaan repetitif sederhana, dan LLM cocok untuk pekerjaan penerjemahan. Kalau ingatan saya benar, arsitektur transformer juga awalnya diciptakan untuk penerjemahan
    • Penulisan ulang oleh manusia tanpa pemeliharaan hanyalah proyek hobi. Saya tidak tahu untuk apa token dibakar dalam penulisan ulang AI
    • Sekarang itu sudah menjadi sekadar tahap build

  • Saya sering melihat proyek penulisan ulang seperti ini mengklaim bahwa software-nya bekerja karena bergantung pada pengujian. Namun yang membuat software seperti Postgres atau SQLite dapat dipercaya bukanlah pengujian itu sendiri, melainkan lebih mirip luka-luka yang terkumpul di lingkungan produksi
    Keandalan terbangun setelah bertahun-tahun berjalan di produksi

    • Sebagian besar test suite yang sangat besar itu justru merupakan luka dari produksi. Karena setiap kali ada bug atau regresi, dibuatlah pengujian untuk memastikan perilaku yang benar
      SQLite adalah contoh yang bagus. Pengujian privat SQLite yang sangat besar sering dikutip sebagai faktor yang membuat orang sulit melakukan fork. Turso memang berhasil melakukannya, tetapi untuk menjamin ketelitian yang setara dibutuhkan perusahaan. Tentu saja juga dibutuhkan bertahun-tahun operasi
    • Ini bukan penilaian terhadap penulisan ulang spesifik ini, tetapi pengujian adalah spesifikasi bahwa software bekerja dengan benar. Jika suatu perilaku tidak tercakup oleh pengujian otomatis apa pun, maka Anda tidak bisa mengklaim bahwa perubahan tertentu tidak merusak perilaku itu
      Mengatakan bahwa sesuatu bekerja dengan menggunakan test suite lama yang tidak dimodifikasi sepenuhnya masuk akal. Menurut saya makin besar proyeknya, makin benar demikian. Luka dari produksi harus didokumentasikan dan dilindungi dalam test suite; jika tidak, pelajaran itu akan hilang
      SQLite terkenal dengan test suite raksasa dan fuzzing yang ekstensif. Kode pengujian dan skripnya 590 kali lebih banyak daripada kode biasa. Sumber: https://sqlite.org/testing.html
    • Kalau begitu, keandalan itu harus dibuat mudah untuk dikembalikan ke upstream
      Hal paling berguna yang bisa dilakukan dengan versi konversi LLM seperti ini saat ini adalah, jika versi konversi tersebut lulus semua pengujian asli, menjalankan test suite aplikasi saya di atasnya untuk menemukan kurangnya cakupan pengujian pada versi asli
      Jika versi konversi crash atau menunjukkan perilaku salah yang dapat diamati, itu berarti ada regression test yang hilang di proyek sebenarnya. Jika proyek konversi seperti ini bisa dijalankan dengan aman dan mudah sebagai satu baris dalam matriks integration test harian, upstream bisa jauh lebih baik mencegah update di masa depan secara tidak sengaja merusak sesuatu
    • Setuju. Saya juga setuju dengan komentar samping bahwa setiap kali ada bug atau regresi, dibuat pengujian untuk memastikan perilaku yang benar
      Namun yang tidak terlihat dalam penulisan ulang seperti ini adalah apa yang dilakukan terhadap bug baru yang diperkenalkan oleh penulisan ulang itu sendiri. Pada akhirnya, bukankah ia harus menghadapi tantangan dalam skenario dunia nyata secara mandiri?
    • Ada juga cara lain untuk memverifikasi penulisan ulang. Cukup jalankan pgrust dan postgres bersama-sama lalu bandingkan output-nya
      Kalau tahu edge case, jalankan juga itu; kalau tidak tahu, gunakan fuzzer atau tool otomatis untuk menemukan input yang menarik. Jika menemukan ketidaksesuaian, pasangan input/output itu kini menjadi test case. Saya tidak tahu apakah tool seperti itu ada, tetapi jika ada, berikan ke Claude agar dimasukkan ke dalam loop pengembangan

  • Demo WebAssembly yang berjalan di browser benar-benar rapi: https://pgrust.com

  • Saya tidak mengerti kenapa begitu negatif. Menurut saya proyek seperti ini menarik untuk tujuan pembelajaran dan eksplorasi cara baru. Apa masalahnya?

    • Mungkin alasannya seperti ini. Menumpang pada nama brand yang sudah mapan, Postgres + Rust, tetapi tanpa kepraktisan atau kemajuan, dan kurang kredibilitas
      Terutama ketika judulnya memuat nama dengan sinyal kuat seperti Postgres dan menonjolkannya, tetapi jelas tidak praktis karena alasan seperti kegunaan jangka pendek maupun jangka panjang, kepercayaan sosial, dan efek jaringan, tampaknya mudah muncul rasa antipati
    • Rasanya tidak nyaman melihat pekerjaan selama puluhan tahun disalin semudah ini
    • Saya penasaran, sebenarnya apa yang dipelajari dari menyuruh LLM melakukan penulisan ulang
    • Sepertinya orang merasa terancam ketika melihat LLM mampu mengerjakan dengan baik sesuatu yang mereka anggap membutuhkan keahlian dan bakat mereka
      Bisa dipahami, tetapi itu emosi negatif yang tidak produktif dan juga tidak terlalu rasional. Thread ini penuh dengan tulisan yang ingin berargumen bahwa ini mustahil bagus, tidak boleh bagus, dan pada akhirnya pasti berakhir bencana. Namun fakta bahwa benda ini lolos puluhan ribu pengujian cermat yang terakumulasi selama puluhan tahun justru menunjukkan sebaliknya. Sulit dibantah
      Tentu saja kemungkinan muncul masalah baru tetap tinggi, tetapi ini tetap pencapaian yang mengesankan
    • Saya khawatir soal kualitasnya. Sekilas saja melihat kodenya, tampak bodoh. Kecuali kalau saya yang tidak mampu mengenali sisi jenius dari kode itu
      https://github.com/malisper/pgrust/blob/3646a73515a5e4ac7d0b...
      https://github.com/malisper/pgrust/blob/3646a73515a5e4ac7d0b...