I sympathize with this point, and I tried to be quite clear that I'm not suggesting we drop everything cavalierly today, but rather we decide that our aspiration is to deprecate C/C++ and we move our dependencies gradually from C-based to something else. Some dependencies will be more pernicious to move because they require a lot of specialty knowledge (e.g., Harfbuzz) or simply due to their size (e.g., Chromium) but many others could be moved more readily. It will be a long, hard road which is why we should start now.

> Let's see how those "memory safe" languages would fare 20 years down the line...but I predict there would be a cool_lang and people would advocate for rewriting every algorithm known to man, yet again

This just reads like you've taken personal offense. My argument is quite clearly not "C isn't cool enough" or "C isn't memory safe", it's "C lacks a standard, sane build system such that packaging C projects is a nightmare".

I'm not experienced enough to take a side in language wars...It's just my personal opinion, as a non-CS, that deprecating working solutions because of non-theoretical problems (like difficulty of packaging) is not a sane engineering approach.

I mean, yeah, right now, Rust/Go have much better tooling than C/C++ for packaging and dependency resolution it's not even a debate but still one may argue that C/C++ library management is decentralized :) and maybe in future people converge to some unique method of dependency resolution that would deprecate Rust/Go way of doing things (like Nix/GuiX).

I came to this view because I see lots of cool projects in very specialized fields, that are practically abandoned and no one continues working on it on the sole reason of community thinking its not worth continue maintaining it in old lang/tech.

Again, consider I'm mainly a embedded guy...so idk, maybe a fresh re-write of every classical cs problem every 10 years is better in practice...

Fear not, I too come from an embedded background. I appreciate the "you can pry C from my cold dead hands" culture in embedded. I understand that many of the arguments against C feel like "C isn't sexy enough". I understand that many have promised that Java, C#, C++98, etc are a better fit for embedded systems than C and failed to deliver.

I'm not saying that we should deprecate C because it's old or unsexy. I'm saying there are practical problems with the C ecosystem that are unlikely to work themselves out which makes packaging downstream software really, really hard. This is a bad fit for domains (like SaaS) where the pace of software development is quite rapid.

> so idk, maybe a fresh re-write of every classical cs problem every 10 years is better in practice

In this case we wouldn't even need to rewrite things if the maintainers of these software projects would opt into a sane package manager (there exist sane package managers for C, for example, Conan) but most maintainers of C projects are militantly opposed.

Not ignoring, but minimizing the surface, for example:

Should the default "webserver" really be written in c? Or maybe just the one for embedded or high performance?

Yeah, best language for the task...but the parent was talking about not using a dependency just because it is written in C or C++

No, he was talking about "minimizing" c/c++ dependencies.