The main reason you don't see it that often is because of the "what if some extremely common library that we depend on indirectly 63 times at a total of 11 different versions discovers that four of those versions have a major security vulnerability" problem.

For hobby projects, vulnerable dependencies are usually a minor annoyance that's often less annoying than dealing with more elaborate dependency systems.

For big professional projects, not being able to easily answer "are we currently running any libraries with major known vulnerabilities" makes this approach a non-starter.

I actually find them to be extremely popular in C and C++, and also in some Lua communities.

They just have an extremely vocal opposition.

This is not too dissimilar to static builds and unity builds, which also "make your life easier" but people will write tirades about how dangerous they are.

I wonder if C++ modules (which I'm loving) will also get the same treatment, since they make a lot of clunky tooling obsolete.

I suspect much of this is a historical result of c's compilation model. Since c compilers define a compilation unit as a file, there is no good way to do incremental compilation in c without splitting the project into multiple files. In an era of much slower computers, the incremental compilation was necessary so this was an understandable choice.

For me, today this split is almost always a mistake. Having everything in one file is superior the vast majority of the time. Search is easy and it is completely clear where everything is in the project. Most projects written by a single individual will be fewer than 10K lines which many compilers can clean compile in less than one second. And I have reached the stage of my programming journey where I would rather not ever work on sprawling hundred K + line projects written by dozens or hundreds of authors.

If the single file gets too unwieldy, splitting it in my opinion usually makes the problem worse. It is like cleaning up by sweeping everything under the rug. The fact that the file got so unwieldy was a symptom that the design got confused and the single file no longer is coherent. Splitting it rarely makes it more coherent.

To make things more concrete and simple. For me the following structure is strictly better (in lua like the op)

     foo.lua:
       local bar = function() print "bar" end
       return function()
         print "foo"
         bar()
       end
 

compared to

    bar.lua:
      return function() print "bar" end
    foo.lua:
      local bar = require "bar"
      return function()
        print "foo"
        bar()
      end

In the latter, I now both have to keep track of what and where bar is and switch files to see its contents or rely on fancy editors tricks. With the former, I can use vim and if I want to remind myself of the definition bar, it is as easy as `?bar =`. I end up with the same code either way, but it is much easier to view in a single file and I can take advantage of lua's scoping rules to keep module details local to the module even from other modules defined in the same file.

For me, this makes it much easier to focus and I am liberated from the problem of where submodules are located in the project. I can also recursively keep subdividing the problem into smaller and smaller subproblems that do not escape their context so that even though the file might grow large, the actual functions tend to be reasonably small.

That this is also the easiest way to distribute code is a nice bonus.

It takes a tiny bit of lateral thinking in C.

What if "build" hacked all the source into a single text file, instead of hacking it all into a single archive of object files?

Roughly, write static in front of most functions, don't reuse names between source files, cat them together in some viable order.

Now you can do whatever crazy codegen nonsense you want in the build and the users won't have to deal with it. The sqlite amalgamation build is surprising, using the result is trivial.

Thanks.

I thought it was the feature engineering company, Fennel, that was acquired by Databricks this year.