Because software is generally written so that people use it. Memory unsafe languages have proven it's impossible to write secure software in, even by the best of the best developers. That's why I made the comparison with seatbelts. If you want to drive your car on public roads(deliver production software to users) you are not allowed to use memory unsafe languages(you must use a seatbelt). If you just make software for yourself that you don't release to the public no one will care if you write it in C or whatever.
It has nothing to do with anything you do. It has everything to do with the impact it has on everyone but yourself.
Driving also brings great value. Using C over another language "Because you can't tell me what to do" does not. The more apt comparison would be if we had fully self driving cars that are proven to make almost no mistakes. And then still wanting to drive a car yourself on public roads, endangering yourself and others.
C and C++ still see overwhelming usage in many industries because of the business value they provide in terms of performance and how quickly you can produce software in it. That does not seem likely to change any time soon- game studios are not widely adopting rust, for example, and I don't expect that to change, even though they impact a MASSIVE amount of people.
Hare's value proposition is simplicity- which allows you to better reason about the software you write, for one thing. We are each entitled to our own opinion about how valuable that is.
C and C++ are at diametric opposite ends of the scale of value proposition. Listing them side by side eliminates any credibility your argument might have had.
Hare's "value proposition" of simplicity is, simply, a shuck. Any software effort has essential complexity that your language may help you manage, or chuck you in the deep water to sink or swim. Hare does the latter, and is even self-righteous about it.
I mentioned performance and game development specifically. I'm sure you're aware that it's common to write C++ that's very close to C while taking advantage of few features of C++. I don't think it's fair to call that the "diametric opposite of C".
Your opinion of Hare's view of simplicity is your opinion. Any software effort has some amount of essential complexity, in my experience many languages and tools quite a bit of incidental complexity that could be avoided.
You can write bad code in any language. (We used to say "you can write FORTRAN code in any language", back when.) C code compiled with a C++ compiler is C, and bad. With the C compiler, you had no choice. You do not get that excuse when you have a C++ compiler.
Avoiding unnecessary complexity is everybody's responsibility. Dumping every last bit of unavoidable complexity onto the programmer where it has been long demonstrated that tooling can take care of much of it is simply irresponsible, and inexcusable.
The most common policy will be for SOC2, ISO27001. There's virtually nothing about software security in there, other than scanning for vulnerabilities. Everything else is about controls on infrastructure, threat modeling, that sort of thing.
It's not really relevant.
Besides, none of those have to do with software engineers. Compliance doesn't imply any individual responsibility.
The most common policy for what? I've worked in defense and there are stringent security requirements for applications and servers, which programs written in manual memory management languages would likely fail. "Some existing policies are bad" is not a convincing argument that hare shouldn't exist.
I'm not sure what your point is. I didn't claim memory unsafe languages aren't used, they obviously are. C is in fact not an easy language to verify. There have gone trillions of dollars into that and it's still not solved. You can't verify C. You might be able to verify a subset of C. But if you are in any position to choose any other language you should run, run, run quickly and far away from C.
My point is that your metaphor about "not [being] allowed to use memory unsafe languages" to build a car is completely backwards -- safety-critical embedded systems use C to avoid the abstractions introduced by higher-level languages.
It's not backwards. C is used out of necessity not because it's such a great language. Safety-critical embedded systems use C because they have to. Not because it's nice. Claiming they do because C is such a great language to write safety-critical software in is a special kind of Stockholm syndrome.
I’m allowed to have opinions about what tools should be used for what. I think it’s fair to say you shouldn’t write a production HTTP service in assembly, for example.
You're allowed to disagree with me. I don't claim to be the ultimate authority and I have no power to enforce my opinions. If I were your tech lead and you wanted to use Hare for something I would probably say no but we could have a discussion about it and you might convince me otherwise. But that's not the context here. This is a programming forum, so I will speak my mind.
A person's actions sometimes have effects on other people. Such as not wearing a mask, for example. Or writing some piece of obscure but critical infrastructure with a memory vulnerability that causes all someone's precious apes to be stolen.
How so? I'm sure you take my point: that by indulging selfish wants, we can harm others. Private situations, do what you like; shared or social contexts, not so much.
Oh, hey! That makes them an even more perfect analogy. They help, massively, protecting others by removing many forms of transmission; but they don't prevent all transmission. Likewise, memory safety helps, massively, protecting others by removing many forms of security vulnerability; but it doesn't prevent all security vulnerability. And, crucially, not to get too far distracted from the original point: both are things we try to make use of where we can, not for ourselves, but for others and for the health of our overall communities. To really spell it out in words of one syllable: that's why people care about whether other people use memory safe languages.
All the while I have to use broken, unsafe software on a day to day basis I reserve the right to complain about things that make programs broken and unsafe
The vast majority of software that I use on a daily basis is broken because of logic errors and/or performance problems, not crashes due to memory unsafety. The former has nothing to do with memory safety, and the latter isn't solvable at all by programming language design.
I'm not saying that memory unsafety isn't a problem, but if you really want to make software better, you should address the biggest problems first.
