I don't agree, especially on the second point. Having strings default to empty instead of nil is a feature not a flaw.

What Go actually needs: Nil-Safe Types! [1]

Programmers can work around verbose error handling(3) and lack of enums(1), but forget to check for nil before using a pointer... CRASH! And that's something the compiler doesn't warn about.

[1]: https://wakatime.com/blog/48-go-desperately-needs-nil-safe-t...

As an ex security consultant almost all the bugs I found in Go applications were crashes that happened because of nil. It’s crazy how Rust just gets rid of this whole class of bugs with option and result types (and sum types in general).

> It’s crazy how Rust just gets rid of this whole class of bugs

As do TypeScript, and Kotlin, and Dart, and Python (with MyPy), and C#, and Swift...

It's honestly inexcusable that Go, as a relatively new statically-typed language, doesn't have strict null-checks

Unfortunately in any real world typescript or python the type checking is almost always partial. Which means it doesn't actually save you from these kind of errors.

I have not found this to be the case in Typescript code I've worked on. The main issue I've found with TS is stuff coming in from outside the system as JSON that doesn't conform to expected formats.