Gosling said that "[C# is] sort of Java with reliability, productivity and security deleted." (from Wikipedia)
C# incorporates "unsafe" capabilities that allow pointer manipulation. C#'s underlying platform, CLR/CLI (.NET bytecode), was intended to be somewhat more language agnostic than Java (and Java's byte-code). .NET supported, for example, what was called Managed C++ (I have the T-shirt!), though that never really caught on. Managed C++ supported managed as well as unmanaged objects.
C#'s unsafe capabilities allow pointer manipulation, and so, reduce reliability and security as they these extensions are not type safe.
However, the unsafe capabilities are extremely useful. For example, you can memory map files and access the file mapped content without constantly copying bits of the mapped file into some other type-safe object (avoiding both the copy and the generation of soon-to-be garbage).
Further, the "unsafe" features are nicely contained. For one, you can declare whether your program wants to allow any unsafe features at all. For another, if you choose to allow them, then you can clearly locate where any unsafe features are being used (via the keyword
(Note: new language Rust also has a similarly well-contained unsafe capability.)
Still, undisciplined use of unsafe can land you in the same territory as C or (true) C++, with crashes much delayed after some buggy code sequence. I think that Gosling was saying that if you allow unsafe code, then the whole program is suspect, maybe even the whole language: and he's not incorrect from a logical point of view.
However, I think that history is showing that "unsafe" capabilities are not the big safety problem it was presumed to be: that unsafe can be avoided, or, judiciously used-to-advantage, just like invoking native code/APIs (which Java and C# both allow).
I'm guessing that the productivity part of the argument comes from the delayed bugs that happen when unsafe is allowed.