Go is a great language -- I greatly admire its simplicity -- and for its domain it's fantastic. Rust is in a different domain: low-level systems programming in which abstractions must be zero-cost and control over the machine is crucial.
If you want a fixed size array of bytes, for for it. Zero overhead. If you want a slightly smarter list you can use a go slice, which is also pretty low overhead. I've personally verified that if I create a struct in go it takes up the exact same amount of memory as the same c structure.
As a concrete example, I recently built an interface to kernel crypto apis using pure go (no cgo). There's no magic to go data structures, you can define structs in go and pass pointers directly to syscalls (through the syscall package) and everything just works. Dealing with large arrays of binary data is similarly straightforward. So go does give you complete control over memory layout if you choose to use it.
The elephant in the room is that go does have garbage collection, and that ain't free. Practically you can minimize it's impact by managing your own memory. In fact that's what Brad Fitzpatrick is doing with his go based memcached implementation.
It all boils down to how you define systems programming. I guess if you mean is go suitable to write a kernel in, the answer is probably no, (but it would sure be fun to try). If systems programming requires having the complete ability to interact with the operating system and all syscalls + tight control over memory layout, then maybe go is the way to go.
with respect to python and garbage collection, did you know you can actually turn it off? If you have no cycles in your program you can turn off gc and let the ref counter clean up all your data, similar to Objective-C's ARC.
The article is about doing safe manual memory management. That's something that's unique to Rust.
Since HN is Lisp country, it has to be said that having GC isn't an "elephant in the room" - though a slow GC implementation may be.
There's the overhead to check the bounds on operations in that array, which you don't have in C.
Speaking in general:
You get all this wonderful language functionality, and I promise you that you will write some shitty code at some point just to keep up with the daily pressures presented by a successful software package (clients screaming, salespeople breathing down your neck, etc), I don't care how good of an engineer you think you are. What's really funny is that, because everything has gotten so much more complicated (dev tools, business, cost of bugs going up, how to make money with software, whatever), the successful software I work on today is not making any more money than the successful software I worked on back in the late 80's running under DOS. Back then, the oop free tools and the target os were simple enough that we really could become SME's on our domains as well as on the dev tools we used to write code for those domains.
C# and java are definitely not the solution for new applications which are expected to generate revenue for the next 10 years. If Rust is just trying to be smarter at what these languages already do, I'm not interested. Something has got to come along which simplifies development, especially concurrency, and allows programmers of varying skill levels to write productive code in. Then after 5 mil loc, programmers coming and going on a project, an app doesn't end up looking like a fragile mess.
The language is designed to make it harder to write buggy code at the cost of some amount of language complexity. Whether this is an acceptable tradeoff will depend on your particular situation.
That doesn't even make sense. Both C# and Java (and JVM, CLR languages) will be used in new billion generating applications in the next 10 years and more.
If you're still using C# or java in 10 years time for a commercial app, the only reason you will not be at a competitive disadvantage is because all the other competitors in your space are using the same languages.
How well does Rust do in this zero (or low) cost department? In C++ STL there's the same goal, but it compiles to code very far from what you would write in assembly without abstractions.
Eg. how are code compactness and data layout optimizations?