Not really. And the allure of Go over .NET has very little to do with performance.

Most applications I develop these days are web services. I write most things today in Go, but I used to work quite a bit with C#/Asp.NET applications.

Here's what I do to build a Go web application:

  - go build .

What I get out of it is a single, statically-linked, self-contained ELF binary for which deployment is as simple as scp, if I want to. It will run on any x64 linux box, without dependencies, since it contains its own webserver. I don't need to dump it into IIS to make sure the build works.

Here's what I used to do with .NET:

  - Open VS, wait about 30 seconds for it to finally start working
  - Set the target, Rebuild All
  - Publish to file, wait
  - Eventually get a packaging error, predicated on some obscure tools dependency issue somewhere inside my 98KB .csproj file, which I have to fix by closing down VS, manually editing in Notepad, and re-opening VS
  - Finally get a working build+publish, ok, let's take a look
  - Oh, very nice, the publish directory weighs in at nearly a QUARTER GIGABYTE, and contains about 60 dll dependencies and a ton of entirely useless descriptor files.
  - Well, okay, let's at least get this deployed to the test server to make sure it still plays nice with IIS, xcopy this over.
  - Oh, IIS doesn't like this at all, now let's spend the next couple hours tracking down this insane .net framework dependency hell.
  - Screw it, where's my whiskey?