The Linux kernel is tens of millions of lines, so I'm rather doubtful at the existence of this OS over a billion lines.

> I'm rather doubtful at the existence of this OS over a billion lines

Someone somewhere is trying to vibe code the entirety of the Linux kernel using Copilot.

That's just the kernel. An OS is more than the kernel

I don't see anything that makes this impossible. In fact I think this is just a result of nobody making a project of that scale in those languages yet, rather than it being fundamentally impossible.

It doesn't matter if you or I see what makes it impossible.

It's a fact that:

- Super large software tends to be C or C++

- One of the unique features of C and C++ is the way software is organized (headers and separate compilation).

- Attempts to bring other languages' approach to modules to C++ have been a complete disaster.

Hence it's an empirical fact that C and C++ have a superior approach to software scaling, and that approach is headers and separate comp. And a preprocessor with macros.

> Hence it's an empirical fact that C and C++ have a superior approach to software scaling

I'm not convinced the "superior" follows. What I'm missing is a causal link between your first and second points - super large software could have been written in C or C++ for reasons other than the header/implementation split (especially if the super large software wasn't so super large at first and grew into its size instead of being planned for that size from the start), and somewhat conversely programming languages with header/implementation splits don't necessarily have corresponding super large software (e.g., OCaml, at least publicly?).

> The problem with C++ modules is that they are empirically inferior to headers and separate compilation units.

I didn't think modules and separate compilation units are (completely) mutually exclusive? It's not like modules force you to use a single compilation unit for all your code; it just changes where the compilation unit boundaries/dependencies are (though to be fair I'm not entirely certain how much heavy lifting that "just" is doing)

> Want to build a >billion line of code OS? You can do that with headers and separate compilation units. Good luck doing that with any other tech

It's not immediately obvious to me why this must be the case. That's the fundamental limitation of modules systems that supposedly prevents this scaling?

> That's the fundamental limitation of modules systems that supposedly prevents this scaling?

Not the person you're replying to but I can see a problem with some dependency chains.

Let's say you have: stdlib <- A.hpp <- B.hpp (small header) <- C.hpp (likewise) <- many .cpp files.

If you only precompile A.hpp (as is commonly done), the many .cpp files can be compiled in parallel once A.hpp is precompiled, and you get a nice speedup.

If on the other hand you need to precompile everything, then all these cpp files must wait on A, then B, then C to be precompiled

I'm not entirely sure modules systems must face that limitation. C++'s module system, for example, permits separation of module interfaces and module implementations, much like the existing header/implementation system. IIRC OCaml's module system does something similar, though I'm not familiar enough with it to say whether it qualifies as a module system beyond the name.

Speaking more abstractly even if there isn't an explicit interface/implementation separation perhaps compilers could pick out and make available interface information "ahead of time" to alleviate/possibly eliminate the effect of otherwise problematic dependency chains? For example, in Rust you "just" need to look for signatures to figure out the interface and you have the corresponding keywords to make searching for those easy without having to fully parse the entire file.

There's also the question of whether super large projects must have problematic dependency chains - hypothetically, if a super large project were written in a language with a module system some work would be done to try to structure it to minimize build time/system pain points. I don't think I can confidently say that that is always (im)possible.

> Speaking more abstractly even if there isn't an explicit interface/implementation separation perhaps compilers could pick out and make available interface information "ahead of time" to alleviate/possibly eliminate the effect of otherwise problematic dependency chains?

I'm not sure how well this would work for non-instantiated templates

> There's also the question of whether super large projects must have problematic dependency chains

Any header precompilation dependency chain is a dependency chain and may end up worse than fully parallel TU compilation if the time to parse said headers is faster than the time to compile them in a serial way.

I can see modules being used, but relegated to, "import std; import fmt; import vulkan (etc)", typically use cases one should already use PCH for.

> I'm not sure how well this would work for non-instantiated templates

I don't know either, but I was thinking about module systems in general rather than C++'s module system specifically, since the original comment I was responding to seemed to be speaking in generalities as well for that particular topic.

> Any header precompilation dependency chain is a dependency chain and may end up worse than fully parallel TU compilation if the time to parse said headers is faster than the time to compile them in a serial way.

Right, but it comes down to whether it's literally impossible to structure super large projects in a practical manner. Sure, maybe you eat some slowdown, maybe you get some speedup, but I'm a bit skeptical that modules must result in slowdowns of such a magnitude that super large projects are infeasible.