>Rust and Go are both touted as memory safe. While this statement is absolutely true

Duh?

>So both languages are memory safe in that they are not memory unsafe

This is more accurate statement imo. Saying Go is memory safe [1] is like saying a lamb is safe among a heard of hungry lions.

[1] http://www.pl-enthusiast.net/2014/07/21/memory-safety/

From that article, safe Go prevents: buffer overflow, use after free, use of uninitialized memory, illegal free, access to undefined memory. The only thing it misses is null pointer dereference. (OOM errors are not possible to prevent in turing-complete languages.)

I don't agree with your analogy. A lamb among lions is clearly very unsafe, but Go isn't unsafe; you just agreed with me on this. Your analogy fits better to C/C++. The lamb could theoretically survive, but it's very unlikely; just as unlikely as a C/C++ program with no memory bugs.

Yes I do generally agree with you. I went a bit overboard - somewhat HN pushes me over the edge sometimes :-(

Lamb metaphore would not do Go the justice indeed. I do like Go, but also do not like some opinion which oversimplify reality.

Again, how are those "the first" after people stopped tolerating new unsafe languages?

We hadn't had a new memory unsafe language catching on (or released from some major vendor) since what? C++? It was pretty much standard by the time Java was out. Heck, there were mainstream Smalltalk in the 90s, with IBM support, IDE's et al.

So Smalltalk, Java, VB (up to 6), C# and others all all languages that predated Go and Rust in memory safety, and came out in an era memory safety was de rigeur.

Just adding Ada, Modula-2, Modula-3, Oberon, Oberon-2, Active Oberon, Component Pascal, Turbo Pascal, Quick Pascal, Delphi, Eiffel, ... to your safety list.

It is incredible how two decades of C and C++ becoming mainstream, change the perception of all existing alternatives.