Reminds me of the humility every programmer should have, basically we're standing on the shoulders of giants and abstraction for the most part. 80+ years of computer science.
Cool kids may talk about memory safety but ultimately someone had to take care of it, either in their code or abstracted out of it.
Memory safety predates C by a decade, in languages like JOVIAL (1958), ESPOL/NEWP (1961) and PL/I (1964), it follows along in the same decade outside Bell Labs, PL/S(1970), PL.8 (1970), Mesa (1976), Modula-2 (1978).
If anything the cool kids are rediscovering what we lost in systems programming safety due to the wide adoption of C, and its influence in the industry, because the cool kids from 1980's decided memory safety wasn't something worth caring about.
"A consequence of this principle is that every occurrence of every subscript of every subscripted variable was on every occasion checked at run time against both the upper and the lower declared bounds of the array. Many years later we asked our customers whether they wished us to provide an option to switch off these checks in the interests of efficiency on production runs. Unanimously, they urged us not to--they already knew how frequently subscript errors occur on production runs where failure to detect them could be disastrous. I note with fear and horror that even in 1980 language designers and users have not learned this lesson. In any respectable branch of engineering, failure to observe such elementary precautions would have long been against the law."
-- C.A.R Hoare's "The 1980 ACM Turing Award Lecture"
Guess what programming language he is referring to by "1980 language designers and users have not learned this lesson".
The "cool kids talking about memory safety" are indeed standing on the shoulders of giants, to allow for others to stand even taller.
Big non sequitur, but your comment triggered a peeve of mine that I find it ironic when people talk like oldsters can't understand technology.
> ...people talk like oldsters can't understand technology
IMO it is young people that have trouble understanding.
The same mistakes are made over and over, lessons learned long ago are ignored in the present
It easier to write than read, easier to talk than listen, build new than expand the old
This is the way of young people in every domain, not just technology. Much like teenagers think they're the first ones to ever have sex before, young people tend to think they are the first ones to notice "hey this status quo really sucks" and try to solve it.
This can be a strength, to be fair - the human mind really does tend to get stuck in a rut based on familiarity, and someone new to the domain can spot solutions that others haven't because of that. But more often, it turns into futile attempts to solve problems while forgetting the lessons of the past.
Understanding one level of abstraction doesn't mean you understand the levels of abstraction built on top of it. And vice versa.
Your comment sounds like a riddle. I've programmed for 25 years but appreciate there's a lot more going on than what I know.
Upon my own rereading, it is unclear. My point is that the languages most of us use and the fundamental technologies in the oses we use were designed/invented by people who are in their 80s now, many of the Linux core team are 50-60.