One of the things I hear the most lately in the programming world is the holy grail of technology: memory-safe languages. If you don't know, these are languages that, by design, aim to prevent issues like memory leaks and unverified channels. I have strong feelings about these languages, and while I recognize their benefits, I also see significant drawbacks (That are usually ignored by most "techbros")
I don't deny that memory-safe languages have their uses; end-user applications benefit greatly from them, and they can empower less experienced developers by reducing the likelihood of common programming errors. However, this comes at a cost: these languages often implement layers of abstraction that can hinder performance and limit control when you need to operate outside the scope of what the language design allows.
Some might argue, "But you should only use these languages in end-user apps, not in low-level programming!" The reality is that many advocates of memory-safe languages push to use them in low-level contexts, sometimes resorting to "unsafe" tags to bypass safety features. This usually leads to a umaintainable mess of unsafe tags, and it kinda defeats the porpuse of memory-safe programming in the first place.
The key takeaway is to use the right language for the right project. Don't let the devotion for one specific language blind you from better, faster, and simples alternatives. Write code that works.