Comment by drschwabe 19 hours ago
When I first read the source for his original QuickJS implementation I was amazed to discover he created the entirety of JavaScript in a single xxx thousand line C file (more or less).
That was a sort of defining moment in my personal coding; a lot of my websites and apps are now single file source wherever possible/practical.
The sqlite3.c file is generated from more finely-grained real sources, see https://www.sqlite.org/src/doc/trunk/README.md
SQLite is only deployed as a single file but the original sources are multiple files. They call it "The Amalgamation".
I honestly think the single file thing is best reserved for C, given how bad the language support for modularity is.
I've had the inverse experience dealing with a many thousand line "core.php" file way back in the day helping debug an expressionengine site (back in the php 5.2ish days) and it was awful.
Unless you have an editor which can create short links in a hierarchical tree from semantic comments to let you organize your thoughts, digging through thousands of lines of code all in the same scope can be exceptionally painful.
C has no problems splitting programs in N files, to be honest.
The reason FB (and myself, for what it is worth) often write single file large programs (Redis was split after N years of being a single file) is because with enough programming experience you know one very simple thing: complexity is not about how many files you have, but about the internal structure and conceptually separated modules boundaries.
At some point you mainly split for compilation time and to better orient yourself into the file, instead of having to seek a very large mega-file. Pointing the finger to some program that is well written because it's a single file, strlongly correlates to being not a very expert programmer.
The file granularity you chose was at the perfect level for somebody to approach the source code and understand how Redis worked. It was my favorite codebases to peruse and hack. It’s been a decade and my memory palace there is still strong.
It reminded me how important organization is to a project and certainly influenced me, especially applied in areas like Golang package design. Deeply appreciate it all, thank you.
> complexity is not about how many files you have, but about the internal structure and conceptually separated modules boundaries.
You probably don't need this, but ...
C's support for modularity is actually rather strong. This PDF gives a good overview of the basic techniques available: http://www.metamodulaire.org/Computing/modular-c.pdf
It may not be immediately obvious how to approach modularity since it isn't directly accomplished by explicit language features. But, once you know what you're doing, it's possible to write very large programs with good encapsulation, that span many files, and which nevertheless compile quite rapidly (more or less instantaneously for an incremental build).
I'm not saying other languages don't have better modularity, but to say that C's is bad misses the mark.
Unironically JavaScript is quite good for single file projects (albeit a package.json usually needed)
You can do a huge website entirely in a single file with NodeJS; you can stick re-usable templates in vars and absue multi-line strings (template literals) for all your various content and markup. If you get crafty you can embed clientside code in your 'server.js' too or take it to the next level and use C++ multi-line string literals to wrap all your JS ie- client.js, server.js and package.json in a single .cpp file
> I honestly think the single file thing is best reserved for C, given how bad the language support for modularity is.
You don't program much in C, do you?
SQLite 3.51.1
Is there any as large as possible single source (or normal with amalgamation version) more or less meaningful project that could be compiled directly with rustc -o executable src.rs? Just to compare build time / memory consumption.