C में एक आधुनिक वेब ऐप
सादे C, CGI, SQLite और OpenBSD के httpd का उपयोग करके एक “modern” web app बनाना minimalist stacks के लिए उत्साह जगाता है, साथ ही C की सुरक्षा और internet-exposed services के लिए उसकी उपयुक्तता पर लंबे समय से चल रही बहसों को फिर से उभारता है। कई टिप्पणीकार single static binary को प्रति request चलाने की सरलता, पूर्वानुमेयता, और छोटे dependency surface को पसंद करते हैं, खासकर nginx, app servers, और बड़े frameworks वाले multi-layer setups की तुलना में। आलोचक जवाब देते हैं कि string handling, concurrency, और memory safety C को Go, Rust, या PHP/FastCGI की तुलना में खराब विकल्प बनाते हैं, और तर्क देते हैं कि किसी भी performance या architectural लाभ को security risks तथा modern observability और maintenance की वास्तविकताओं के साथ तौलना चाहिए.
C और BCHS stack का चयन
- कई लोग OpenBSD httpd और SQLite (BCHS) के साथ सादे C में एक “आधुनिक” वेब ऐप बनाने से आकर्षित हैं।
- अनुमानित प्रेरणाएँ: न्यूनतम निर्भरताएँ, पूर्वानुमेय व्यवहार, OpenBSD के pledge/unveil के साथ सटीक मेल, और यह भावना कि C “आपके दिमाग में समा जाता है।”
- कुछ लोग सवाल करते हैं कि C के बजाय C++, Rust, Go, या PHP क्यों नहीं चुना गया, और तर्क देते हैं कि अन्य भाषाएँ अधिक सुरक्षा और टूलिंग के साथ समान सादगी दे सकती हैं।
CGI, process model, और प्रदर्शन
- मूल डिज़ाइन: CGI, हर request के लिए एक नया process। समर्थकों को isolation, तैनाती की सरलता (एक binary बदलना), और जटिल app servers की अनुपस्थिति पसंद है।
- आलोचक CGI को एक “half measure” और “inefficient” कहते हैं, process creation overhead और shared state की कमी की ओर इशारा करते हुए; वे FastCGI, in‑process modules, या custom HTTP servers का सुझाव देते हैं।
- अन्य लोग जवाब देते हैं कि आधुनिक kernels
forkको low/medium traffic के लिए पर्याप्त सस्ता बनाते हैं, और इस मॉडल की तुलना आज के “serverless” functions से करते हैं।
SQLite और concurrency
- एक SQLite file पर कई concurrent requests के टकराने को लेकर प्रश्न उठे।
- उत्तर: WAL mode सक्षम करने से कई concurrent readers के साथ एक single writer संभव होता है; file locking process concurrency को संभालती है। Writes फिर भी serialize होते हैं, लेकिन network hops के बिना तेज़ रहते हैं।
String handling और C ergonomics
- कई लोग नोट करते हैं कि C में HTML/CSS output करना सहनीय है; parsing और सामान्य string handling कठिन हिस्से हैं।
- कुछ लोग इसे custom string builders/views और fixed-size buffers से, allocations से बचते हुए, कम करते हैं।
Security और language choices
- नए C code को internet पर expose करने को लेकर तीखा मतभेद है।
- आलोचक: C की memory unsafety बार-बार RCEs की ओर ले जाती है; अधिक सुरक्षित विकल्प (Rust, “C-style C++”) मौजूद हैं।
- समर्थक: अधिकांश अंतर्निहित infrastructure (kernels, web servers, DBs) पहले से C/C++ में है; सावधानीपूर्वक design, OpenBSD hardening, और छोटा, auditable code सुरक्षित हो सकता है।
- Rust की memory safety की सराहना की जाती है, लेकिन भारी dependency graphs और “supply chain” जोखिम की आलोचना भी होती है; C को memory safety के बदले सरल, छोटे dependency surfaces के रूप में देखा जाता है।
सादगी बनाम आधुनिक stacks
- कई लोग CGI और शुरुआती PHP/Perl दिनों के लिए nostalgia और आज के multi-layered stacks (nginx → app server → framework → ORM, आदि) से थकान व्यक्त करते हैं।
- कुछ तर्क देते हैं कि modern layers आवश्यक features (observability, scaling, rate limiting) जोड़ती हैं, जबकि अन्य कहते हैं कि छोटे sites और internal tools के लिए ये overkill हैं।
Frontend, UX, और AI-writing संबंधी चिंताएँ
- कई टिप्पणीकारों को प्रदर्शित site का design पढ़ने में कठिन और low-contrast लगता है।
- कई लोगों को संदेह है कि blog post के कुछ हिस्से AI-written हैं, हालांकि अन्य इससे असहमत हैं और बताते हैं कि AI detectors अविश्वसनीय हैं।