4 ms·

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-theor

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...

throwaway894345 5y ago
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.

throwaway894345 5y ago

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.