I agree. These days I can't even imagine programming in C++ without using STL. It still has some weird ergonomics at some places though. For example - instead of a simple vector.contains(something) we have to write this

  std::vector<T> x_Vec;
  if (!(x_Vec.find(another_x) == std::vector<T>::npos) {
      //some code
   }

Also the ugly std::get<N> syntax..

  auto x = std::get<0>(myTuple);

Why not -

  auto x  = myTuple.0

The first snippet you wrote makes sense for string, but not for vector. For vector, you'd need to do:

   if (x_Vec.find(another_x) != x_Vec.end()) {
      //some code
   }

The reason why vector doesn't have contains() is because it would be an O(N) operation for a vector. STL is generally designed in such a way that, when something needs to do an O(N) lookup, it has to deal with iterators, making the iteration happening in the background a bit more explicit.

But, for example, for std::set and map, you can just do:

   if (a_set.count(x)) { ... }

It's not a good pattern for multiset and multimap, since it won't stop at the first occurrence. C++20 finally added contains() for that reason - but, again, only to associative containers.

Yes, I'd need to check for end iterator in vector. But my point still stands - C++ does have some weird ergonomics.

but isn't find() an O(n) operation already?

Indeed! Which is why find() is not a member function on vector (so my snippet above is wrong - I just missed that part). It's a global function, so you need to do:

   if (find(x, v.begin(), v.end()) != v.end()) ...

For maps and sets, find is a member function though. Same principle - if it is implemented in some optimized way, the class provides it directly, but not otherwise.

If you didn't write your own generic "contains" method on the third time you had this pattern I don't know what to say