C++ development will be my end.

The absolutely unreadable errors, the overly convoluted macros set up in the project, the cmake build system.... The absolutely unnecessary separation into cpp and header files...

help

I agree!

(*Rust agrees as well*)

In rustc, a bad or vague error is seen as a compiler bug and that's an awesome stance to have!

Agreed, which is why i looked into other things such as Nim and Rust.

currently liking Nim a lot more than Rust.

> The absolutely unreadable errors

Upgrade your compiler. New compilers don't unpack all of the crazy template types like they used to.

> the overly convoluted macros set up in the project

Using macros in C++ is a no-no.

> the cmake build system

Agreed, though it's the best one that exists that can cover all cases people possibly need.

> The absolutely unnecessary separation into cpp and header files

C++20 modules, yo.

Writing cpp is the best encouragement to get out of cpp.

@Geoxion rust seems to make a lot of things right but I'm not completely sold

The syntax has an equally confusing feel to it as C++ does and ... it has macros

Hell even the println is a macro

@LotsOfCaffeine there sure is a lot of syntax, but it's mostly pretty consistent. But yeah, Rust is also doing a lot more stuff than C, so the complexity can be 'bought back' by using it to make very clean abstractions.

Also, the macros are not the same. They have the same name because it's the same concept. But in C, there are pretty much no rules. Everything is like it's been copy-pasted. In Rust however, there are actual rules.

For example in C:
max(x+1, 10)

This could go very wrong if the macro doesn't put parentheses around the parameters when it uses it.

In Rust, the two parameters would be treated like expressions so the x+1 is always resolved as if the input was { x+1 }

@Geoxion I'm opposed to macros in principle, like completely

@LotsOfCaffeine well, they're a trade-off. All formatting is done in macros in Rust because the language itself doesn't support features to do it properly.

So to add the normal printf, then Rust must first get support for functions with a variable amount of parameters. That will take more syntax and make the language and any implementation more complex.

There are also multiple kinds of macros.

The macros in Rust and the libraries can be really powerful. Without it, a library like Serde couldn't exist. https://play.rust-lang.org//...

Take a look, you just slap on the Serialize and Deserialize tags on it and the traits are implemented for it. You can now serialize your struct to e.g. json in one line.

I've tried in the past to deserialize some xml in c++ and that was a nightmare. It can be just one line in Rust.

@Geoxion okay fair the serialization stuff is fairly well made

Comparing to let's say Java or C# would be a little unfair, since they have a runtime environment which plays a big role in (de-)serialization

@AleCx04 Nim won't give you the same absolute performance like Rust does

So in a sense Nim isn't a replacement for C but a higher level language with all the overhead that entails

Let me put it this way: All the things that make Rust annoying are excatly the features that make it what it is in the first place. You cannot have a Rust without the borrow checker. If you try, you won't get Rust

That said, you maybe don't need the full performance of C, in which case Nim is perfectly fine

@12bitfloat nim (besides it's indentation based syntax, ugh) pretty much radiates "simple but powerful" which I think is nice

Sure if you really want the most performance you'll go with C or Rust

@12bitfloat I know how Nim and Rust works, thanks tho, and it really does depend on what one is doing to say that Rust just completely outperforms every aspect of Nim

You forgot the casual segfaults, though arguably they are there in other languages.

I like to think of C++ as the most expensive swiss knife that holds with duct tape. Each new version of C++ adds more useful tools but more duct tape as well.

@PepeTheFrog if C was a lumberaxe, C++ would be a DIY chainsaw duct taped onto said lumberaxe with the safety mechanism removed

@PepeTheFrog IDK why people focus on segfaults. They are literally the easiest class of error to fix and are no different than random exceptions in other languages, just that you have to use a dump to get the stack information instead of it being nicely printed on the terminal or (god forbid) sent to the client to see.

If you're not using valgrind or something like it sometime during your C/C++ development, you're doing something wrong.

The few times I run into a segfault in a month takes me 30 seconds to pop into valgrind, see where the memory was allocated, then where it was freed, and then where my program tried to access it again. Paints me a clear picture as to my logic error.

@junon it's just an unhelpful error, instead of having a builtin base exception for null pointers or kernel panic.

It's obviously not the worse aspect of C++ though.

@PepeTheFrog segfaults are not exceptions. There's nothing to "throw". It's the kernel telling you you accessed invalid memory. It could happen with any language.

You should research more about defaults before you associate them with C/C++.

@junon of course there is not much you can do if a program points to unassigned memory. It just lets the programmer do the memory management mistakes if he does not know better. Cryptic messages are still annoying.

Some low level languages found a way to make it better, like Rust for example who just points it out at compile time and I believe kernel panic too. I believe C++ designers should take that into consideration. Unfortunately Rust is still a fairly new languages so the libs and platform support is still minimal.

Just as much as you I did use Valgrind, GDB and even looked at the disassembly to troubleshoot C/C++ code. It still does not mean that always using 3rd-party tools to troubleshoot is the most efficient way to do it and we should ask ourselves those questions as engineers.

I still use C++ a lot btw but I can see its weaknesses when looking at competition. Especially when you are stuck with shitty embedded systems that are unfortunately stuck with old C++ revisions.

@junon @PepeTheFrog you guys got me remembering something, but it's too long to write down here, so I made a twitter thread instead: https://twitter.com/Geoxion/status/...

It's not directly related to anything here though

@Geoxion A great thread that arrives at a sound conclusion. :)