← Back to context

Comment by himata4113

3 days ago

My biggest problem with the refusal to be memory safe is the fact that those problems end up becoming my problems when I am forced to use these applications and I have to think about how there might be a zero-click zero-day that uses an overflow in some random codec. Not as a software developer, but a regular person I want my application to be written in rust or at least use fil-c at bare minimum.

Now as a software developer I feel like this is even more important because I use libraries maintained by thousands of other developers that might also use applications that have these exploits which get their systems compromised pushing malware to thousands of other developers which end up compromising even more libraries.

I believe that memory safety should be the standard for software that thousands if not millions rely on and that it shouldn't be some political issue of X is better, Y is that, Z is something else.

But then again, social engineering is the primary source of malware spread so I don't know.

36 comments

himata4113

Reply
consumer451  3 days ago

It seems to me that memory safety might be the difference between the software engineering and Software Engineering. As in, an actual Engineering discipline.

However, I should probably pipe down, as I would not call myself either one.

  • dns_snek  2 days ago

    > memory safety might be the difference between the software engineering and Software Engineering. As in, an actual Engineering discipline.

    I wouldn't go that far, what matters is the finished whole. Memory safety of the finished program is a critical factor and using a memory safe language makes it easier to achieve that goal.

    However simply using a memory safe language doesn't make you a "Software Engineer" any more than using a certified I-beam makes someone a "Civil Engineer". What matters is that the finished structure/program meets the explicit and implicit requirements of safety, functionality, durability, cost, etc.

    Not to mention that complex reliable systems are usually engineered out of much less reliable components.

  • goalieca  20 hours ago

    There are engineering standards where dynamic allocation and especially garbage collectors are banned. C is actually a perfectly approved language in these cases.

  • himata4113  3 days ago

    There are too many opensource projects that show that even with good engineering discipline humans are flawed creatures.

    Memory safety is just little thing that makes sure that when you write code at 4am that it will not leak memory via trivial mistakes such as forgetting to free something, freeing something twice or passing a freed pointer. I believe AI agents shine here the most because the they do not get tired and are getting pretty damn predictable.

NBJack  2 days ago

If as a user you're willing to pay these library/application owners and premium to do so, by all means; this is a reasonable demand. But short of a massive campaign to educate and change minds, I can't see the average user caring enough.

  • himata4113  2 days ago

    My biggest gripe honestly is businesses rather than any particular opensource project, opensource projects can often get away with these issues getting caught by the many eyes looking at them before they ever make it to mainline.

    • inigyou  2 days ago

      But they usually don't? heartbleed should have put that idea to rest once and for all. The many eyes don't exist.

uecker  2 days ago

As a user you should be far more worried about running up-to-date software and supply chain risks rather than zero-days related to memory safety.