std::string doesn’t have a template type for the allocator. You are stuck using the verbose basic_string type if you need a special allocator.

But, of course, nobody sane would write that by hand every time. They would use a typedef, like how std::string is just a typedef for std::basic_string<char, std::char_traits<char>, std::allocator<char>>. Regardless, the C++ standard library is insanely verbose when you start dropping down into template types and using features at an intermediate level. SFINAE in older versions of C++ was mindfuck on the best of days, for example.

Don’t get me wrong, though. I’m not saying Rust is much better. Its saving grace is its type inference in let expressions. Without it, chaining functional operations on iterators would be an unfathomable hellscape of Collect<Skip<Map<vec::Iter<Item = &'a str>>>>

TypeScript […] only adds syntax, and doesn’t re-write it.

I believe enum, const enum, and decorators would like to have a word with you.

Swift also uses backticks and Rust has a dumb one in the form of r#thekeyword. Still much better than introducing a async as a new keyword in a minor version of a language and breaking a bunch of libraries.

Rust is verbose, but C++ might still take the cake with its standard library templates. Especially when using fully-qualified type names…

auto a = ::std::make_shared<::std::basic_string<char, ::std::char_traits<char>, MyAllocator<char>>>();

A reference-counted shared pointer to a string of unspecified character encoding and using a non-default memory allocator.

This means either them or more junior developers will be brought in as glorified prompt engineers.

Oh, sweet summer child. It’s not going to be junior developers; they still have self-worth. An un(der)paid intern or outsourced contractors, however? They’re fine working for scraps and no health insurance.