Three dominant themes
| Theme | Supporting quotations |
|---|---|
| 1. Practical utility and performance of Fil‑C | > "I’m biased since I’m the Fil. It was materially useful in this project – caught multiple memory‑safety issues in a nice deterministic way... C++ with accurate GC is a really great programming model. I feel like it speeds me up by 1.5× relative to normal C++, and maybe 1.2× relative to other GC’d languages." – pizlonator |
| 2. Suitability for greenfield vs. legacy work | > "It made sense because I was able to move very quickly, and once perf became a problem I could move to Yolo‑C++ without a full rewrite." – pizlonator > "I’m curious. Given the overheads of Fil‑C++, does it actually make sense to use it for greenfield projects?" – vlovich123 |
| 3. Interpreter speed & language‑design impact | > "Python’s execution time is mostly spent looking up stuff... VBA is not fast. VBA is really slow." – psychoslave > "Lua is way more dynamic... The Python interpreter has some fast paths for specific object types, but it is really limited in the optimizations it can do, because there simply aren’t any unboxed types." – pizlonator > "The jump from change #5 to #6 (inline caches + hidden‑class object model) doing the bulk of the work here really tracks with how V8/JSC got fast historically..." – jiusanzhou |
Summary
The discussion centers on (1) the tangible productivity and safety gains offered by Fil‑C/C++, (2) whether its use is justified for new projects or merely for maintaining existing code, and (3) how language‑design choices directly affect interpreter speed and optimization, illustrated through comparisons with Lua, Python, and other runtimes.