Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The Case for Memory Safe Roadmaps

nsa.gov

Post reply on HN
Print view View original

241–250 of 427 posts

Re: The Case for Memory Safe Roadmaps

#241

Post by ElectricalUnion »

Zambyte wrote: post #82
nobleach wrote: post #29

Earlier quoted context omitted.

Hurd any day now, right? I do wonder what this landscape could have looked like if all of the effort had gone behind a Mach-based microkernel. I read all of the back and forth between Tanenbaum and Torvalds. At the time, I was just so excited to see "free and open" winning. I should specify that the XNU Kernel from Darwin/OSX took a lot of my attention when it first premiered.

Hurd works in the same sense that OpenBSD works. It has very limited hardware support so you'll likely have to run it in a VM, but it does work.

If you're willing to split your workload into VMs in the first place I think application-level segmentation like Qubes starts to become a more interesting idea that microkernels.

Re: The Case for Memory Safe Roadmaps

#243

Post by ARandomerDude »

manishsharan wrote: post #201
natsucks wrote: post #163

Earlier quoted context omitted.

"In attempts to mitigate the dangers of memory unsafe code in C and C++, many software manufacturers invest in training programs for their developers. Many of these training programs include tactics designed to reduce the prevalence of memory unsafe vulnerabilities produced by those languages. Additionally, there are numerous commercial and industry trade association training programs. Further, various organizations…

Does the training go beyond showing them how to use Valgrind ?

How to quit vim.

Re: The Case for Memory Safe Roadmaps

#244

Post by butlerm »

1970-01-01 wrote: post #210

Fully agree. The best time to stop giving the next generation of coders the gift of unsafe memory is today. C and C++ should be known as 'legacy' languages.

It is generally speaking difficult to make an efficient implementation of the compiler and/or the virtual machine for many memory safe languages without writing it in a more efficient, statically compiled language like C, C++, or Rust. And that is to say nothing of software like operating system kernels and browser engines. So perhaps Rust will gradually take over the world there.

Re: The Case for Memory Safe Roadmaps

#245

Post by trealira »

logicchains wrote: post #89
CJefferson wrote: post #36

Earlier quoted context omitted.

Next thing they'll be giving requirements for people building bridges, houses, and gas and electricity fittings. Seriously, I think the time has long since passed software needs regulating. It's a major part of modern society, and as far as I'm aware, most people aren't opposed to building standards in principle.

If software had been regulated like engineering we'd still be writing horrible OO-heavy enterprise Java style code like in the 90s and UML would be mandatory.

We'd probably be using Ada. The government used to mandate that contractors write software in Ada, but they stopped because of the pushback they got; now they also use C++.

Re: The Case for Memory Safe Roadmaps

#246

Post by miohtama »

jvanderbot wrote: post #151
jerf wrote: post #22

Earlier quoted context omitted.

Really, the only memory unsafe languages still in use are C and C++. If it weren't for the behemoth of legacy code we'd really have this problem more-or-less licked. Unfortunately, that behemoth is still rampaging across the landscape. "Rewrite it in Rust" gets a bit of pushback, perhaps even justified, but at this point in time I'll take anything that just reduces that behemoth in size. The journey of a thousand mil…

Why are C and C++ considered the same, in these conversations? C++ at least has tools to make life significantly more safe. I can write a buffer overflow in any language, and on the scale of difficulty, ASM-C-C++-Rust-Python covers my experience (from easiest to fuck up to hardest). Yet nobody is calling for us to rewrite everything in python. Why is the line drawn at Rust? It's perfectly simple to trash memory in Ru…

> It's perfectly simple to trash memory in Rust.

What makes you think so? Most Rust programmers and programmers from other languages, agree that this is not possible. I might be missing something, but can you give an example of such simple methods to trash memory in Rust, asking from a curiosity standpoint?

Re: The Case for Memory Safe Roadmaps

#247

Post by staunton »

joncrane wrote: post #145
jmclnx wrote: post #32

I advise training programmers instead of throwing them in front of a screen without any training. Companies these days provides no training at all. When I was hired over 40 years ago, I spent plenty of time being trained for my first 3 months. Now, nothing, and you if you want to train a new person, you do it on your own time.

I feel like each company/organization has such a unique DevOps toolset that all the "training" goes into figuring out which IDE you're allowed to use, which git client to install, what even are the processes/policies for installing stuff on your work computer, what's the workflow, etc etc etc. All the bandwidth is used on that and there's not much left over for the actual art of coding.

It's plausible that in many settings this is actually most efficient from the point of view of the company.

Do training on the things that can cause trouble longer term (inconsistent tooling taking over, security issues, company-specific things you cannot find online) and just hope people pick up the rest as they go. Good workers will usually manage. The people deciding how to train new workers maybe don't even know what kinds of "main" knowledge a given worker would need. Rather than assigning an expensive senior worker to training them, they might hope someone good willing will do it in their spare time.

Re: The Case for Memory Safe Roadmaps

#248

Post by estebank »

matthewdgreen wrote: post #227
jvanderbot wrote: post #151

Earlier quoted context omitted.

Why are C and C++ considered the same, in these conversations? C++ at least has tools to make life significantly more safe. I can write a buffer overflow in any language, and on the scale of difficulty, ASM-C-C++-Rust-Python covers my experience (from easiest to fuck up to hardest). Yet nobody is calling for us to rewrite everything in python. Why is the line drawn at Rust? It's perfectly simple to trash memory in Ru…

What I don't understand is the excitement for using Rust vs. using garbage collected languages like Golang, at least for high-level applications (performant or low-level systems applications are excepted here.) My experience is that an experienced programmer can be a lot more productive quickly with Golang, since they don't need to climb the Rust borrow-checking learning curve. Rust doesn't even free you from the nee…

> Rust doesn't even free you from the need for a runtime or standard library.

Could you elaborate on this? Rust doesn't have a runtime (beyond what C has), and am having trouble understanding what you meant to say about stdlibs.

Re: The Case for Memory Safe Roadmaps

#249

Post by zozbot234 »

projektfu wrote: post #213
marcosdumay wrote: post #71

Earlier quoted context omitted.

Neither Ada nor Rust are completely memory-safe... and they are partially unsafe in completely different ways. But I guess people prefer the Rust explicitness.

Ada is safe if you never free memory explicitly. The story for reclaiming memory without GC was always a little weird, basically pool allocation by type. But it does bounds checking, counted strings, and has a reasonably rich type system that allows variants and things in a safe way.

Ada has Controlled types, so the memory reclaiming story can be similar to C++/Rust RAII. What it's missing compared to Rust is the lifetime and borrow checking.

Re: The Case for Memory Safe Roadmaps

#250

Post by UncleMeat »

gosub100 wrote: post #105

Can someone explain why we can't double-down on C++ and, through compiler wizardry and reduction in toolset (say, strings can only be fixed-size at 32 chars, 64, or 256 long. No raw pointers, allocator zeroes out all freed memory), achieve a memory-safe language? Obviously, making certain concessions would be a deal-breaker for some, but it might be viable for legacy codebases. If you were to try to make C++ memory-s…

"Ban a ton of widely used C++ features" creates a problem that is smaller than but still comparable to "rewrite it in rust." You also still have some features of modern defensive C++ that can still be abused and cannot be removed from the language or made safe without something resembling the Rust borrow checker.

Getting these features in the C++ language itself will be absolutely impossible, both because of massive performance implications and well as nightmarishly large ABI breaks on everything.

There are various efforts to do what you are describing. I think that they are often a good idea, but they absolutely will not solve the problem conclusively.

Post reply on HN