And Java is 2x faster than golang in this benchmark when I ran it. Many benchmarks are to be taken with a grain of salt.

golang: 7.76 real 8.67 user 0.08 sys

Java: 3.74 real 3.58 user 0.46 sys

    public class Test {
      public static void main(String[] args) {
        final int numOfStrings = 100_000;
        final int numIters  = 1_000;
        var numStrings = new String[numOfStrings];
        for (int i = 0; i < numStrings.length; i++) {
          numStrings[i] = Integer.toString(i);
        }

        for (int i = 0; i < numIters; i++) {
          var strToInt = new java.util.HashMap<String, Integer>(numOfStrings);
          for (final var s : numStrings) {
            strToInt.put(s, s.length());
          }
        }
      }
    }

What's happening is that the std::unordered_map was a mistake. Many parts of it's API prevent implementing it efficiently (For example, every insertion requires allocation, even if you reserve). It's widely regarded, within and outside the standards committee, as a very unfortunate mistake.

swisstable (absl::flat_hash_map) is a popular choice right now for the hash table to use for C++ code that cares about performance. There are other choices as well (dense_hash_map, F14FastMap, etc), But honestly most choices these days are worse than std::unordered_map (well, boost::unordered_map is probably just as bad, since std's implementation was taken wholesale from boost without any thought!)