Both the defenders and detractors of Google's Go language acknowledge its limitations. But according to conventional wisdom, they're there for a reason, and if you want to do things differently, fork Go and make your own version.
Toni Cárdenas, a developer involved in several Go-related projects, is doing exactly that. He's rolled out the first iteration of of SGo, a Go variant that prevents certain panics, aka application crashes, by catching them at compile time instead of runtime.
SGo doesn't provide these features by forking the Go compiler or runtime. Instead, it's more like a transpiler: It takes code written in SGo and generates a new Go program that adheres to SGo's rules.
In Go, variables that are uninitialized are set to nil. Unfortunately, this means there are times when an application expects a value, receives a nil instead, and crashes because the condition wasn't handled. The current version of Go doesn't do compile-time checking to prevent those problems from seeping into running code.
SGo compiles to conventional Go source code, but along the way, it provides compile-time checks. If the SGo compiler encounters a pointer, interface, map, channel, or function that could be set to nil, it throws an error.
In situations where you need nil, SGo provides a syntax for "optional types" -- a variable that can be either a stated type or nil. The flexibility of optional types is deliberately restricted by SGo -- again, to prevent a nil-related crash.
Another SGo addition, "entangled optionals," allows you to return with a function either an error or another set of values if the error is nil. This kind of multiple-return pattern for error handling is common for Go, so this feature, and many others in SGo, complement how Go already works.
Cárdenas claims these latter features "introduce absolutely no runtime costs." However, as he documents, the final Go program built from SGo code also doesn't know about SGo's features.
Most criticisms of Go focus on the language's lack of generics or its error handling. In the minds of Go's creators, these are intentional design decisions, so the only way to address them would be to fork the language wholesale.
SGo's ambitions are more modest. They're aimed at catching problems that crop up in the language as it currently stands, but don't require the major, breaking changes that a full-blown fork of Go would entail.