sentry-native VS CppCoreGuidelines

I understand what C bindings means - hence my comment about the lowest common denominator. I'm not deeply familiar with the Lua api so I don't feel comfortable commenting on it, but the sentry C api is a prime example. Yes you can use this API from many different languages, including C++, but you end up writing code like this. You almost always lose type safety, RAII, and introduce error prone, verbose code, such as: sentry_value_t debug_crumb = sentry_value_new_breadcrumb("http", "debug crumb"); sentry_value_set_by_key( debug_crumb, "category", sentry_value_new_string("example!")); sentry_value_set_by_key( debug_crumb, "depth", sentry_value_new_int32(11)); sentry_value_set_by_key( debug_crumb, "level", sentry_value_new_string("debug")); sentry_add_breadcrumb(debug_crumb);

> Put another way, I'd rather fix relatively simple C (which also tends to be simpler code in general) than the monsters created by "modern C++" because they thought the "added safety" would mean they could go crazy with the complexity without adding bugs.

It's completely possible to write C++ code without it being a mess of a template mostrosity and massively overloaded function names. People who write C++ like that would write C filled with macros, void pointers and all the other footguns that C encourages you to use instead.

I've been working with the sentry-native SDK recently [0] which is a C api. It's full of macros, unclear ownership of pointers (in their callback, _you_ must manually free the random pointer, using the right free method for their type, which isn't type checked), custom functions for working with their types (sentry_free, sentry_free_envelope), opaque data types (everythign is a sentry_value_t created by a custom function - to access the data you have to call the right function not just access the member, and this is a runtime check).

Compare [1] (their C api example)

[0] https://github.com/getsentry/sentry-native

If you aren't aware of the c++ core guidelines[1] - it should be on your radar.

Also, it might not be a popular opinion, but I think Bjarne's books are just fine.

A Tour of C++ (3rd edition) [2]

Principles and Practice Using C++ (3rd Edition) was just published in april 2023 [3]

[1] https://github.com/isocpp/CppCoreGuidelines/blob/master/CppC...

You need to talk to Bjarne and Herb...

"C++ Core Guidelines" - https://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines

In addition to the other comments -

TypeScript deliberately takes a "good enough" approach to improving JavaScript, instead of designing an ideal but incompatible approach. For example, its handling of [function parameter bivariance](https://www.typescriptlang.org/docs/handbook/type-compatibil...) is unsound but works much better with the existing JavaScript ecosystem. By contrast, a more academic functional programming language would guarantee a sound type system but would be a huge shift from JavaScript.

By analogy, Herb Sutter is arguing that something like the [C++ Core Guidelines](https://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines), with tooling help in this new Cpp2 syntax, can bring real improvements to safety. Something like Rust's borrow checker would bring much stricter guarantees, backed by academic research and careful design, but would be incompatible and a huge adjustment.

https://www.youtube.com/watch?v=2olsGf6JIkU

Take a look at Effective Modern c++ by Scott Meyers and the ISO c++ core guidelines. These resources are great for learning how to write better, more modern C++. I don't think it would be hard to grasp if you're already familiar with the language, just make sure to actually write some code which makes use of this stuff, otherwise it's easy to forget.

Look to the C++ Core Guidelines. It's not perfect, it has some flaws, including some sabotaging advice apparently adopted for political reasons. But at least it has some C++ authorities (Bjarne and Herb) as authors.