If attention is paid, if the architecture is good, all else like programmer salary/skill being equal, any of those languages (and plenty of others) will work fine. (And honestly, not a huge difference in the work to achieve that, a good design will look about the same in all four.)
It's only an interesting question which to use if attention is not paid, or you don't want to invest enough to ensure attention will be paid; in which case you need to look at the causes and effects of that.
I am not your parent commenter but to me they added the nuance of "not all programming languages are good and we should stop pretending otherwise". And "we don't actually have as much choice as we think".
Well, thanks. I was going for that first part (with the added detail that C is one of the languages being discussed on the context).
But I don't really agree with that second statement. People seem to not be aware of how much choice we have, and focus only on a few possibilities that are not even all of them good.
I suppose such a discussion could spiral into semantics so I'll only say this:
Yes, in theory we have a lot of choice but in practice you start a project and you need a good ORM / data-mapper, you need a good HTTP/Web/WebSockets framework, you need good DB migration solution, you need SSO for 5 services, and you need 20+ more things and when you start eliminating stuff there are barely any programming languages left. If even 20 are left at the end of such an evaluation that would be still pretty good (but in my practice you usually end up with maximum 7-8 viable choices).
You don't have to agree with me on this, or I with you -- it's my empirical observation which is prone to bias and filter bubbles (of course).
Alright, you confused me. I was simply saying that this (your words):
> any of those languages (and plenty of others) will work fine.
...is not necessarily true. I've tried a good amount of languages in my life and their killer apps lose steam very fast when you try doing commercial code with them. For the rest of discussion, well, I didn't understand its point, so not participating there.
Agree. But the argument put forward in favor of automatic memory management is that it speeds up development.
But if that is only true if you don't care about the architecture that argument doesn't hold (assuming you want a good architecture).
The claim I make is that you have to think about memory, either directly or indirectly. And if you have to think about it dealing with it yourself isn't a burden, it is liberating.
In in a similar sense to how a static type system is liberating. Which might sound a bit weird, until you need to refactor.
This is still a mostly circular argument though. An architecture is "good" if it's saving resources - compute, time, or labor. If your "good" architecture is slowing down development i.e. more time more labor, you'd better be able to point to significant compute gains or it's not actually good. Rust is, only sometimes, and marginally, better than other languages in this regard.
And your compute gains need to be something you can't just trade off against money for development time, i.e. it either needs to be a fundamental part of your problem, or you need to be planning for hyperscale. This is also only a small fraction of problems.
If attention is paid, if the architecture is good, all else like programmer salary/skill being equal, any of those languages (and plenty of others) will work fine. (And honestly, not a huge difference in the work to achieve that, a good design will look about the same in all four.)
It's only an interesting question which to use if attention is not paid, or you don't want to invest enough to ensure attention will be paid; in which case you need to look at the causes and effects of that.