Memory management is trivial if your problem is trivial. In the real world you have network connections that fail, third party libraries with other conventions than yours, multiple threads with their own lifetimes, memory mapped files, etc.

Third party code is a risk and should always be carefully managed and properly isolated.

This applies regardless of programming language.

Of course the web people and their "frameworks" is just another demonstration of how bad relying on third party code is.

Not true, taking on C or C++ dependencies has different potential consequences than taking on Java or Python dependencies

Which are?

Non-local bugs due to memory safety. If I have a function

    def f(x)
      return ...

in Python or Java, those functions will work regardless of what other modules I import. (modulo monkey patching in Python, though you can defend against that)

In C you don't have these guarantees -- foreign code can stomp on your code.

This is probably why C does not have an NPM-like culture of importing thousands of transitive dependencies -- because that style would just fall down.

Also a minor issue, but C doesn't have namespaces (for vars or macros), so it's a bit harder to compose foreign code.

Also compiler flags don't necessarily compose. Different pieces of C code make different portability assumptions, and different tradeoffs for speed.

So your argument is that C does not have strong module encapsulation, then you argue that Python does.

That is just plain false, since a Python module can trivially be tainted by what you import before, and the Python environment is widely known for its dependency hell.

Meanwhile C modules, once compiled, can be fully isolated from what you link against them, depending on build and link settings.

Non-local bugs is just a matter of sharing state across a module boundary. Memory errors is just a very small subset of the possible bugs you can have in a program, and preventing them doesn't magically solve all the other more important bugs.

Not disagreeing with your first paragraph and will add, that memory management mistakes happen to the best. But it is also probably true, that Google and others do this, because they know there will always be someone committing shit, no matter, whether they are at Google or another big company. So they want guarantees, not blind trust.

> _if_ you are in a small clean opinionated private codebase

This is actually an important point. I think all codebases can (and should) be split into small, opinionated, privately owned sub-codebases. This is why developing large scale projects can work even in languages like C. After all this is what that whole 'modularity' thing is about ;)

(it also implies that external dependencies need to be managed the same way you handle internal dependencies, as soon as you use an external dependency you also need to be ready to take ownership of that dependency)

Memory management is fundamentally a cross-cutting concern, so modules don’t help, unless you introduce some hard barrier (like copying everything at boundaries).

Modules work if they can operate without allocating or are generic over allocators. I don't really get why people think it's normal for e.g. a websocket decoder to insist on calling read, write, epoll, and mmap, if the user just wants to encode and decode messages.

There is no maximum size for a websocket message, so unless you want to force a size ahead of time, you might need to allocate to resize your buffer.

Or you could give the message in fragments to the user, but that immediately becomes a very inconvenient API.

Generational-indices also help to secure system boundaries. The memory is always owned and manipulated by a system, and the system only hands out generational-index-handles as "object references".

Arguably that's even a good idea in memory safe languages, it avoids tricky borrow checker issues, and also prevents the outside world to directly manipulate objects. Everything happens under control of the system.