The Two Factions of C++ (2024)

Post by _hao » Wed, Aug 19, 2026, 2:29 PM UTC

budman1 wrote: post #70

You folks are in an HN bubble. C++ is still king of the mountain and it will remain so for decades. The billions of lines of existing C++ are not being re-written in rust (by humans or AI's). 100 thousands of lines are being re-written. C++ is changing, but C++11 is moving across the land. It will be 20 years before the 'new' C++ stuff gets regularly used. Just because it is old, doesn't mean it doesn't have value. J…

Post by wasmperson » Wed, Aug 19, 2026, 3:40 PM UTC

badpun wrote: post #43

HappMacDonald wrote: post #40

Earlier quoted context omitted.

> There is a good language buried underneath C++ somewhere Well.. "C".. though I wouldn't go so far as to call that a good language, either.

Lack of support for type-safe containers (need to be hack toghether via macros) and overreliance on macros in general (which are not IDE and debugger friendly) are two aspects of C that are off-putting for majority of people in 2026. That's even assuming you're willing to forego pointer/memory safety.

  // pair.h
  struct id(pair) { T a, b; };
  static inline struct id(pair) id(make_pair)(T a, T b){
    return (struct id(pair)){ .a = a, .b = b };
  }
  #undef id
  #undef T

  // main.c
  #include 
  #define T int
  #define id(n) n ## _int
  #include "pair.h"
  int main(void){
    struct pair_int p = make_pair_int(12, 13);
    printf("%d %d\n", p.a, p.b);
  }

  //pair.h
  template
  struct pair { T a, b; };
  template
  pair make_pair(T a, T b){
    return (pair){ .a = a, .b = b };
  }

  //main.cpp
  #include 
  #include "pair.h"
  int main(void){
    pair p = make_pair(12, 13);
    printf("%d %d\n", p.a, p.b);
  }

Post by nitwit005 » Wed, Aug 19, 2026, 9:46 PM UTC

tonyedgecombe wrote: post #29

> “We must minimize the need to change existing code. For adoption in existing code, decades of experience has consistently shown that most customers with large code bases cannot and will not change even 1% of their lines of code in order to satisfy strictness rules, not even for safety reasons unless regulatory requirements compel them to do so.” But the major players do seem to be happy to replace their C++ code wi…

Post by blub » Thu, Aug 20, 2026, 7:53 AM UTC

tonyedgecombe wrote: post #29

> “We must minimize the need to change existing code. For adoption in existing code, decades of experience has consistently shown that most customers with large code bases cannot and will not change even 1% of their lines of code in order to satisfy strictness rules, not even for safety reasons unless regulatory requirements compel them to do so.” But the major players do seem to be happy to replace their C++ code wi…

Post by locknitpicker » Thu, Aug 20, 2026, 10:19 AM UTC

simon_void wrote: post #68

locknitpicker wrote: post #63

Earlier quoted context omitted.

> But the major players do seem to be happy to replace their C++ code with Rust. I would be wary of mindlessly referring to appeals to authority like this. Sometimes their rationale is very context sensitive. For example, Microsoft has been behind quite a heavy push for C#, and it wouldn't be wise to use that as an example of C# being preferable to C++. See for example Bun's recent migration to Rust which could be mi…

> Bun's recent migration to Rust which could be misinterpreted as an example supporting migrating to rust, but under the hood it's far from a success story. Since you don't mention that this migration is basically executed agenticly by Claude, it seems like you attribute this troubled migration to Rust not being that good of an improvement after all. For me it doesn't seem that surprising that Claude autonomously tra…