เขียน Postgres ใหม่ด้วย Rust ตอนนี้ผ่านการทดสอบ regression ของ Postgres ได้ 100% แล้ว

 (github.com/malisper)
1 คะแนน โดย GN⁺ 5 시간 전 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • pgrust คือโปรเจ็กต์เขียน Postgres ใหม่ด้วย Rust โดยตั้งเป้าให้เข้ากันได้กับ Postgres 18.3 และให้ผลลัพธ์ตรงกับเอาต์พุตที่คาดไว้ของ Postgres ใน regression query มากกว่า 46,000 รายการ
  • มีความเข้ากันได้ในระดับดิสก์จนสามารถบูตจาก Postgres 18.3 data directory เดิมได้ และใช้การทดสอบจริงของ Postgres เป็นเกณฑ์พฤติกรรม
  • ขณะนี้ ยังไม่พร้อมใช้งานใน production และยังไม่ได้ปรับแต่งประสิทธิภาพ อีกทั้งโดยทั่วไปยังไม่รองรับส่วนขยาย Postgres เดิมและส่วนขยายภาษาเชิงกระบวนการอย่าง PL/Python, PL/Perl, PL/Tcl
  • สามารถลองรันได้ผ่านเดโม WebAssembly และ Docker image malisper/pgrust:v0.1 โดย latest ชี้ไปที่รีลีสเดียวกันในตอนนี้ แต่ image สำหรับรันแบบตรึงเวอร์ชันคือ v0.1
  • โรดแมปรวมถึง สถาปัตยกรรมภายในของ Postgres แบบมัลติเธรด, connection pooling ในตัว, การปรับปรุงเวิร์กโหลดที่เน้น JSON, การทดลอง storage แบบ no-vacuum และ runtime guardrails สำหรับ SQL ที่ AI สร้างขึ้น

เป้าหมายและความเข้ากันได้ของ pgrust

  • pgrust เป็นโปรเจ็กต์ที่เขียน Postgres ใหม่ด้วย Rust
  • เป้าหมายคือ Postgres 18.3 และให้ผลลัพธ์ตรงกับเอาต์พุตที่คาดไว้ของ Postgres ใน regression query มากกว่า 46,000 รายการ
  • รองรับ ความเข้ากันได้ระดับดิสก์ ที่สามารถบูตจาก Postgres 18.3 data directory เดิมได้
  • เป้าหมายของโปรเจ็กต์คือทำให้ปรับเปลี่ยน Postgres ภายในได้ง่ายขึ้น
    • คงพฤติกรรมให้เป็นแบบ Postgres
    • ใช้การทดสอบจริงของ Postgres เป็นเกณฑ์
    • สำรวจการเปลี่ยนแปลงเซิร์ฟเวอร์ที่ลึกขึ้นด้วย Rust และการเขียนโปรแกรมแบบมี AI ช่วย

สถานะปัจจุบันและข้อจำกัด

  • pgrust ยังไม่พร้อมใช้งานใน production
  • ยัง ไม่ได้ปรับแต่งประสิทธิภาพ
  • โดยทั่วไปยังไม่รองรับส่วนขยาย Postgres เดิมและส่วนขยายภาษาเชิงกระบวนการ
    • PL/Python
    • PL/Perl
    • PL/Tcl
  • โมดูล contrib แบบ bundled บางส่วนถูกพอร์ตมาแล้ว และเมื่อเวลาผ่านไปอาจมีความเข้ากันได้เพิ่มขึ้น

วิธีรัน

  • สามารถลองเดโม WebAssembly ได้ที่ https://pgrust.com
  • การรันด้วย Docker ใช้ image malisper/pgrust:v0.1
    • ใช้ไคลเอนต์ psql ที่อยู่ภายใน image
    • malisper/pgrust:latest ตอนนี้ชี้ไปที่รีลีสเดียวกัน
    • image รีลีสแบบตรึงเวอร์ชันคือ 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

การคอมไพล์จากซอร์สและการรัน

  • บน macOS ต้องใช้ icu4c, openssl@3, 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"
  • บน Debian/Ubuntu ให้ติดตั้งเครื่องมือ build พร้อม ICU, OpenSSL, LDAP, PAM และ Postgres 18 client
sudo apt-get update
sudo apt-get install -y build-essential pkg-config libicu-dev libssl-dev libldap2-dev libpam0g-dev postgresql-client-18
  • คอมไพล์ด้วย cargo build โดยระบุ vendored Postgres 18.3 shared directory
PGRUST_PGSHAREDIR="$PWD/vendor/postgres-18.3/share" \
cargo build --release --locked --bin postgres
  • data directory สร้างด้วย --initdb ของ pgrust
target/release/postgres --initdb \
  -D /tmp/pgrust-data \
  -L "$PWD/vendor/postgres-18.3/share" \
  --no-locale \
  --encoding UTF8 \
  -U postgres
  • ตอนรันให้ใช้ค่าตั้งเกี่ยวกับสแตกและ synchronous I/O ร่วมกัน
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

การทดสอบ regression และผลการตรวจสอบ

  • การทดสอบ regression ของ Postgres รันด้วย scripts/run-regression
PGRUST_BIN="$PWD/target/release/postgres" \
scripts/run-regression
  • test runner ใช้ --initdb ของ pgrust เองและ ไฟล์ทดสอบ Postgres 18.3 ที่รวมอยู่ในรีโพซิทอรี
  • ต้องมีไคลเอนต์ Postgres 18 psql อยู่ใน PATH
    • ถ้าอยู่คนละตำแหน่ง ให้ตั้งค่า PGRUST_PSQL=/path/to/psql
  • ผลลัพธ์รีลีสที่ผ่านการตรวจสอบคือ pgrust ให้ผลตรงกับเอาต์พุตที่คาดไว้ของ Postgres ใน regression query มากกว่า 46,000 รายการ

โรดแมปและประวัติโปรเจ็กต์

  • โรดแมปประกอบด้วยหัวข้อต่อไปนี้

    • สถาปัตยกรรมภายในของ Postgres แบบมัลติเธรด

      • connection pooling ในตัว
      • ปรับปรุงการรองรับเวิร์กโหลดที่เน้น JSON
      • เวิร์กโฟลว์ fork และ branching ที่รวดเร็ว
      • การทดลองด้าน storage รวมถึงการออกแบบแบบ no-vacuum
      • runtime guardrails สำหรับคิวรีที่ผิดพลาดและ SQL ที่ AI สร้างขึ้น
      • ลดการสลับไปใช้ execution plan ที่แย่แบบฉับพลัน
      • ปัจจุบันรีโพซิทอรีนี้มี implementation pgrust ที่ใหม่กว่าซึ่งไปถึง milestone การทดสอบ regression แล้ว
      • implementation สาธารณะก่อนหน้านี้ถูกเก็บไว้ที่ archive/pre-fabled-2026-06-23
      • ลิงก์พื้นหลังที่เกี่ยวข้อง
      • Original pgrust launch
      • 67% regression update
      • Four Horsemen roadmap
      • ไลเซนส์คือ AGPL-3.0

บทความที่เกี่ยวข้อง

1 ความคิดเห็น

 
GN⁺ 5 시간 전
ความเห็นจาก Hacker News

  • ผมเป็นผู้เขียนต้นฉบับเอง ไม่คิดว่าจะมาโผล่ที่นี่ สรุปคือผมทดลองอยู่ว่าจะสร้าง Postgres ที่ดีกว่าเดิมด้วย LLM ได้ไหม และมองว่า Postgres มีอายุกว่า 30 ปีแล้ว ระหว่างนั้นเราก็ได้เรียนรู้อะไรเกี่ยวกับฐานข้อมูลเพิ่มขึ้นมาก
    เทคนิคหลายอย่างที่มีประโยชน์ต่อการเขียนใหม่ ก็มีประโยชน์ต่อการออกแบบใหม่ด้วย เวอร์ชัน pgrust ใหม่ที่ยังไม่เปิดเผยตอนนี้ผ่าน regression test ของ Postgres ได้ 100% แล้ว และแทนที่จะใช้โมเดล หนึ่งโปรเซสต่อหนึ่งการเชื่อมต่อ แบบ Postgres ก็ได้ทำ โมเดลหนึ่งเธรดต่อหนึ่งการเชื่อมต่อ ไว้ อีกทั้งในงานโหลดแบบทรานแซกชันยังเร็วกว่า Postgres 50% และในงานโหลดเชิงวิเคราะห์เร็วกว่าเกือบ 300 เท่า
    ตอนนี้ยังช้ากว่า ClickHouse 2 เท่าใน clickbench แต่คิดว่าน่าจะทำให้เร็วกว่า ClickHouse ได้ ถ้ามีคำถามก็จะตอบ

    • หนึ่งเธรดต่อหนึ่งการเชื่อมต่อ เกือบจะเป็นตัวเลือกที่ถูกต้องเสมอในมุมมองด้านประสิทธิภาพ แต่ที่ Postgres เลือกหนึ่งโปรเซสต่อหนึ่งการเชื่อมต่อ ทำให้สามารถโหลดส่วนขยายแปลก ๆ ได้ตามใจชอบ อย่างแย่ที่สุดก็ทำให้ตายแค่โปรเซสนั้น ไม่ใช่ทั้งฐานข้อมูล ถ้ามีจุดสมดุลที่แม้ส่วนขยายจะเกิด segmentation fault ก็ทำให้ล่มแค่บางการเชื่อมต่อ ไม่ใช่ทั้งระบบ ก็น่าจะดี
    • การ ปรับปรุง 50% ใน OLTP ฟังดูน่าสงสัยนิดหน่อย ไม่ได้อยากโจมตีแบบไร้หลักฐาน และผมเองก็อ้าง benchmark บ่อย แต่ถึงจะรู้ว่าใช้ benchmark มาตรฐาน ก็ยังรู้สึกแปลก ๆ
      อาจมีการยอมแลกบางอย่างที่ทำให้ MVCC พังในจุดใดจุดหนึ่งจนเอาไปใช้จริงไม่ได้ก็ได้ เห็นแล้วว่าผ่าน regression test แต่ fsync เปิดอยู่ไหม? เท่าที่รู้ regression test จับรูปแบบ I/O แย่ ๆ ได้ไม่ค่อยดี ถึงอย่างนั้นก็ดูเป็นโปรเจ็กต์ที่น่าสนใจ
    • อยากรู้ภูมิหลังและความเชี่ยวชาญจริง ๆ เกี่ยวกับ Postgres และฐานข้อมูลโดยรวม ท้ายที่สุดก็อยากรู้ว่า รู้แน่ชัดไหมว่าตัวเองกำลังทำอะไรอยู่ หรือยังมีทุ่นระเบิดก้อนใหญ่ที่ไม่รู้ซ่อนอยู่
    • ดูเหมือนจะเป็นงานทดลองมากกว่าจะเป็นการเปิดตัวผลิตภัณฑ์ แต่มีคนผลักมันมาอยู่ใต้รถบัสสปอตไลต์ของ HN มากกว่า เลยสงสัยว่านี่เป็นการทดลองว่า การเขียนโค้ดด้วย LLM ไปได้ไกลแค่ไหน หรือเป็นการดูว่าถ้าสร้างก่อนแล้ว จะยอมรับโค้ดที่ LLM เขียนได้มากแค่ไหน
    • ที่บอกว่าเร็วกว่า Postgres เกือบ 300 เท่าในงานโหลดเชิงวิเคราะห์ และช้ากว่า ClickHouse 2 เท่า หมายความว่าเก็บข้อมูลในรูปแบบ columnar ใช่ไหม? หรือใช้ทั้งแบบแถวและแบบคอลัมน์?
      ผมกำลังทำงานที่คล้ายแต่ก็ต่างอยู่ ชื่อว่า δx เป็นส่วนขยายของ Postgres ที่เก็บข้อมูลบีบอัดแบบคอลัมน์ไว้ในตาราง Postgres ปกติ ทำให้ replication, failover, pg_dump ฯลฯ ยังทำงานได้เหมือนเดิม: https://github.com/xataio/deltax
      ตอนนี้สำหรับ single node ยังช้ากว่า ClickHouse ราว 30~40% มี PR เพิ่มเข้า clickbench ที่เพิ่งถูกรับไป เลยดูการเปรียบเทียบได้ที่นี่: https://benchmark.clickhouse.com/#system=+liH|_etx|gQ|saB&ty...

  • ผมไม่ค่อยเข้าใจงานเขียนใหม่แบบนี้ ปกติมักมีคนคนเดียวเป็นแกนนำ เลยกลายเป็น จุดล้มเหลวเพียงจุดเดียว ได้ง่าย และมักถูกสร้างขึ้นในเวลาสั้นมาก จนยากจะบอกว่าได้ฝึกวินัยในการทำโปรเจ็กต์อย่างต่อเนื่อง
    ระยะกลางถึงยาวก็ดูมีโอกาสถูกดูแลต่อไม่มาก คนที่จะมาช่วยก็ต้องจ่ายต้นทุนโทเค็นด้วย เพราะต่อไปการดูแลโปรเจ็กต์แบบนี้โดยไม่มี AI จะยิ่งยากขึ้น แบบนี้จะมีใครอยากเอาไปใช้จริงหรือ? ฟังดูไม่ค่อยสมเหตุสมผล

    • ไม่ได้เป็นแค่การเขียนใหม่อย่างเดียว แต่มีการปรับปรุงด้วย ผมเองก็เคยทำอะไรคล้าย ๆ กันเล่น ๆ และอยากดูว่าจะปรับปรุงดีไซน์เก่า โดยเฉพาะส่วนที่คนฝั่ง PostgreSQL บอกว่า “ทำต่างไปไม่ได้” ได้ไหม ซึ่งจริง ๆ แล้วทำต่างได้
      ผมคงไม่เอาไปใช้จริง แต่ได้เรียนรู้เรื่องภายในฐานข้อมูลเยอะมาก แม้ในยุค LLM ผมก็ยังทำฟีเจอร์ฐานข้อมูลในฐานข้อมูลโปรดักชันของเราโดยไม่ใช้ LLM เพื่อให้สมองสนุกอยู่ ตอนนี้กำลังปวดหัวกับ Flexible Paxos แต่สุดท้ายก็คงใช้ Raft ที่เก่า เสถียร และเรียบง่ายต่อไป ถึงอย่างนั้นก็ยังน่าสนใจ
    • มองว่าเป็น proof of concept ที่น่าสนใจ ไม่ใช่แค่การเขียน PostgreSQL ใหม่ด้วย Rust แต่ยังเป็นการทดสอบความเป็นไปได้ของ dependency ที่เลือก การเปลี่ยน threading model และการเปลี่ยนสถาปัตยกรรมอื่น ๆ
      LLM เก่งมากในการปั่นโปรโตไทป์ออกมาอย่างรวดเร็ว และโปรโตไทป์ที่ทำงานได้จริงก็ช่วยยุติการคาดเดาได้หลายอย่าง ถ้าไม่มีทีมเดิมหรือทีมขนาดใกล้เคียงกันหนุนหลัง และไม่มีคำอธิบายที่น่าเชื่อว่าคุณภาพโค้ดต้นฉบับและความสามารถในการดูแลรักษานั้นเทียบเท่าหรือดีกว่าเดิม ผมก็คงไม่ใช้เวอร์ชันเขียนใหม่ของโปรเจ็กต์ยักษ์แบบนี้
      โดยทั่วไปผมคิดว่าการใช้ LLM เพื่อฟอกใบอนุญาตนั้นปกป้องได้ยากทั้งในเชิงกฎหมายและศีลธรรม แต่กรณีนี้ต่างออกไปตรงที่เลือกไลเซนส์ที่จำกัดมากกว่า ผมไม่ใช่ทนาย แต่เข้าใจว่าการดาวน์โหลด PostgreSQL มาแล้ว s/MIT/AGPL/ จากนั้นแจกจ่ายต่อ เป็นสิ่งที่ทำได้ตามกฎหมาย เวอร์ชันต้นฉบับที่เป็น MIT ก็ยังมีอยู่เหมือนเดิม ดังนั้นจนกว่าจะมีฟีเจอร์ใหม่ที่น่าเชื่อจริง ๆ ก็ไม่มีเหตุผลอะไรให้ต้องชอบเวอร์ชันนั้นมากกว่า
    • แม้จะไม่เหมือนกันเสียทีเดียว แต่การ สร้างโมเดล 3D ใหม่จากชุดแบบเดิม ย่อมเร็วและง่ายกว่าการทำตั้งแต่ศูนย์มาก เพราะมีการตัดสินใจจำนวนมากถูกทำไว้แล้ว
    • สำหรับโปรเจ็กต์ขนาดระดับ Postgres การดูแลต่อโดยไม่มี AI แทบจะเป็นไปไม่ได้เลย ถ้าจำไม่ผิด Postgres มี เกิน 1 ล้านบรรทัด

  • วิธีที่ดีที่สุดในการทดสอบสิ่งนี้น่าจะเป็นการวาง พร็อกซีอย่าง PgBouncer ไว้หน้าฐานข้อมูลโปรดักชันที่มีโหลดสูง แล้วมิเรอร์คิวรีไปทั้ง Postgres เดิมและเวอร์ชัน Rust พร้อมกัน
    แบบนั้นก็จะเทียบทั้งผลลัพธ์และประสิทธิภาพบนโหลดจริงได้ พอรันไปสักพักก็ยังเทียบตารางทีละตัวกับอินสแตนซ์ Postgres ปกติได้ด้วย

  • โค้ดแบบนี้ควรรีวิวอย่างไร? ปกติจะไล่ดูประวัติ commit เพื่อดูว่าคนทำอะไรกันไปบ้างและทำอย่างไร แต่ถ้า LLM สร้าง 7101 commits ภายในเวลาไม่ถึงเดือนก็แทบเป็นไปไม่ได้
    แค่ดูของวันเดียวก็เยอะเกินไปแล้ว [1] ยังไงเสีย เนื้อหาใน commit เองก็อาจไม่ได้บอกอะไรนักด้วย อยากรู้เหมือนกันว่าบน GitHub จะไปที่ commit แรกของ repository ได้ง่าย ๆ อย่างไร การไล่ดูประวัติ commit รู้สึกค่อนข้างยุ่งยาก
    [1] - https://github.com/malisper/pgrust/commits/main/?since=2026-...

    • กำลังทำงานร่วมกับ malisper ใน pgrust อยู่ สำหรับโปรเจกต์แบบนี้ ดูเหมือนว่าโฟกัสจะขยับจากการรีวิวแต่ละ commit ไปเป็นการรีวิว กระบวนการทดสอบและการทำ fuzzing มากกว่า
      ต้องไปให้ไกลกว่าการทดสอบ regression, isolation และ fault ของ Postgres มาก ดูบทความของ danluu ที่เกี่ยวข้อง: https://danluu.com/ai-coding/
    • github cli มีคำสั่งสำหรับ query commits พร้อมแฟลกเรียงลำดับจากน้อยไปมาก/มากไปน้อย: https://cli.github.com/manual/gh_search_commits
      เอกสารไวยากรณ์อย่าง before x date อยู่ที่นี่: https://docs.github.com/en/search-github/searching-on-github...
      มีหน้า advanced search ด้วย แต่ไม่รองรับ commits ด้วย date filter: https://github.com/search/advanced
      จะใช้การค้นหาแบบ binary search กับวันที่ในวิดเจ็ตค้นหาก็ได้ และวันแรกที่มี commit คือที่นี่: https://github.com/malisper/pgrust/commits/main/?since=2026-...
      commit แรก: https://github.com/malisper/pgrust/commit/22113dc36b02973060...
    • โดยทั่วไปแล้ว ถ้าไม่มีประวัติ prompt และไม่สามารถรัน “การคอมไพล์” ของ LLM ซ้ำได้โดยตรง ก็ชวนให้ลังเลว่านี่นับเป็น โอเพนซอร์ส หรือไม่ แม้จะอ่านโค้ดได้ แต่ก็ให้ความรู้สึกใกล้กับโปรเจกต์แบบ “source available” ที่เข้าถึงได้แค่โค้ด แต่เข้าถึงระบบ build ไม่ได้
      ในทางกลับกัน ที่ผ่านมาเราก็ไม่เคยเข้าถึงกระบวนการคิดภายในของนักพัฒนามนุษย์อยู่แล้วนอกจาก commit messages ดังนั้นจะบอกว่า prompt ที่เป็นความลับเท่ากับซอร์สที่ปิดก็อาจไม่ได้เหมือนกันเสียทีเดียว
    • ถ้าจะไปที่ commit แรกบน GitHub แบบง่าย ๆ ใช้รูปแบบ github.com/user/repo/commits/?after=last_commit_hash+number_of_commits-2 ได้ เพราะต้องหัก -1, -1 จาก commit ล่าสุดกับ commit สุดท้าย
      ตัวอย่าง: https://github.com/malisper/pgrust/commits/?after=3646a73515...
    • ไม่ได้รีวิวหรอก ทำได้แค่เชื่อว่า ผ่าน regression tests หมายถึงเข้ากันได้กับต้นฉบับอย่างสมบูรณ์

  • น่าประทับใจอยู่ แต่เป็นการเปลี่ยนไลเซนส์จาก PostgreSQL license [0] ไปเป็น AGPL [1]
    ผมชอบ AGPL และคิดว่าเป็นหนึ่งในไลเซนส์โอเพนซอร์สเสรีที่ดีที่สุดจริง ๆ แต่ก็กังวลเรื่องความเข้ากันได้ ถ้าเป็นการเขียนใหม่จากซอร์สต้นฉบับ ก็น่าจะต้องใช้ไลเซนส์เดิมไม่ใช่หรือ? ผมคิดว่าใช่ ก่อนหน้านี้ก็มีแนวโน้มแบบเดียวกัน เช่น Rust coretools ที่เขียนซอฟต์แวร์โอเพนซอร์สใหม่ภายใต้ไลเซนส์ที่จำกัดกว่า แม้การเลือก AGPL จะดูมีจริยธรรมกว่ามาก แต่ถ้าไม่เปลี่ยนเลยจะปลอดภัยกว่าไหม?
    [0] https://www.postgresql.org/about/licence/
    [1] https://github.com/malisper/pgrust?tab=AGPL-3.0-1-ov-file

    • น่าจะเข้าใจทิศทางของความเข้มงวดกลับด้าน uutils coreutils ที่ใช้ไลเซนส์ MIT มีข้อจำกัดน้อยกว่า GNU coreutils ที่ใช้ GPL และ AGPL ก็มีข้อจำกัดมากกว่า PostgreSQL license
      การแจกจ่ายฉบับเขียนใหม่ภายใต้ไลเซนส์ที่เข้มงวดกว่านั้นไม่ได้ละเมิด PostgreSQL license เหตุผลที่ไลเซนส์ตระกูล MIT มีข้อจำกัดน้อยกว่า GPL หรือ AGPL ก็เพราะมันอนุญาตให้ relicense ไปเป็นไลเซนส์ที่เข้มงวดกว่าได้
    • ถ้าไม่ชอบไลเซนส์ ก็แค่ให้ LLM “พอร์ต” อยู่สองสามวันแล้วค่อยติดไลเซนส์ที่ต้องการ เดี๋ยวนี้ดูเหมือนเขาทำกันแบบนั้น
    • PostgreSQL license เป็นไลเซนส์สาย BSD แบบดัดแปลง จึง เข้ากันได้กับ (A)GPL
      ให้เข้าใจแบบนี้: สร้างโปรเจกต์ (A)GPL เปล่าขึ้นมาแล้วนำ codebase BSD ต้นน้ำเข้ามา ไฟล์ต้นน้ำดั้งเดิมยังคงอยู่ภายใต้ไลเซนส์แบบ permissive เดิม แต่ทั้งโปรเจกต์จะถูกกำกับโดย (A)GPL พร้อมข้อกำหนดเรื่อง attribution ของไลเซนส์ต้นน้ำ ซึ่ง GPL อนุญาตข้อกำหนดแบบนั้นได้ หลังจากนั้นก็เพิ่มโค้ดของตัวเองภายใต้ AGPL และแจกจ่ายงานที่รวมกันภายใต้ AGPL ได้
      ถ้าใครเอาเฉพาะส่วนโค้ดที่คุณเขียนไป ก็ทำตาม AGPL อย่างเดียวก็พอ แต่ถ้ารวมซอร์สต้นน้ำไปด้วย ก็ยังต้องปฏิบัติตามข้อกำหนด attribution ของไลเซนส์ต้นน้ำต่อไป
    • ไลเซนส์ของ Postgres เข้ากันได้กับ AGPL อย่างสมบูรณ์อยู่แล้ว BSD/MIT permissive กว่า

  • มี unsafe { 2664 จุด และ unsafe fn 1835 จุด แบบนี้ไม่ปลอดภัยอย่างสิ้นเชิง ดูไม่เหมือนการเขียนใหม่ที่เข้าใจว่าเกิดอะไรขึ้นจริง ๆ และควรออกแบบสถาปัตยกรรมใหม่อย่างไรเพื่อดึงข้อดีของ Rust ออกมา
    แต่ดูเหมือน การแปลงที่สร้างโดย AI ซึ่งใช้ raw pointer อย่างกว้างขวาง มากกว่า

    • unsafe ส่วนใหญ่ถูกกักอยู่ใน parser ที่สร้างจากการรัน c2rust กับ Postgres parser โดยตัว Postgres parser เองก็ถูกสร้างจาก yacc/bison อยู่แล้ว จึงเลือกพอร์ตแบบเชิงกลมากกว่าจะย้ายไปเป็น Rust แบบเป็นธรรมชาติ
      ถ้ามี unsafe จุดไหนที่คิดว่าร้ายแรงเป็นพิเศษก็บอกมาได้
    • โปรเจกต์ LLM ที่เขียนด้วย Rust ทั้งหมดของผมตั้งค่า unsafe=deny ไม่เข้าใจเหมือนกันว่าทำไมถึงไม่คาดกันว่าจะเจอปฏิกิริยาแบบนี้
    • ก็แค่คัดลอกคอมเมนต์รีวิวนี้ไปใส่ในพรอมป์ต์ตรง ๆ ได้เลย อีกไม่กี่ชั่วโมงก็น่าจะกลายเป็น “แก้แล้ว!”

  • น่าจะต้องแยกให้ชัดระหว่างการเขียนใหม่กับ การเขียนใหม่ด้วย AI

    • ตัวอย่างเช่น การเขียน TypeScript ใหม่เป็น Go นั้นส่วนใหญ่ทำโดยมนุษย์ และใช้เวลาถึง 1 ปีกว่าจะเปิดเผยออกมา การเขียนซอฟต์แวร์ใหม่ที่คนเชื่อถือได้มันเป็นแบบนั้น
    • ดูเหมือนจะไม่ง่ายขนาดนั้น โปรเจกต์ใหม่ที่ทะเยอทะยานแทบ 100% น่าจะใช้ AI ในระดับหนึ่ง ผมรู้จักบางโปรเจกต์ที่มีนโยบายไม่ใช้ AI แบบเข้มงวด เช่น Zig แต่ถือว่าเป็นส่วนน้อยมาก
      ถ้าอย่างนั้นต้องใช้ AI มากแค่ไหนถึงจะเรียกว่าเป็น “การเขียนใหม่ด้วย AI”?
    • การเขียนใหม่ดูเหมือนเป็นงานที่ LLM เหมาะกว่ามนุษย์เสียอีก เพราะส่วนใหญ่เป็น งานซ้ำ ๆ ตรงไปตรงมา และ LLM ก็เหมาะกับงานแปล ถ้าจำไม่ผิด สถาปัตยกรรมทรานส์ฟอร์เมอร์เองก็ถูกคิดค้นขึ้นมาเพื่อการแปลแต่แรก
    • การเขียนใหม่โดยมนุษย์ที่ไม่มีการดูแลต่อก็เป็นแค่โปรเจกต์งานอดิเรก ส่วนการเขียนใหม่ด้วย AI นี่ไม่รู้เลยว่าเผาโทเคนไปเพื่ออะไร
    • ตอนนี้มันกลายเป็นแค่ ขั้นตอนในกระบวนการ build ไปแล้ว

  • เห็นหลายกรณีที่โปรเจกต์เขียนใหม่แบบนี้อ้างว่ามันทำงานได้เพราะพึ่งพาการทดสอบ แต่สิ่งที่ทำให้ซอฟต์แวร์อย่าง Postgres หรือ SQLite น่าเชื่อถือ ไม่ใช่ตัวการทดสอบล้วน ๆ เท่ากับ บาดแผลที่สะสมมาจากสภาพแวดล้อม production
    ความน่าเชื่อถือถูกสั่งสมจากการรันจริงใน production เป็นเวลาหลายปี

    • test suite ขนาดมหึมาส่วนใหญ่ก็คือบาดแผลจาก production นั่นเอง เพราะทุกครั้งที่เกิดบั๊กหรือ regression ก็จะมีการเขียนเทสต์เพื่อยืนยันพฤติกรรมที่ถูกต้อง
      SQLite เป็นตัวอย่างที่ดี ชุดทดสอบมหาศาลที่ไม่เปิดเผยของ SQLite มักถูกยกเป็นเหตุผลว่าทำไมคนถึง fork ได้ยาก Turso ทำสำเร็จจริง แต่การจะรับประกันความเอาจริงเอาจังในระดับเดียวกันได้ก็ต้องมีบริษัทคอยหนุน และแน่นอนว่าต้องใช้เวลาหลายปีใน production ด้วย
    • ไม่ได้พูดถึงการเขียนใหม่นี้โดยเฉพาะ แต่การทดสอบคือ สเปก ที่บอกว่าซอฟต์แวร์ควรทำงานอย่างไร ถ้าพฤติกรรมบางอย่างไม่ได้ถูกครอบคลุมด้วย automated test ไม่ว่าจะรูปแบบไหน ก็ไม่สามารถอ้างได้ว่าการเปลี่ยนแปลงใด ๆ จะไม่ทำให้พฤติกรรมนั้นพัง
      การบอกว่าสิ่งใดสิ่งหนึ่งทำงานได้โดยใช้ test suite เดิมที่ไม่แก้ไขเลยนั้นสมเหตุสมผลอย่างยิ่ง โดยเฉพาะเมื่อโปรเจกต์มีขนาดใหญ่ขึ้น บาดแผลจาก production ควรถูกบันทึกและปกป้องไว้ใน test suite ไม่อย่างนั้นบทเรียนเหล่านั้นก็จะสูญหายไป
      SQLite มีชื่อเสียงเรื่อง test suite ขนาดมหึมาและการทำ fuzzing อย่างกว้างขวาง มีโค้ดและสคริปต์ทดสอบมากกว่าโค้ดปกติถึง 590 เท่า ที่มา: https://sqlite.org/testing.html
    • ถ้าอย่างนั้นก็ควรทำให้ส่งต่อความน่าเชื่อถือนั้นกลับไปยัง upstream ได้ง่าย
      ตอนนี้สิ่งที่มีประโยชน์ที่สุดที่ทำได้กับเวอร์ชันแปลงด้วย LLM แบบนี้คือ ถ้าเวอร์ชันแปลงผ่านเทสต์ต้นฉบับทั้งหมด ก็ให้เอา test suite ของแอปพลิเคชันผมไปรันบนมันเพื่อหาว่า test coverage ของต้นฉบับยังขาดตรงไหน
      ถ้าเวอร์ชันแปลง crash หรือมีอาการผิดปกติที่สังเกตได้ ก็แปลว่าโปรเจกต์จริงยังขาด regression test บางอย่างอยู่ ถ้าทำให้รันโปรเจกต์แปลงแบบนี้ได้อย่างปลอดภัยและง่ายดายในฐานะหนึ่งแถวใน integration test matrix ตามปกติ ก็จะช่วยให้ upstream ป้องกันการทำอะไรพังโดยไม่ตั้งใจในอัปเดตอนาคตได้ดีขึ้นมาก
    • เห็นด้วย และก็เห็นด้วยกับคอมเมนต์ข้าง ๆ ที่บอกว่าทุกครั้งที่เกิดบั๊กหรือ regression ก็ควรเขียนเทสต์เพื่อยืนยันพฤติกรรมที่ถูกต้อง
      แต่สิ่งที่ไม่เห็นในการเขียนใหม่แบบนี้คือ แล้วบั๊กใหม่ที่ถูกนำเข้ามาเพราะการเขียนใหม่เองจะจัดการอย่างไร? สุดท้ายมันก็ต้องถูกทดสอบในสถานการณ์จริงของโลกความเป็นจริงด้วยไม่ใช่หรือ?
    • ยังมีอีกวิธีในการตรวจสอบการเขียนใหม่ แค่ รัน pgrust กับ postgres ควบคู่กัน แล้วเทียบผลลัพธ์ก็พอ
      ถ้ารู้ edge case ก็เอาไปรันด้วยได้ และถ้าไม่รู้ ก็ใช้ fuzzer หรือเครื่องมืออัตโนมัติหาข้อมูลนำเข้าที่น่าสนใจได้ ถ้าเจอความไม่ตรงกัน คู่ข้อมูลนำเข้า/ผลลัพธ์นั้นก็จะกลายเป็น test case ได้ทันที ไม่รู้ว่ามีเครื่องมือแบบนั้นอยู่หรือเปล่า แต่ถ้ามีก็โยนให้ Claude แล้วให้มันเอาเข้าไปอยู่ใน development loop ได้เลย

  • เดโม WebAssembly ที่รันในเบราว์เซอร์นั้นทำได้เนี๊ยบมาก: https://pgrust.com

  • ไม่เข้าใจว่าทำไมถึงมองลบกันขนาดนี้ ผมมองว่าโปรเจ็กต์แบบนี้น่าสนใจในแง่การเรียนรู้และการสำรวจแนวทางใหม่ แล้วมันมีปัญหาตรงไหน?

    • อาจเป็นเพราะเหตุผลประมาณนี้: ไปอาศัยชื่อแบรนด์ที่เป็นที่ยอมรับแล้วอย่าง Postgres + Rust แต่ไม่มีประโยชน์ใช้สอยหรือความก้าวหน้าที่แท้จริง และยังขาดความน่าเชื่อถือ
      โดยเฉพาะเมื่อมีชื่อที่ส่งสัญญาณแรงอย่าง Postgres อยู่ในหัวข้อและชูจุดนั้นขึ้นมา แต่กลับไม่ชัดเจนว่าใช้งานได้จริงทั้งระยะสั้นและระยะยาว รวมถึงขาดความน่าเชื่อถือทางสังคมและ network effect ก็ดูจะทำให้คนต่อต้านได้ง่าย
    • มันทำให้รู้สึกไม่สบายใจที่เห็นงานหลายสิบปีถูกคัดลอกได้ง่ายแบบนี้
    • ผมสงสัยว่าให้ LLM มาเขียนใหม่แบบนี้ เราได้เรียนรู้อะไรอย่างชัดเจนกันแน่
    • ดูเหมือนผู้คนจะรู้สึกถูกคุกคามเมื่อเห็นว่า LLM ทำงานที่พวกเขาเชื่อว่าต้องอาศัยทักษะและพรสวรรค์ของตัวเองได้ดี
      เข้าใจได้ แต่ก็ไม่ใช่อารมณ์ด้านลบที่สร้างสรรค์นัก และก็ไม่ได้มีเหตุผลมากนักด้วย ในเธรดนี้มีแต่โพสต์ที่พยายามจะบอกว่าสิ่งนี้ไม่มีทางดีได้ ไม่ควรจะดี และสุดท้ายต้องจบลงด้วยหายนะแน่นอน แต่ความจริงที่ว่าสิ่งนี้ผ่านชุดทดสอบอันประณีตนับหมื่นรายการที่สั่งสมมาหลายสิบปี กลับชี้ไปในทางตรงกันข้าม ซึ่งโต้แย้งได้ยาก
      แน่นอนว่ามีโอกาสสูงที่จะเกิดปัญหาใหม่ ๆ แต่ถึงอย่างนั้นก็ยังเป็นความสำเร็จที่น่าประทับใจ
    • กังวลเรื่องคุณภาพ แค่ไล่ดูโค้ดผ่าน ๆ ก็ดูงี่เง่าแล้ว เว้นแต่ว่าผมจะมองไม่ออกเองว่ามันอัจฉริยะตรงไหน
      https://github.com/malisper/pgrust/blob/3646a73515a5e4ac7d0b...
      https://github.com/malisper/pgrust/blob/3646a73515a5e4ac7d0b...