Hacker News Reader

    > involves making a completely new build system AND test framework from scratch because C++ tooling is just that bad

In 2026, CMake is the standard build tool, and Google Test is usually a safe choice. There are many example projects on GitHub to learn how to use them.

I think you misunderstood me. I did use them at first, but it took so much effort for me to set them up and config them for that particular application (Code only Skyrim modding) where I pretty much spent an entire day debugging and diagnosing crashes in CMakeLists.txt with the only info being random forum posts and Youtube videos on the subject without having written a single line of C++ that I decided to build my own instead.

> 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.

Indeed, picking C doesn't make sense when you actually want to write C++ code in C ;)

> Lack of support for type-safe containers (need to be hack toghether via macros)

Are templates really so much better than macros that the latter deserve to be called a "hack"? The following two examples are both type-safe and have roughly the same semantics and #LoC:

Macros:

  // 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 <stdio.h>
  #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);
  }

Templates:

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

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

Well, Carbon would have been better off if they just made "C with `match` and sane error handling" instead of whatever it is they are building there over at Google. But still, I think C and C++ are honestly very different languages at this point and that you can't really call C++ a superset of C at all really.

> Well, Carbon would have been better off if they just made "C with `match` and sane error handling" instead of whatever it is they are building there over at Google.

Perhaps that might be a better language in a different context, but I don't think that language would have have been better for Google given their goals (e.g., bidirectional interop with C++, incremental automated migration, memory safety, etc.)

C++ at least rescues you from defining a million callbacks with a void* context argument that you then cast into whatever you know it actually is

> In 2026, there really needs to be a REALLY good reason for people to use C++ for greenfield projects over using something like Rust, Go or C#.

I don't think that professional developers go around mindlessly starting projects without evaluating their choices. The truth of the matter is that the whole industry has been picking C++ over alternatives for ages, to the point where C++ managed to get one of the most popular languages devised. Why do you think that happened?

> I mean, I've made it work, but that pretty much involves making a completely new build system AND test framework from scratch (...)

That says more about your competence than anything. I mean, CMake works so well that companies such as Jetbrains developed their C++ IDEs around it. But somehow you seem to struggle where everyone just dash towards coding. Why is that?

> There is a good language buried underneath C++ somewhere, it's just that nobody has taken the time to extract it.

Carbon?

Has anyone major used that for any production project though?

Carbon isn't even a real language, no real language will spent 4 entire years and is still stuck in version 0.0.0-0. It feels more like bad Rust than a proper C++ successor at all.

Just to give you a small example? why would a C++ successor language use `fn main()` instead of using C/C++ style `int main()`? And their generics system is even more confusing, are they going to support a new form of generics or are they sticking with templates? And if they are going to add templates, why would they not add pretty much one of the best additions to modern C++ to Carbon, concepts?

> why would a C++ successor language use `fn main()` instead of using C/C++ style `int main()`

Apparently easier and faster parsing. Most modern language have arrived at the `fn bla(arg: ArgType): ResultType` form and I don't think they made that decision for purely aesthetical reasons.

Even C++ has. https://www.geeksforgeeks.org/cpp/trailing-return-type-in-cp...

> Most modern language have arrived at the `fn bla(arg: ArgType): ResultType` form and I don't think they made that decision for purely aesthetical reasons.

Not just modern, it's older than you think. Pascal function definition is `function bla(arg: ArgType): ResultType;`

> no real language will spent 4 entire years and is still stuck in version 0.0.0-0.

Strongly disagree. I too thought that it would be easy to implement a new language in 1-2 years. I started the current Quxlang codebase (under a different name) on Dec 27, 2022. In 2026, hundreds of commits and hundreds of thousands of lines of code later, I still don't have a feature complete language.

I also rewrote the syntax, mainly because C++ parsing is a nightmare... Although my choice was very different...

No, it's C :) And for me that's not even a hot take anymore, I switched back to C (specifically C99 and later) around 2017 after nearly 20 years of C++ as my main language, and I don't miss C++ the slightest. The hardest part was unlearning some bad C++ habits. The other 'behaviour change' for me was to open my mind to more programming languages. E.g. instead of trying to solve every problem with C++ I now pick a language that better matches the problem I want to solve (e.g. on one end of my language toolbox is C, on the other extreme end is Typescript, and somewhere in the middle are Zig, on Mac of course the occasional ObjC (not a fan of Swift tbh), and yes, sometimes even still modern C++ - in the end, the choice of language is mostly driven by the dependencies you need to use).

> No, it's C :) And for me that's not even a hot take anymore,

For me, I switched away from C++ in 2008 or thereabouts. For anything that needs a higher level of abstraction than C, I'll use Lisp, Python, Java, C#[1], etc.

You might enjoy (shameless plug to my own blog):

https://www.lelanthran.com/chap9/content.html

https://www.lelanthran.com/chap13/content.html

=============================

[1] Although, C# has lately gone the way of becoming incomprehensible syntax-wise. I've seen this happen with C++ in the past, so not so sure I'll even use C# again.