News for hackers. Stuff that matters.
Re:Will Carbon Replace C++? by vlovich123 on Monday February 27, 2023 @08:01PM (#34964364)
There's a talk by Scott Meyers (at the D lang conference IIRC), where he methodologically takes apart the claim that priority #1 is performance or 0-cost abstractions. Basically the way the standards body seems to work is there's ~N different concerns and people will whatever set is appropriate to kill proposals. It gives a fantastic illusion of performance being #1, but C++ makes plenty of choices that are misaligned with performance (e.g. variable aliasing that it inherited from C but it let infect the C++ type system too).
Re:Will Carbon Replace C++? by hot_gril on Monday February 27, 2023 @08:42PM (#34964631)
There are tradeoffs. If performance were always #1 with the underlying requirement of portability, you'd be using C. And performance is more of a concern in C++ than in Java.

I'm no expert in this, I'm just a guy who's sick of writing web backends in C++ for no reason.

Re:Will Carbon Replace C++? by pjmlp on Tuesday February 28, 2023 @12:02PM (#34971716)
Ah the days of ISAPI ATL extensions. :)
Re:Will Carbon Replace C++? by vlovich123 on Tuesday February 28, 2023 @02:22PM (#34973608)
You'd think so, but C doesn't have the performance crown always either due to language design choices. A big one is aliasing (which languages like Rust and Fortran forbid) which inhibits the ability for very impactful and common low-level optimizations that come up all the time. Performance characteristic differences between C vs C++ are not all that interesting because the language models are so similar (& thus similarly the compilers for them basically have the same model). Indeed, higher level of abstractions can help improve performance as virtual classes will outperform manual attempts at doing similar things (due to devirtualization passes within the compiler). That's actually been a friction point for Rust using LLVM because LLVM is built around the C/C++ language model and it's hard to express certain invariants to it that would result in even more efficient code or you try to use optimization passes that turn out to be broken because they're not really used by the broader C/C++ community (https://github.com/rust-lang/rust/issues/54878).