Those aren't safe. There are many ways to cause use-after-free with unique_ptr: for example, placing a uniquely-owned object in a vector and clearing the vector in a method call on that object.
In the mean time, we can take advantage of modern C++ safe constructs instead of keep on using C, as new language adoption always takes time.
Lets suppose that some corporation would download the binaries of my project and use it on an embedded system, would it run?
Don't mix languages with implementations.
Currently there are two native compiler toolchains for Go, which only support a given set of OSs and computer architectures.
Additionally some people written Go interpreters with another set of supported targets.
So to answer your question, it would run on the embedded system if :
1 - the hardware could cope with Go runtime requirements
2 - it would be a supported target for one available native code toolchain
But I used MMU-less uClinux as an example because it breaks a lot of assumptions that are made in a lot of code. No dynamic linking(which if I remember go doesn't support by default, or does it even support at all? I haven't written any in a year or two), no protected memory, and no real fork (vfork instead) crosses a lot of code off the list on what you can run. I don't know if go can support it, but I know that the current offical toolchains don't. There may be a feature go has that prevents them running on a platform like this, but it won't be GC. There are some GC'd languages that will run on this platform.
C is great in that is makes very few assumptions and if written carefully can be extremely portable. The base language doesn't even assume there is an OS present. I've only run into one platform that had very little C support. It was a small 8 bit uC that had a very strange execution stack that made C as everyone uses it hard to efficiently implement.
Go compiles to native code, not bytecode. Your post makes it seem like you might be missing this fact.
Go has good cross-compile support so from say a Windows box I can compile a Go program using just the standard library that will run on Windows, or I can compile one that runs on MacOS, or I can compile one that runs on Linux, and I can even compile one that runs on a different processor arch (like I can be running Windows/x86 and compile a binary for Linux/ARM, for example).
But(!) you have to compile a separate binary for each of those platforms, you can't compile just one single executable that runs on all of those systems. The output of the Go compiler is native machine language code for a specific architecture and OS.
eg. I want to compile an http server and run it on either a Windows/x64 box or a chumby Linux device and I'm currently on a Linux/x86 system:
cd mygoprogram
export GOARCH=arm
export GOARM=5
export GOOS=linux
go build
I now have an executable in the current working directory named "mygoprogram" that will run on a Linux system with an ARMv5 processor (say, an old chumby device)
export GOARCH=amd64
export GOOS=windows
go build
I now have an executable in the current working directory named mygoprogram.exe that will run on a Windows/x64 system, but it is completely separate from the binary that will run on the Linux/ARM device despite being built from the same source code.
mygoprogram.exe will not run on the Linux system, and vice versa. Go is like C/C++ in this regard as opposed to say Java where a common bytecode format will make the compiled code still platform independent.
Shipping a VM with the product is not always possible/desireable.
And these are off the top of my head, I'm sure there are others.
I am also active on D forums.
However the mainstream developers aren't aware, or even care, about those languages. Which leaves us in the current state of affairs in the industry.
(Yes you can work around the current GC's but this drives away some developers)