Not really; Go is GC'd. C++ isn't memory safe.

Using unique_ptr correctly is memory safe. For example:

  std::unique_ptr<int> p(new int(1));
  std::unique_ptr<int> q = p;

Should fail.

You can strong arm it into break but you can also reuse a pointer locally in Go after it was sent over a channel.

C++ really isn't memory safe. It's trivial to think of an example:

    #include <iostream>

    auto f() {
        int x = 1;
        return [&] () { return x; };
    }

    int main(int, char **) {
        std::cout << f()() << std::endl;
    }

Of course "using <x> correctly" prevents bugs as long as - as C++ does - you define "correctly" as generously as possible. I agree Go isn't totally memory safe, but the level of memory safety is insanely less than in C++.

If you want something particularly involving unique_ptr, consider that best practices are to give non-owning sharing as raw pointers: you could say they're safe as long as you use them correctly but again that misses the point. I can also give an example (stolen from a talk) directly involving shared_ptr even when used with traditional "best practices" although I'm sure the best practices will update themselves to include this.

In some sense, Rust has been described as merely formalizing and automatically enforcing the best practices that people were already using in C++; it's the formality and automaticity that turns it from a dangerous language to a safe one.