[moth-fuzz]

C++ has a myriad of wonderful language features that exist entirely within C++ and cross no language boundaries. I really adore C++ as a language but unfortunately I find little pragmatic use for it unless I'm working 100% inside C++ and using native APIs only. If you're doing that, it's a dream. Rust, on the other hand, speaks the same ABI as C, and with serde, can read and write to most formats and/or APIs with utmost ease.

C++ I find can get a little unwieldy quite fast, but is generally easier to keep simple. It maps to higher-level concepts in easy and intuitive ways. Rust, I hate to say it, but unless you know best practices / idiomatic Rust from the start, you'll have to do a lot of refactoring as you learn the language. Some constructs simply aren't possible using safe Rust. Many embrace the limitations, many else frustrate themselves again and again until 'the Rust way' drills into their heads. But, of course, once you get a feel for it, it's pleasant to write in.

How much difficulty you'll have with Rust or C++ depends on what problems you try to solve, and what your approach to programming is generally. If you're more of a pragmatic "I write simple programs that actually do things" I don't think you'll have any problems with Rust. It's very straightforward. And the tooling is second-to-none. If you like to partake in exploratory programming, trying out different theoretical models and different abstractions, C++ caters to that by allowing you to write more elegant designs than in Rust, with the downside that it also lets you make worse mistakes.

The wider cross-language library ecosystem is mostly C-based I've found, so, in C++ you can just use those libraries directly with no hassle (the only hassle being the build system, or lack thereof). Rust can use those libraries as well (as long as you don't have a gut-reaction "ew" to using `unsafe` everywhere) but unfortunately the safe and idiomatic Rust library ecosystem is kind of on the bleeding edge at the moment. Hopefully things will stable out soon, and all these hip new technologies will come to fruition, but that day is not today.

I know this isn't really nudging in one way or another but really it comes down to what you value in a language and what projects you want to see through using these technologies that will determine which one you like better. Have fun!

[twic]

> C++ has a myriad of wonderful language features that exist entirely within C++ and cross no language boundaries. I really adore C++ as a language but unfortunately I find little pragmatic use for it unless I'm working 100% inside C++ and using native APIs only. If you're doing that, it's a dream. Rust, on the other hand, speaks the same ABI as C, and with serde, can read and write to most formats and/or APIs with utmost ease.

This seems like a weird statement. Yes, C++ has a load of features you can't express in a C API. But so does Rust! Yes, Rust can produce and consume libraries with a C API. But so can C++! They're in pretty much identical positions here, aren't they?

It's true that serde is great, and C++ doesn't have an equivalent (AFAIK). But C++ does typically have excellent piecemeal support for popular serialisation formats.

[moth-fuzz]

I find it difficult to articulate, so forgive me if I'm not getting my point across, but the gist of what I'm trying to say in that section is less about straight binary compatibility and more about API design in general, playing to the respective language's strengths. I feel like Rust encourages more "C-like" APIs, and its added features (such as memory safety) are in effect the whole running time of the program, regardless of where that memory comes from or how it's initialized. On the other hand, C++ has something of a vendor lock-in regarding how it functions - RAII, constructors, exceptions, inheritance, etc. etc. all assume you have objects with a lifecycle that starts and ends in C++, and that those objects see most of their use according to C++'s object model. All of C++'s features come together in a brilliantly harmonized way and build off each other, but, if you forgo even some of those features, you end up missing out on most of them.

[jcelerier]

It's possible to have some parts of what serde does if you restrict yourself to aggregates (no private members, no explicit constructors), e.g. your types are simple structs such as

     struct foo { int x; std::string label; };

Here it's possible to serialize/deserialize this structure in a generic way without having to annotate it - currently it's a bit complicated to implement so libraries help doing it (e.g.https://github.com/apolukhin/pfr_non_boost) but in 23 the missing language feature that makes the code trivial to write without any library should be there.