You sure speak surely about "us" like there is just one group of programmers out there. Some people love JavaScript, some people love C. Some people only use programming languages, some create new ones.

Live and let live, don't tell others what they need.

Let me quote the part of the comment that you didn't read:

> 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.

Honestly memory unsafe languages shouldn't be used with exception of very few corner cases. It's the same reason why we no longer allow cars without seatbelts. You don't go around saying that seatbelts shouldn't be mandatory because you don't need them.

What's with this obsession about what other people do? You don't have to use a memory unsafe language, but others might.

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.

It’s also massively unsafe to drive in general, so we should probably ban the usage of cars wherever possible.

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.

I do not excuse it.

We license people to drive and have a legal system for dealing with irresponsible drivers.

Companies have policies for software security. Industries have regulations.

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.

The most common for companies to have/ be required to have.

> 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.

> Like? FEDRAMP?

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.

The issue is that no one is taking responsibility for writing safe software. Compliance / regulation isn't, developers aren't either.

I can assure you, the automotive industry uses more C/C++ than you've ever seen. C is used precisely because it's a mature and verifiable language.

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.

There is no such language as C/C++. Your statement is meaningless, as stated.

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.

The problem with this is that you're now the Ministry Of Truth of programming tools.

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.

Doesn't even make sense. The Ministry of Truth is tasked with rewriting the past to match the present.

We all have opinions. The 1984 reference is unhinged.

> You don't have to use a memory unsafe language, but others might.

And we're telling them they shouldn't.

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.

> Such as not wearing a mask, for example.

That's pretty rich

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.

Masks don't even work for many of the things people want them to work for.

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.

I personly don't, yet they land on hardware devices and servers I am not asked about, and have an impact on my digitial life.

> for code that’s supposed to be used in production it’s useless

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.

Except maybe one day I'll be using some software written in Hare which will mess up and have negative implications for me.

Furthermore, it could be argued that our time could be spent more productively than on a language like Hare.

Then don't use that software. If you're right, software made with it will be worse - if even producible - and it won't take off. I'm sorry, but the ship has sailed: it is already possible to create bad software. The Hare language is not opening some hitherto-unopened Pandora's box. The same forces carrying good software to the top, and bad software to the bottom - and with them the tools used to make both the former and the latter - will continue to function.

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.

For Christ's sake, you already use messed up software.

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.

What, in your opinion, does functional programming bring to the table for writing things Hare is designed for?

Clearly, it brings a warped perspective on how a CPU functions.

Do I really have to guess the order that my procedures are called? FP zealots say that I do.

Same things it does for Rust.

Why do you feel the need to mention functional programming in a thread about a clearly structured, systems programming language?

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.

Not sure what you mean. Rust has no functional programming either ...

Functional programming patterns are very common in Rust code. It doesn’t have automatic currying or higher-kinded types but it has generic associated types, anonymous functions, closures, and a rich set of collections with functional processing methods in the standard library.

A lot of the standard library and an extensive part of the community ecosystem lives and breathes mutation at both the edges and in the internals, something people normally would avoid when trying to stick with functional programming. Sure, some mutation is always needed, but Rust wouldn't be the first language I'd pick if I want to focus on functional programming for sure.

No, but it’s widely acknowledged that functional programming features are useful even in imperative languages. Almost every imperative language that isn’t C, Go, or Hare has them. Java, C#, JavaScript, Python, Ruby. You should take a look at all the functions available on iterators in Rust if you haven’t. The Rust community tends to prefer using iterators to express things like looping when possible, which is a more functional style.

Mutation within a single program flow is a well-known functional programming pattern, e.g. as supported by the ST feature in Haskell. Shared mutability is much harder to reason about, so is generally excluded and Rust implements it separately.

Rust is a functional programming language, that's exactly what's implemented in the basic borrow checking rules. Interior mutability is added to that featureset, so as to support procedural programming with shared mutable state.

I can not agree with Rust being a functional programming language. I don’t think it has NO functional style idioms, but the borrow checking does not make it functional. That would imply that the only characteristic of functional programming is some sort of ‘variable’ mutability constraint. I may not be up to defining functional programming by exclusion, I think any definition of functional programming includes things Rust does not have.

It borrowed some FP concepts, it's influenced by FP but it's definitely not an FP language. It's very much a language about imperative, explicit control. And that's a good thing for the use-cases that Rust targets.

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.

> It doesn't have in-built immutable data structures

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.

You can't do proper functional programming without garbage collected closures. There is a reason why Haskell has a garbage collector ... and it's not "the borrow checker wasn't invented yet".

Haskell uses a garbage collector to enable closures to extend the lifetimes of values they capture within their context. You can do the exact same thing in Rust by using Rc or Arc, it just isn't required in most cases because the borrow checker can verify that the value is not outlived by the closure.

This point has been made so many times that it gets tiresome. Perhaps that's ok, but it doesn't really tell us anything new.