Live and let live, don't tell others what they need.
That's pretty rich
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.
It has nothing to do with anything you do. It has everything to do with the impact it has on everyone but yourself.
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.
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.
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.
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.
I do not excuse it.
It's not really relevant.
Besides, none of those have to do with software engineers. Compliance doesn't imply any individual responsibility.
> I've worked in defense and there are stringent security requirements for applications and servers.
Like? FEDRAMP? The vast majority of compliance is about threat modeling and access controls.
No, STIGs.
> The vast majority of compliance is about threat modeling and access controls.
If compliance doesn't address security, that sounds like a bigger issue than a new hobby language existing.
And we're telling them they shouldn't.
> but for code that’s supposed to be used in production it’s useless
This isn't about doing what you love - it's about engineering a product, a product that needs to have certain safety, security, and stability guarantees. That's the context of this conversation, and for that purpose, Hare isn't suitable.
Then ... don't use it. Others can use it and see what they learn from it, or even whether they find it productive to build stuff with. Even Brainfuck and Malbolge have devoted users who enjoy the challenges they pose, so I can promise you there's room enough in the world for this language. Let's just have some camomile tea and calm down a little.
Furthermore, it could be argued that our time could be spent more productively than on a language like Hare.
As for whether our lives could be used better, well, let's leave that to each individual. I heartily encourage you to live your life as I do, worrying about what I myself am spending time on (currently: this inane conversation), rather than whether other people might be spending their own time in some supposedly-slightly-suboptimal manner.
It is literally everywhere. Your kernel, your networking stack, your interpreters, your office suite.
Almost everything you use has some roots in C, a memory unsafe language that "messed up" and still became the most widely used language ever.
Software will always mess up, regardless of language it's written in.
Do I really have to guess the order that my procedures are called? FP zealots say that I do.
What makes generics and functional programming style mandatory for any given language?
These things just add complexity and philosophy to a field that values pragmatic thinking.
Functional programming is not pragmatic. And neither are thusand ways to handle generics.
It doesn't have in-built immutable data structures, most basic data structures and types are mutable and have mutate in place methods as their primary way of interaction. Struct fields being private by default is a dead giveaway (unnecessary in an FP language). Closures and functions are not the same thing and you cannot do much with them except calling them and passing them around.
I would rather describe it as an imperative language with lightweight OO (via traits) and some FP sprinkled on top. Note I'm not saying you cannot write FP code in it or that Rust doesn't have great unique benefits.
Immutable data structures by default would involve avoidable overhead, so that's why they aren't a built in. There are well-known crates that do provide persistent data structures in Rust.
> Struct fields being private by default is a dead giveaway (unnecessary in an FP language).
Data hiding is just as useful in functional programming; in particular, it enables you to expose an interface to data that stays valid under any isomorphism, while preserving desired invariants. Structs with generally accessible and updatable fields are a special case.