Lots of optimized code in Go's standard library has fast paths in assembly which is linked into the final binary on a platform by platform basis. I this sense, it's probably easier than C to drop into assembly. Granted, Go's memory model is not going to enforce a whole lot so you better know what you're doing at this point.
Of course the C parts of Go's standard library have optimized assembly - using C's capability to do.
So Go is not easier in any way for dropping into assembly - in fact it's much harder, you can't do it in the language, at best you might be lucky if Go's library does some stuff like that for you.
This is all compatible with the `go` tool. You just drop in your Assembly, run `go build`, and the appropriate Assembly version is chosen based on your target architecture (or the Go code is used as a fallback if no Assembly for the target architecture exists).
I don't have much experience with inlining Assembly in C, but this is pretty damn easy.
Easy? Sure. Easier than C? Nope. Sounds like it has the equivalent of a few make rules written for you (which is nice, make is a mess, but not really an advantage for go-the-language per se), but you could do exactly the same thing in C - and you can also inline assembly in your C source file.
It gives you more options. It makes it more practical to interleave C and assembly at a very granular level, whereas it sounds like you can only do it at the function level or coarser in go.
>Does C automatically choose the correct target architecture for every piece of Assembly you write?
No. I won't deny that go has a good build system, but I'm more interested in the language.
