Have you ever heard of Java native Interface or Java native abstractions? Thats unsafe AF. Same goes for native implementations. Whenever something needs to be

Have you ever heard of Java native Interface or Java native abstractions? Thats unsafe AF. Same goes for native implementations. Whenever something needs to be done fast, the jvm implements native code. Have you ever debugged that magic bs? Guess why people chose a high level language, because they don't want to bother with complicated stuff. Still those abstractions on these languages are not better, even worse considering their APIs, than rusts. Working with thread locals or synchronized keywords, non atomic members and all the bad concurrency mechanisms inside Java is unsafe shy default. Runtime exceptions is what I consider a bad practice and it's spread everywhere in Java... Also the language evolutions are not really that good. So bringing errors/exception to the compilation time is a safety net. Despite the fact that languages with managed memory safety bring a lot of potential for abusively high memory consumption, random GC stop the world situations and worse like oom. Whenever I had to analyze a memory issue with an application it was no fun at all, despite the challenge. The jvm specifications are so flawed considering security... Creating classes at runtime from a stream using reflections, which is totally spec compliant gave us log4shell. Why even load serialized classes from remote?! Fail by design. So safety is still context sensitive and depends on the requirements. If you write bad software you can ignore some of the mentioned aspects, though it still lacks of 'security' Just my 2 cents here