4 ms·
But you're arguing in circles. If attention is paid, if the architecture is good, all else like programmer salary/skill being equal, any of those languages (an
by morelisp 3y ago
But you're arguing in circles.
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.
- tjoff 3y agoAgree. 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.
- morelisp 3y agoThis 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.
- tjoff 3y ago> If your "good" architecture is slowing down development i.e. more time more labor [...] The argument is that it isn't slowing down development in the long run. Because it is a fundamental part of your architecture anyway. (And my argument has nothing to do with Rust per se)
- marcosdumay 3y ago> any of those languages (and plenty of others) will work fine Well, C won't. Any large C code needs a decade or two of bug-fixing before it is safe, and that only happens if the developers are competent and wiling to fix it.
- morelisp 3y agoWhat do you think this comment added to the discussion?
- pdimitar 3y agoI 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".
- morelisp 3y agoDoes "a fully negative outcome" sound like "all languages are good"?
- pdimitar 3y agoAlright, 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.
- marcosdumay 3y agoWell, 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.