Postgres को Rust में फिर से लिखा गया, अब Postgres regression tests 100% पास

 (github.com/malisper)
1 पॉइंट द्वारा GN⁺ 5 시간 전 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • pgrust Rust में Postgres को फिर से लिखने वाला प्रोजेक्ट है, जिसका लक्ष्य Postgres 18.3 compatibility है, और यह 46,000 से अधिक regression queries में Postgres के expected output से मेल खाता है
  • इसमें disk compatibility है, जिससे यह मौजूदा Postgres 18.3 data directory से boot हो सकता है, और वास्तविक Postgres tests को व्यवहार का मानक मानता है
  • फिलहाल यह production-ready नहीं है, performance optimization भी अभी नहीं की गई है, और मौजूदा Postgres extensions तथा PL/Python·PL/Perl·PL/Tcl जैसी procedural language extensions आम तौर पर compatible नहीं हैं
  • इसे WebAssembly demo और Docker image malisper/pgrust:v0.1 से चलाकर देखा जा सकता है; latest फिलहाल उसी release की ओर इशारा करता है, लेकिन fixed run image v0.1 है
  • रोडमैप में multi-threaded Postgres internals, built-in connection pooling, JSON-केंद्रित workloads में सुधार, no-vacuum storage experiments, और AI-generated SQL के लिए runtime guardrails शामिल हैं

pgrust के लक्ष्य और compatibility

  • pgrust Postgres को Rust में फिर से लिखने वाला प्रोजेक्ट है
  • इसका target Postgres 18.3 है, और यह 46,000 से अधिक regression queries में Postgres के expected output से मेल खाता है
  • यह मौजूदा Postgres 18.3 data directory से boot हो सकने वाली disk compatibility प्रदान करता है
  • प्रोजेक्ट का लक्ष्य Postgres को अंदरूनी तौर पर बदलना आसान बनाना है
    • व्यवहार Postgres जैसा बनाए रखा जाता है
    • वास्तविक Postgres tests को आधार के तौर पर इस्तेमाल किया जाता है
    • Rust और AI-assisted programming के साथ server में गहरे बदलावों को explore किया जाता है

मौजूदा स्थिति और सीमाएँ

  • pgrust अभी production-ready नहीं है
  • अभी performance optimization नहीं की गई है
  • मौजूदा Postgres extensions और procedural language extensions आम तौर पर अभी compatible नहीं हैं
    • PL/Python
    • PL/Perl
    • PL/Tcl
  • कुछ bundled contrib modules पहले ही port किए जा चुके हैं, और समय के साथ और अधिक compatibility संभव हो सकती है

चलाने का तरीका

  • WebAssembly demo https://pgrust.com पर चलाकर देखा जा सकता है
  • Docker run के लिए malisper/pgrust:v0.1 image का उपयोग करें
    • image के अंदर मौजूद psql client का उपयोग करें
    • malisper/pgrust:latest फिलहाल उसी release की ओर इशारा करता है
    • fixed release 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

source से build और run

  • 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 tools और ICU, OpenSSL, LDAP, PAM, Postgres 18 client install करें
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 vendored Postgres 18.3 shared directory specify करके cargo build से किया जाता है
PGRUST_PGSHAREDIR="$PWD/vendor/postgres-18.3/share" \
cargo build --release --locked --bin postgres
  • data directory pgrust के --initdb से बनाई जाती है
target/release/postgres --initdb \
  -D /tmp/pgrust-data \
  -L "$PWD/vendor/postgres-18.3/share" \
  --no-locale \
  --encoding UTF8 \
  -U postgres
  • run करते समय stack से जुड़ी settings और synchronous I/O setting साथ में उपयोग करें
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 tests और verification results

  • Postgres regression tests scripts/run-regression से चलाए जाते हैं
PGRUST_BIN="$PWD/target/release/postgres" \
scripts/run-regression
  • test runner pgrust के अपने --initdb और repository में शामिल Postgres 18.3 test files का उपयोग करता है
  • PATH में Postgres 18 psql client होना चाहिए
    • अगर वह किसी दूसरी location पर है, तो PGRUST_PSQL=/path/to/psql set करें
  • verified release result यह है कि pgrust 46,000 से अधिक regression queries में Postgres के expected output से मेल खाता है

roadmap और project history

  • roadmap में ये items शामिल हैं

    • multi-threaded Postgres internals

      • built-in connection pooling
      • JSON-केंद्रित workloads के लिए बेहतर support
      • तेज fork और branching workflow
      • no-vacuum design सहित storage experiments
      • गलत queries और AI-generated SQL के लिए runtime guardrails
      • अचानक खराब execution plan में switch होने की घटनाएँ कम करना
      • मौजूदा repository में pgrust की एक नई implementation है, जिसने regression test milestone हासिल कर लिया है
      • पिछली public implementation archive/pre-fabled-2026-06-23 में archive की गई है
      • संबंधित background links
      • Original pgrust launch
      • 67% regression update
      • Four Horsemen roadmap
      • license AGPL-3.0 है

संबंधित पढ़ाई

1 टिप्पणियां

 
GN⁺ 5 시간 전
Hacker News की राय

  • मूल लेखक हूं। अंदाज़ा नहीं था कि यह यहां आ जाएगा। संक्षेप में, मैं LLM के साथ बेहतर Postgres बनाने का एक प्रयोग कर रहा था, और मुझे लगता है कि Postgres 30 साल पुराना है, इसलिए इस दौरान databases के बारे में हमने बहुत कुछ सीखा है
    rewrite में उपयोगी कई techniques redesign में भी उपयोगी हैं। pgrust का नया version, जिसे अभी public नहीं किया गया है, फिलहाल Postgres regression tests 100% पास करता है, Postgres के process-per-connection model की जगह thread-per-connection model लागू करता है, और transactional workloads में Postgres से 50% तेज़ व analytical workloads में लगभग 300 गुना तेज़ है
    अभी clickbench पर यह ClickHouse से 2 गुना धीमा है, लेकिन मुझे लगता है कि यह ClickHouse से भी तेज़ हो सकता है। सवाल हों तो जवाब दूंगा

    • Thread-per-connection performance के नजरिए से लगभग हमेशा सही चुनाव है, लेकिन Postgres के process-per-connection चुनने की वजह से आप संदिग्ध extensions को मनमाने ढंग से load कर सकते हैं। सबसे खराब स्थिति में पूरा database नहीं, सिर्फ वह process मरता है। अच्छा होगा अगर ऐसा संतुलन मिले कि extension में segmentation fault होने पर पूरा नहीं, केवल कुछ connections मरें
    • OLTP में 50% सुधार थोड़ा संदिग्ध लगता है। बिना आधार के आरोप नहीं लगाना चाहता और मैं खुद भी benchmark दावे अक्सर करता हूं, लेकिन standard benchmark इस्तेमाल किया गया है यह जानते हुए भी कुछ intuition alarm दे रहा है
      कहीं MVCC को तोड़कर ऐसा trade-off किया गया हो सकता है जो production में नहीं जा सकता। regression tests पास करने की बात देखी है। क्या fsync enabled है? मेरी समझ में regression tests खराब I/O patterns को अच्छे से नहीं पकड़ते। फिर भी project दिलचस्प लगता है
    • Postgres और databases के बारे में वास्तविक background और expertise जानना चाहूंगा। आखिरकार जानना यह है कि क्या इन्हें ठीक-ठीक पता है कि ये क्या कर रहे हैं, या कोई बड़ा अनदेखा landmine छिपा है
    • यह product launch से ज्यादा एक experiment लग रहा था, जिसे किसी ने HN spotlight bus के नीचे धकेल दिया हो। जिज्ञासा है कि क्या यह LLM coding से कितनी दूर तक जा सकते हैं देखने का experiment है, या पहले बनाकर यह देखने का कि LLM द्वारा लिखे code में से कितना accept किया जा सकता है
    • analytical workloads में Postgres से लगभग 300 गुना तेज़ और ClickHouse से 2 गुना धीमा होने का मतलब क्या data को column-oriented format में store करना है? या row-oriented और column-oriented दोनों इस्तेमाल हो रहे हैं?
      इसी से मिलता-जुलता लेकिन अलग काम करते हुए δx बना रहा हूं। यह एक Postgres extension है जो सामान्य Postgres tables के अंदर column-oriented compressed data store करता है, इसलिए replication, crash recovery, pg_dump आदि वैसे ही काम करते हैं: https://github.com/xataio/deltax
      फिलहाल single node के आधार पर ClickHouse से 30–40% धीमा है। clickbench में जोड़ने वाला PR अभी-अभी accept हुआ है, इसलिए यहां comparison देख सकते हैं: https://benchmark.clickhouse.com/#system=+liH|_etx|gQ|saB&ty...

  • इस तरह के rewrites मुझे ठीक से समझ नहीं आते। आमतौर पर इन्हें एक व्यक्ति drive करता है, जिससे single point of failure बनना आसान है, और ये बहुत कम समय में बनते हैं, इसलिए यह मानना मुश्किल है कि project को लगातार बनाते रहने की discipline सीखी गई है
    medium-to-long term में इसके maintain रहने की संभावना भी कम लगती है। योगदान देने वालों को token cost भी देनी होगी। क्योंकि AI के बिना ऐसे projects maintain करना लगातार मुश्किल होता जा रहा है। क्या कोई इसे production में डालना चाहेगा? ज्यादा समझ में नहीं आता

    • यह सिर्फ simple rewrite नहीं है, इसमें improvements भी हैं। मज़े के लिए मैंने कुछ similar किया था; देखना चाहता था कि old design और खासकर PostgreSQL side के लोगों द्वारा “इसे अलग तरह से नहीं किया जा सकता” कहे गए हिस्सों को improve किया जा सकता है या नहीं। असल में अलग तरह से किया जा सकता है
      production में नहीं डालूंगा, लेकिन database internals के बारे में बहुत कुछ सीखा। LLM era में भी दिमाग को आनंद देने के लिए, हमारे production database में भी LLM के बिना database features implement किए। अभी Flexible Paxos से जूझ रहा हूं; शायद पुराने, stable और simple Raft का ही इस्तेमाल जारी रखूंगा, फिर भी यह दिलचस्प है
    • इसे एक दिलचस्प proof of concept मानता हूं। यह सिर्फ Rust में PostgreSQL rewrite करना नहीं, बल्कि चुनी गई dependencies, threading model में बदलाव, और अन्य architecture changes की possibilities test करना भी है
      LLMs prototypes बेहद तेजी से निकालने में मजबूत हैं, और working prototype कई अनुमानों को खत्म कर सकता है। अगर original team या उसके बराबर substantial लोग support में न हों, और यह भरोसेमंद explanation न हो कि original code quality और maintenance की बराबरी की गई है या उससे आगे निकले हैं, तो इतने बड़े project का rewrite version मैं शायद इस्तेमाल नहीं करूंगा
      आम तौर पर LLM से license laundering करना कानूनी और नैतिक दोनों तरह से defend करना मुश्किल लगता है। हालांकि इस case में फर्क है क्योंकि इन्होंने ज्यादा restrictive license चुना है। मैं lawyer नहीं हूं, लेकिन मेरी समझ में PostgreSQL download करके s/MIT/AGPL/ करने के बाद distribute करना कानूनी तौर पर possible है। original MIT-licensed version तो जस का तस है, इसलिए जब तक compelling new features न आएं, उस version को prefer करने की कोई खास वजह नहीं है
    • पूरी तरह समान नहीं, लेकिन मौजूदा drawings के set के आधार पर 3D model फिर से बनाना शुरुआत से बनाने की तुलना में कहीं तेज़ और आसान होता है। क्योंकि बहुत सारे decisions पहले ही लिए जा चुके होते हैं
    • Postgres जैसे scale के project में AI के बिना maintain करना practically लगभग impossible है। अगर याद सही है तो Postgres 10 लाख lines से ज्यादा है

  • इसे test करने का सबसे अच्छा तरीका शायद किसी busy production database के सामने PgBouncer जैसा proxy रखकर queries को existing Postgres और Rust version दोनों में simultaneously mirror करना है
    तब real load पर output और performance compare कर सकते हैं। कुछ समय चलाने के बाद regular Postgres instance और tables को एक-एक करके compare भी किया जा सकता है

  • ऐसे code की समीक्षा कैसे करनी चाहिए? आम तौर पर commit history पर सरसरी नज़र डालकर देखते हैं कि लोगों ने क्या और कैसे काम किया, लेकिन अगर LLM एक महीने से भी कम समय में 7101 commits बना दे, तो यह असंभव है
    सिर्फ एक दिन का भी देखें तो बहुत ज़्यादा है [1]. वैसे भी commit की सामग्री शायद बहुत कुछ न बताए. GitHub पर repository के पहले commit तक आसानी से जाने का तरीका भी जानना चाहूंगा. Commit history में नेविगेट करना काफ़ी झंझट भरा लगता है
    [1] - https://github.com/malisper/pgrust/commits/main/?since=2026-...

    • मैं pgrust पर malisper के साथ काम कर रहा हूं. ऐसे project में हर commit की समीक्षा करने के बजाय, ध्यान testing और fuzzing process की समीक्षा पर शिफ्ट होगा लगता है
      Postgres के regression, isolation, failure tests से कहीं आगे जाना होगा. संबंधित danluu लेख: https://danluu.com/ai-coding/
    • github cli में sort ascending/descending flag के साथ commits query करने की command है: https://cli.github.com/manual/gh_search_commits
      before x date जैसी syntax के docs यहां हैं: https://docs.github.com/en/search-github/searching-on-github...
      advanced search page भी है, लेकिन date filter से commits support नहीं करता: https://github.com/search/advanced
      search widget में date को binary search भी कर सकते हैं, और जिस पहले दिन commits हैं वह यहां है: https://github.com/malisper/pgrust/commits/main/?since=2026-...
      पहला commit: https://github.com/malisper/pgrust/commit/22113dc36b02973060...
    • सामान्य तौर पर, अगर prompt history नहीं है और LLM “compile” को सीधे फिर से run नहीं किया जा सकता, तो यह open source है या नहीं, यह अस्पष्ट है. यह कुछ-कुछ “source-available” project जैसा लगता है, जहां code पढ़ सकते हैं लेकिन build system तक access नहीं है
      दूसरी तरफ, commit messages को छोड़ दें तो human developer की internal thought process तक भी हमारी कभी पहुंच नहीं रही, इसलिए secret prompts को private source कहना भी पूरी तरह वही बात नहीं हो सकती
    • GitHub पर पहले commit तक आसानी से जाने के लिए github.com/user/repo/commits/?after=last_commit_hash+number_of_commits-2 syntax इस्तेमाल कर सकते हैं. latest commit और last commit की वजह से -1, -1 करने जैसा है
      उदाहरण: https://github.com/malisper/pgrust/commits/?after=3646a73515...
    • समीक्षा नहीं करते. बस यह मानना पड़ता है कि regression tests pass होना original के साथ पूरी compatibility का मतलब है

  • प्रभावशाली तो है, लेकिन यह PostgreSQL license [0] से AGPL [1] में बदला हुआ license change है
    मुझे AGPL पसंद है और मैं इसे सचमुच free open source licenses में सबसे अच्छा मानता हूं, लेकिन compatibility को लेकर चिंता है. अगर original source से rewrite किया है, तो original license लागू नहीं होना चाहिए क्या? मुझे तो ऐसा लगता है. Rust के coretools की तरह open source software को ज्यादा restrictive license में rewrite करने का trend रहा है. AGPL चुना है, इस लिहाज़ से यह कहीं ज्यादा ethical दिखता है, लेकिन शायद बिल्कुल बदलाव न करना ज्यादा safe नहीं होता?
    [0] https://www.postgresql.org/about/licence/
    [1] https://github.com/malisper/pgrust?tab=AGPL-3.0-1-ov-file

    • लगता है आपने restrictiveness की दिशा उलटी समझी है. MIT-licensed uutils coreutils, GPL वाले GNU coreutils से कम restrictive है, और AGPL, PostgreSQL license से ज्यादा restrictive है
      rewrite version को ज्यादा restrictive license में distribute करना PostgreSQL license का उल्लंघन नहीं करता. MIT-family licenses GPL या AGPL से कम restrictive इसी वजह से हैं कि वे ज्यादा restrictive relicensing की अनुमति देते हैं
    • अगर license पसंद नहीं है, तो LLM से कुछ दिनों तक “porting” करवा लें और फिर अपनी पसंद का license लगा दें. आजकल apparently ऐसा ही किया जाता है
    • PostgreSQL license, BSD license का एक variant है, इसलिए (A)GPL compatible है
      इसे इस तरह समझें. एक खाली (A)GPL project बनाते हैं और upstream BSD codebase ले आते हैं. original upstream files अपने original permissive license के तहत रहती हैं, लेकिन पूरा project upstream license की attribution requirement सहित (A)GPL के अधीन होता है. GPL ऐसी requirements की अनुमति देता है. उसके बाद आप अपना code AGPL के रूप में जोड़ सकते हैं और combined work को AGPL के तहत distribute कर सकते हैं
      अगर कोई आपके code में से सिर्फ आपके द्वारा लिखा गया हिस्सा लेता है, तो उसे केवल AGPL का पालन करना होगा. लेकिन अगर upstream source भी शामिल करता है, तो upstream license की attribution requirements भी लगातार पूरी करनी होंगी
    • Postgres license पहले से ही AGPL के साथ पूरी तरह compatible है. BSD/MIT ज्यादा permissive हैं

  • unsafe { 2664 बार है, और unsafe fn 1835 बार। यह बिल्कुल भी safe नहीं है। यह ऐसी rewrite नहीं लगती जिसमें सच में समझा गया हो कि क्या हो रहा है, और Rust के फायदे लेने के लिए architecture को कैसे redesign करना चाहिए
    इसके बजाय यह raw pointers का व्यापक इस्तेमाल करने वाला AI-generated conversion लगता है

    • ज़्यादातर unsafe उस parser के अंदर सीमित हैं जो Postgres parser पर c2rust चलाकर generate किया गया है। Postgres parser खुद भी yacc/bison से generate होता है, इसलिए इसे idiomatic Rust में ले जाने के बजाय mechanically port करने का फैसला किया गया
      अगर कोई unsafe आपको खास तौर पर गंभीर लगता है, तो बताएं, अच्छा रहेगा
    • Rust में लिखे जाने वाले LLM projects सभी unsafe=deny पर set किए जाते हैं। समझ नहीं आता कि हर कोई ऐसी reaction की उम्मीद क्यों नहीं करता
    • इस review comment को prompt में ज्यों का त्यों copy-paste कर देना चाहिए। कुछ घंटों बाद शायद “fix हो गया!” हो जाएगा

  • rewrite और AI rewrite के बीच मजबूत अंतर करना चाहिए, ऐसा लगता है

    • उदाहरण के लिए TypeScript की Go rewrite ज़्यादातर इंसानों ने की थी, और public होने में 1 साल लगा था। जिस software rewrite पर लोग भरोसा कर सकें, वह इसी तरह होती है
    • बात इतनी सरल नहीं लगती। नए और ambitious projects में लगभग 100% किसी न किसी हद तक AI का इस्तेमाल करेंगे, ऐसा लगता है। Zig जैसे सख्त no-AI policy वाले कुछ projects के बारे में पता है, लेकिन वे बहुत छोटी minority हैं
      तो फिर AI का इस्तेमाल कितना होना चाहिए कि उसे “AI rewrite” कहा जाए?
    • rewrite ऐसा क्षेत्र लगता है जहाँ LLM इंसानों से बेहतर fit होते हैं। ज़्यादातर यह दोहराव वाला सरल काम है, और LLM translation tasks के लिए अच्छी तरह fit होते हैं। अगर मुझे सही याद है, तो transformer architecture भी मूल रूप से translation के लिए ही invent हुआ था
    • maintenance के बिना human rewrite बस hobby project है। AI rewrite आखिर किस लिए tokens जला रही है, समझ नहीं आता
    • अब तो यह बस build step बन गया है

  • ऐसे rewrite projects अक्सर tests पर निर्भर होकर दावा करते दिखते हैं कि वे काम करते हैं। लेकिन Postgres या SQLite जैसे software को भरोसेमंद बनाने वाली चीज़ tests से ज्यादा production environment में जमा हुए scars हैं
    reliability कई सालों तक production में चलने से जमा होती है

    • विशाल test suite का बड़ा हिस्सा वही production scars हैं। क्योंकि जब भी bug या regression आता है, सही behavior verify करने वाला test लिखा जाता है
      SQLite इसका अच्छा उदाहरण है। SQLite के विशाल private tests को अक्सर ऐसा factor बताया जाता है जिसकी वजह से लोगों के लिए fork करना मुश्किल होता है। Turso ने यह कर दिखाया, लेकिन equivalent seriousness की गारंटी देने के लिए company चाहिए। बेशक, सालों का production usage भी चाहिए
    • यह इस खास rewrite पर judgment नहीं है, लेकिन tests software के सही behavior की specification हैं। अगर कोई behavior automated tests से cover नहीं है, तो आप दावा नहीं कर सकते कि कोई specific change उस behavior को नहीं तोड़ेगा
      मौजूदा unmodified test suite का उपयोग करके यह कहना पूरी तरह reasonable है कि कुछ काम करता है। project जितना बड़ा हो, मेरे हिसाब से यह उतना ही ज्यादा सही है। production से मिले scars को test suite में document और protect किया जाना चाहिए, वरना वे lessons खो जाते हैं
      SQLite अपने विशाल test suite और extensive fuzzing के लिए प्रसिद्ध है। इसमें सामान्य code की तुलना में test code और scripts 590 गुना ज्यादा हैं। स्रोत: https://sqlite.org/testing.html
    • तो फिर उस reliability को upstream में वापस लौटाना आसान बनाना चाहिए
      अभी ऐसे LLM-converted version से किया जा सकने वाला सबसे उपयोगी काम यह है कि अगर converted version original tests सभी pass करता है, तो मेरी application test suite को उस पर चलाकर original की test coverage की कमी ढूंढी जाए
      अगर converted version crash करता है या observable misbehavior दिखाता है, तो इसका मतलब है कि real project में कोई regression test missing था। अगर ऐसे conversion project को routine integration test matrix की एक line के रूप में safely और आसानी से run किया जा सके, तो upstream future updates में गलती से कुछ तोड़ देने से कहीं बेहतर तरीके से बच सकता है
    • सहमत हूं। side comment से भी सहमत हूं कि bug या regression आने पर सही behavior verify करने वाला test लिखा जाता है
      हालांकि ऐसी rewrites में जो नहीं दिखता, वह यह है कि rewrite की वजह से newly introduced bugs का क्या किया जाए। आखिरकार इसे खुद real-world scenarios में चुनौतियां झेलनी ही होंगी, नहीं?
    • rewrite को verify करने के और तरीके भी हैं। बस pgrust और postgres को साथ-साथ run करके outputs compare कर दें
      अगर edge cases पता हैं, तो उन्हें भी run करें; अगर नहीं पता, तो fuzzer या automated tools से interesting inputs खोजें। mismatch मिल जाए तो वह input/output pair अब test case बन जाता है। पता नहीं ऐसा tool मौजूद है या नहीं, लेकिन अगर है तो उसे Claude को देकर development loop में शामिल करा देना चाहिए

  • browser में चलने वाला WebAssembly demo वाकई साफ-सुथरा है: https://pgrust.com

  • समझ नहीं आता लोग इतने नकारात्मक क्यों हैं। ऐसे projects learning के मकसद और नए तरीकों को explore करने के लिहाज से दिलचस्प लगते हैं। इसमें दिक्कत क्या है?

    • शायद वजह यह हो सकती है: Postgres + Rust जैसे established brand name पर सवार होना, पर practical utility या progress न होना, और credibility की कमी
      खासकर जब title में Postgres जैसा strong signal देने वाला नाम हो और उसी को आगे रखा जाए, लेकिन short-term और long-term practicality, social trust, network effects जैसी वजहों से यह साफ तौर पर impractical दिखे, तो लोगों में आसानी से antipathy पैदा होती लगती है
    • दशकों के काम को इतनी आसानी से copy होते देखना असहज है
    • LLM से rewrite करवाने में ठीक-ठीक क्या सीखने को मिलता है, यह जानने की उत्सुकता है
    • लगता है लोग यह देखकर threatened महसूस कर रहे हैं कि LLM उन कामों को अच्छी तरह कर रहा है जिनके लिए वे अपनी skill और talent को ज़रूरी मानते थे
      यह समझ में आता है, लेकिन यह negative भावना न productive है, न बहुत rational। इस thread में ऐसे posts भरे हैं जो यह साबित करने की कोशिश कर रहे हैं कि यह चीज़ अच्छी हो ही नहीं सकती, अच्छी होनी भी नहीं चाहिए, और आखिर में निश्चित रूप से disaster में खत्म होगी। लेकिन यह fact कि इसने दशकों में जमा हुए दसियों हज़ार sophisticated tests pass किए हैं, इसके उलट इशारा करता है। इसका rebuttal मुश्किल है
      बेशक नए issues आने की संभावना ज्यादा है, फिर भी यह impressive achievement है
    • quality को लेकर चिंता है। code को बस सरसरी तौर पर देखने पर भी यह बेवकूफाना लगता है। बशर्ते मैं code की कोई genius वाली बात miss न कर रहा होऊँ
      https://github.com/malisper/pgrust/blob/3646a73515a5e4ac7d0b...
      https://github.com/malisper/pgrust/blob/3646a73515a5e4ac7d0b...