Hacker News Reader

Comment by netr0ute | Hacker News Reader

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

View on HN

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.

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.

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

Reply on news.ycombinator.com