> A typical example I have encountered several times now is people using elaborate setups with std::string_view to avoid string copying, while exactly the same

> A typical example I have encountered several times now is people using elaborate setups with std::string_view to avoid string copying, while exactly the same functionality could've been achieved by fewer code, using just a simple raw const char* pointer. C++ can avoid string copies by passing `const string&` instead of by value. Presumably you're also passing around a subset of the string, and you're doing bounds and null checks, e.g. const char* Buf = "Hello World" ; print_hello(Buf, 6); string_view is just a char* + len; which is what you should be passing around anyway. Funnily enough, the problem with string view is actually C api's, and this problem exists in C. Here's a perfect example: (I'm using fopen, but pretty much every C api has this problem). FILE* open_file_from_substr(const char* start, int len) { return fopen(start); } void open_files() { const char* buf = "file1.txt file2.txt file3.txt"; for (int i = 0; i += 10; ++i) // my math might be off here, apologies { open_file_from_substr(buf + i, buf + i + 10); // nope. } } > When I develop methods in pure C, I always enjoy that I can concentrate 100% on algorithmic aspects instead of architectural decisions which I only have to decide on because of the complexity of the language I agree this is true when you develop _methods_, but I think this falls apart when you design programs. I find that you spend as much time thinking about memory management and pointer safety as you do algorithmic aspects, and not in a good way. Meanwhile, with C++, go and Rust, I think about lifetimes, ownership and data flow.