3 ms·

That's what inevitably happens when you make transitive dependencies easy and you have a culture of "if there's a library for it you must use it!" C/C++ are th

That's what inevitably happens when you make transitive dependencies easy and you have a culture of "if there's a library for it you must use it!" C/C++ are the only widely used languages without a popular npm-style package manager, and as a result most libraries are self-contained or have minimal, and often optional dependencies. efsw [1] is a 7000 lines (wc -l on the src directory) C++ FS watcher without dependencies. The single-header libraries that are popular in the game programming space (stb_* [2], cgltf [3], etc) as well as of course Dear ImGui [4] have been some of the most pleasant ones I've ever worked with. At this point I'm convinced that new package managers forbidding transitive dependencies would be an overall net gain. The biggest issue are large libraries that other ones justifiably depend on - OpenSSL, zlib, HTTP servers/clients, maybe even async runtimes. It's by no means an unsolvable problem, e.g. instead of having zlib as a transitive dependency, it could: 1. a library can still hard-depend on zlib, and just force the user to install it manually. 2. a library can provide generic compress/decompress callbacks, that the user can implement with whatever. 3. the compress/decompress functionality can be make standard [1] https://github.com/SpartanJ/efsw https://github.com/SpartanJ/efsw [2] https://github.com/nothings/stb https://github.com/nothings/stb [3] https://github.com/jkuhlmann/cgltf https://github.com/jkuhlmann/cgltf [4] https://github.com/ocornut/imgui https://github.com/ocornut/imgui

lifthrasiir 2y ago
> The single-header libraries that are popular in the game programming space (stb_* [2], cgltf [3], etc) as well as of course Dear ImGui have been some of the most pleasant ones I've ever worked with. The mainstream game programming doesn't use C at all. (Source: I had been a gamedev for almost a decade, and I mostly dealt with C# and sometimes C++ for low-level stuffs.) Even C++ is now out of fashion for at least a decade, anyone claiming that C++ is necessary for game programming is likely either an engine developer---a required, but very small portion of all gamedevs---or whoever haven't done significant game programming recently. Also, the reason that single-header libraries are rather popular in C is that otherwise they will be so, SO painful to use by the modern standard. As a result, those libraries have to be much more carefully designed than normal libraries either in C or other languages and contribute to their seemingly higher qualities. (Source: Again, I have written sizable single-header libraries in C and am aware of many issues from doing so.) I don't think this approach is scalable in general.
- raverbashing 2y ago
  > The mainstream game programming doesn't use C at all. (Source: I had been a gamedev for almost a decade Game programming changed a lot, parent is talking about stuff older than 10 yrs There was a lot of PC gaming in C/C++, and "Engine" were developed together with games for the most part. Think all the Doom and Quake saga That's what he's talking about
  - lifthrasiir 2y ago
    Most libraries mentioned in the GP are less than 10 years old, except for perhaps stb libraries (dates back to early 2000s). Single-header libraries are definitely a recent phenomenon, possibly inspired by stb libraries after all.
mike_hearn 2y ago
> as a result most libraries are self-contained or have minimal, and often optional dependencies If you ignore the OS, then sure. Most C/C++ codebases aren't really portable however. They're tied to UNIX, Windows or macOS, and often some specific version range of those, because they use so many APIs from the base OS. Include those and you're up to millions of lines too.
the_gipsy 2y ago
> a library can provide generic compress/decompress callbacks, that the user can implement with whatever. This only works for extremely simple cases. Beyond toy example, you have to glue together two whole blown APIs with a bunch of stuff not aligning at all.
xpe 2y ago
> That's what inevitably happens when you make transitive dependencies easy and you have a culture of "if there's a library for it you must use it!" 1. This doesn't mean that C++'s fragmented hellscape of package management is a good thing. 2. "inevitably"? No. This confuses the causation. 3. This comment conflates culture with tooling. Sure, they are related, but not perfectly so.
Measter 2y ago
Having a quick look at efsw, it depends on both libc and the windows API, both are huge dependencies. The Rust bindings for libc come to about 122 thousand lines, while the winapi crate is about 180 thousand lines. [Edit] And for completeness, Microsoft's Windows crate is 630 thousand lines, though that goes way beyond simple bindings, and actually provides wrappers to make its use more idiomatic.
xpe 2y ago
> At this point I'm convinced that new package managers forbidding transitive dependencies would be an overall net gain. Composition is an essential part of software development, and it crosses package boundaries. How would banishing inter-package composition be a net gain?

lifthrasiir 2y ago

> The single-header libraries that are popular in the game programming space (stb_* [2], cgltf [3], etc) as well as of course Dear ImGui have been some of the most pleasant ones I've ever worked with. The mainstream game programming doesn't use C at all. (Source: I had been a gamedev for almost a decade, and I mostly dealt with C# and sometimes C++ for low-level stuffs.) Even C++ is now out of fashion for at least a decade, anyone claiming that C++ is necessary for game programming is likely either an engine developer---a required, but very small portion of all gamedevs---or whoever haven't done significant game programming recently. Also, the reason that single-header libraries are rather popular in C is that otherwise they will be so, SO painful to use by the modern standard. As a result, those libraries have to be much more carefully designed than normal libraries either in C or other languages and contribute to their seemingly higher qualities. (Source: Again, I have written sizable single-header libraries in C and am aware of many issues from doing so.) I don't think this approach is scalable in general.

raverbashing 2y ago
> The mainstream game programming doesn't use C at all. (Source: I had been a gamedev for almost a decade Game programming changed a lot, parent is talking about stuff older than 10 yrs There was a lot of PC gaming in C/C++, and "Engine" were developed together with games for the most part. Think all the Doom and Quake saga That's what he's talking about
- lifthrasiir 2y ago
  Most libraries mentioned in the GP are less than 10 years old, except for perhaps stb libraries (dates back to early 2000s). Single-header libraries are definitely a recent phenomenon, possibly inspired by stb libraries after all.

mike_hearn 2y ago

> as a result most libraries are self-contained or have minimal, and often optional dependencies If you ignore the OS, then sure. Most C/C++ codebases aren't really portable however. They're tied to UNIX, Windows or macOS, and often some specific version range of those, because they use so many APIs from the base OS. Include those and you're up to millions of lines too.

the_gipsy 2y ago

> a library can provide generic compress/decompress callbacks, that the user can implement with whatever. This only works for extremely simple cases. Beyond toy example, you have to glue together two whole blown APIs with a bunch of stuff not aligning at all.

xpe 2y ago

> That's what inevitably happens when you make transitive dependencies easy and you have a culture of "if there's a library for it you must use it!" 1. This doesn't mean that C++'s fragmented hellscape of package management is a good thing. 2. "inevitably"? No. This confuses the causation. 3. This comment conflates culture with tooling. Sure, they are related, but not perfectly so.

Measter 2y ago

Having a quick look at efsw, it depends on both libc and the windows API, both are huge dependencies. The Rust bindings for libc come to about 122 thousand lines, while the winapi crate is about 180 thousand lines. [Edit] And for completeness, Microsoft's Windows crate is 630 thousand lines, though that goes way beyond simple bindings, and actually provides wrappers to make its use more idiomatic.

xpe 2y ago

> At this point I'm convinced that new package managers forbidding transitive dependencies would be an overall net gain. Composition is an essential part of software development, and it crosses package boundaries. How would banishing inter-package composition be a net gain?