|
|
|
|
|
|
by snickerer
1877 days ago
|
|
|
You say that C / C++ is bad. You assume that there are alternatives that are just better. I think you are wrong. Why? The short answer is: there is no free lunch. There is no silver bullet. C / C++ has huge pitfalls with its memory management. But it is also a well-designed programming language with a great balance between efficiency and comprehensibility (and all other features of a language). Every design decision in a language is a trade-off. And the trade-offs in C / C++ are so well chosen that there was no easy improvement for decades. No low hanging fruit. A C programmer has to understand much more about memory management because there is no virtual machine / garbage collector / interpreter running which takes care of it. But for that you get efficiency that is not possible by design with the other approaches. For me C / C++ made the best trade-off. Until Rust came along. Rust wants to make the memory management 10% better than C++ with 0% loss in efficiency. That is huge. No one reached something similar in 40 years. I am sceptical because this is such an ambitious undertaking. If that really works in real life I will be impressed. |
|
|
Citation needed. I don't believe it's anywhere close to the Pareto frontier of language design, nor do I think we should reasonably expect it to be - it's fundamentally a language put together by two kids with no formal training, designed for programming a machine that had 256 kilobytes of RAM. It became popular due to some accidents of history (Unix, availability of free compilers) and the following network effects far more than the technical merits of the design.
> Every design decision in a language is a trade-off. And the trade-offs in C / C++ are so well chosen that there was no easy improvement for decades. No low hanging fruit. A C programmer has to understand much more about memory management because there is no virtual machine / garbage collector / interpreter running which takes care of it. But for that you get efficiency that is not possible by design with the other approaches.
That's nonsense IMO. ML was and remains an overwhelmingly better language, the performance of an incorrect program should be considered meaningless, and for all that C is supposedly more efficient, when I've actually seen a C program rewritten in an ML-family language the result has been substantially better performance.