Being aware that the gun you're holding naturally tends towards pointing directly at your own foot does not make the existence of the footgun any more tolerable. Even the best developers will fuck up; having your language enforce memory safety is objectively a good thing, and arguments against it come from FUDDs and gatekeepers.
C and assembly should 100% be a part of any formal programming education, and then any actual work should be done with memory-safe languages because we're all the dumbest people alive.
I work in embedded systems (more and more test lately though), historically in aviation (not fucking Boeing lol) and test and measurement instruments. So, critical environments. In those situations, when you're writing bare metal firmware, you never dynamically allocate anything. Everything tends to be accounted for, RAM usage is tightly controlled, there are even points where you're counting clock cycles for efficiency. We even accounted for radiation based bit flip events, which are incredibly uncommon, but we know they exist so they have to be handled.
My point is, this is a valid concern in some spaces, but when you use C in a purely functional way, it's not the loaded gun they portray it as.
It is also a serious boon to open source projects because it dramatically limits the damage a PR from someone new might accidentally do. Being able to reasonably expect that this fast, low level code won't introduce memory leaks is part of why even end users tend to like Rust projects.
Being aware that the gun you're holding naturally tends towards pointing directly at your own foot does not make the existence of the footgun any more tolerable. Even the best developers will fuck up; having your language enforce memory safety is objectively a good thing, and arguments against it come from FUDDs and gatekeepers.
C and assembly should 100% be a part of any formal programming education, and then any actual work should be done with memory-safe languages because we're all the dumbest people alive.
I work in embedded systems (more and more test lately though), historically in aviation (not fucking Boeing lol) and test and measurement instruments. So, critical environments. In those situations, when you're writing bare metal firmware, you never dynamically allocate anything. Everything tends to be accounted for, RAM usage is tightly controlled, there are even points where you're counting clock cycles for efficiency. We even accounted for radiation based bit flip events, which are incredibly uncommon, but we know they exist so they have to be handled.
My point is, this is a valid concern in some spaces, but when you use C in a purely functional way, it's not the loaded gun they portray it as.
I'm aware that it is technically possible to program a microcontroller in rust, but it felt like a lot more work than doing it in C
It is also a serious boon to open source projects because it dramatically limits the damage a PR from someone new might accidentally do. Being able to reasonably expect that this fast, low level code won't introduce memory leaks is part of why even end users tend to like Rust projects.