Well, Go isn't really a great language for safety either. Memory safety maybe yes, but not in general. Rust or Zig do much better here.
Use a GC when you can, it's the biggest programming productivity and quality improvement in PLT of the last 60+ years.
[1] Though I know Zig has some interesting mitigations, some used and some under research: https://news.ycombinator.com/item?id=31853964 https://lobste.rs/s/v5y4jb/how_safe_is_zig#c_vddk9j
(I misspoke a bit with "Rust doesn't have GC", it does have opt in basic GC in the form of ref counting, but it's not used much because a headline feature of Rust is code without GC and I guess libs with interfaces requiring GC would be considered uncool)
[1]: there can be memory safety issues in the presence of data races, but this has ever been proven exploitable, doesn't cause the compiler to completely miscompile and is very rare in practice, so it's not comparable to unsafe memory languages.
I agree (typo exploit!)
See eg https://blog.stalkr.net/2015/04/golang-data-races-to-break-m... & https://blog.stalkr.net/2022/01/universal-go-exploit-using-d...
(And also people shouldn't take "nobody developed an exploit for this vulnerability yet" as any kind of strong evidence, attacks techniques always get better, never worse, over time etc - crypto algorithm people have it right when they start bracing for impact quite early after signs of a theoretical break)
Maybe it doesn't immediately sound as if this is related to security, but it is. If it is hard to model your data and hard to work with it, then people will go the "easy and fast" path.
Think Java: for each type you have to create a new file. Even with modern tooling that is still annoying. So people often shortcut and just use "String". Now you have "String password" and "String userid" and you can swap it up and print the password by accident. Artificial example, I know, but I hope it explains what I mean in general.
That's untrue, Java has inner classes, and they can even be public. A "public static" inner class is nearly indistinguishable from a normal top-level class (the only real difference is that its name in the bytecode has a $ character separating the names, that is, its name in the bytecode ends up being something like "org.example.Outer$Inner").
That being said, it maybe makes it slightly better, but I hope you agree that this is still very much a supoptimal solution and probably comes from a time where searching filenames was the best way to navigate code in the lack of modern IDEs.