"100% of our production system is now running Go"

The anything-but-the-OS-niche? I thought we had plenty of languages for that.

It's better to centralise the memory management and optimisation either into a VM or compiler. It's easier and safer to verify a compiler (mathematically or otherwise) than every memory access that you do.

You seem to ignore performance altogether, if you programmed in C/C++ for twenty years but don't care for performance and don't do low-level work, why have you been using C/C++?

Or if you have been doing low level or performance critical work, why wouldn't you want a safer alternative for that?

When you have to tune and debug your application to please the garbage collector having to deal with your own memory seems like child's play. It is much easier and safer to verify that your own memory management won't bite you than it is to be sure that your garbage collector won't eat you. (surely that depends on the context etc. but making broad claims seems to be on topic...)

Right tool for the right job. C/C++ has "monopoly" on a lot of use cases (way more than any other language) and considering its issues I truly believe that a "better C/C++" is needed, way more than those 20 JVM-based languages that popup every other month. Or Go.

It is extremely fast.

The main risk is process failure which is very rare but can be mitigated via putting a front end balancer such as nginx or apache mod_proxy. Process recovery and spawning can be managed by another tool such as supervisord.

However, you can run a process happily from init if you desire.

We have plenty of languages, but most of them are low performance interpreted languages, have major compromises or are not architecturally sound. Go addresses a lot of those issues - more than any other language so far.

You seem to ignore performance altogether, if you programmed in C/C++ for twenty years but don't care for performance and don't do low-level work, why have you been using C/C++?

I don't ignore performance. There are many ways to achieve performance. I've worked on embedded systems (military, medical sector) and occasionally need direct hardware access which is where I use C/C++ and that is primarily to manipulate a device and hand off a suitable abstraction to a higher level language (with a garbage collector).

When you have to tune and debug your application to please the garbage collector having to deal with your own memory seems like child's play. It is much easier and safer to verify that your own memory management won't bite you than it is to be sure that your garbage collector won't eat you. (surely that depends on the context etc. but making broad claims seems to be on topic...)

That is all down to determinism. Determinism can be achieved in various simple ways. If you understand the language, you can write code that pre-allocates and reuses memory in critical sections therefore invoking no garbage collection penalty. Isolating critical sections from each other is still a problem in C/C++ if you consider the threading model that they use.

Right tool for the right job. C/C++ has "monopoly" on a lot of use cases (way more than any other language) and considering its issues I truly believe that a "better C/C++" is needed, way more than those 20 JVM-based languages that popup every other month. Or Go.

I'm not a fan of all "those 20 JVM-based languages" - I find them tedious and ugly. I'm the most critical person on the planet when it comes to this sort of thing. Go pretty much hits the mark.

I think your complaints could be addressed with a simple extension to pause the collector therefore introducing determinism i.e:

   func CriticalFunc() {
       defer runtime.ResumeGC()
       runtime.PauseGC()
       // critical section
   }

   // this defines the entry point
   package main
   
   // import formatting and HTTP server packages
   import (
   	"fmt"
   	"net/http"
   )

   // This is your HTTP Server instance
   type Hello struct{}
   
   // This is a method on your HTTP server instance that sends hello for all requests
   func (h Hello) ServeHTTP(
   		w http.ResponseWriter,
   		r *http.Request) {
   	fmt.Fprint(w, "Hello!")
   }
   
   // this is your entry point
   func main() {
        // create a new HTTP Server instance
   	var h Hello
        // tell the runtime to serve it
   	http.ListenAndServe("localhost:4000",h)
   }

You are writing a bunch of handlers (as you would with Apache) and plugging them into the compiled in web server from the standard library.

For network servers, there is standard library support for SMTP, HTTP, normal stream based text protocols etc as well as serialization formatters and parsers for JSON, XML, HTML etc. You should never have to re-invent the wheel.