Live data from Hacker News

The Case for Memory Safe Roadmaps

nsa.gov

171–180 of 427 posts

Re: The Case for Memory Safe Roadmaps

#171
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 wonder of part of the issue is that 40 years ago, people typically stayed much longer with companies. (I actually don't know what the norm was. My dad was an EE for the defense industry, and IIRC he worked for 3 different employers over his career.)

My dad is in his 60s, started his company with some friends in the 90s. None of them got super rich, but they are all doing well, and all slowly going into pension. The company grew to a mid-size level, but actually most of the early employees stayed, and I think the average tenure is still probably > 10 years. Switching jobs every 3 years is weird, it is pretty much the time it takes to learn the ins and outs deeply enough to be an expert. There's some sense to it, as after learning all you can, it might be better for your career to search for new challenges. There's also the nonsense that switching that often generally yields significantly higher pay.

Re: The Case for Memory Safe Roadmaps

#172
post #25
post #6

Their "Appendix: Memory Safe Languages" lists: C#, Go, Java, Python, Rust & Swift

what do we do about javascript?

Write javascript engines in memory safe languages. I'd vote for rust as rust and javascript's APIs are pretty similar in style, structure, consistency and security/other issues that are not memory safety.

On that note, try valgrind on existing javascript engines, you might be "entertained". (I certainly was, but that was some years back.

Re: The Case for Memory Safe Roadmaps

#173
post #159

Earlier quoted context omitted.

As someone who has worked in C/C++ on teams for a while. My personal opinion is that safe C++ programmers never use pointers - put everything on the stack and use (usually const) references. But I've really got to ask - at that point do you really want to program in C++ anymore or is it just better to use a safer language that removes pointers entirely?

Do "references" even exist in C? Aren't they a C++ thing? How do you manage heap allocations without ever touching a pointer?

Edited for correctness - I was indeed talking about C++ and references are relevant only in C++. C absolutely has stack allocations which can make things a fair bit safer but if you're passing around collections it's usually done by pointer just to avoid copy actions.

Re: The Case for Memory Safe Roadmaps

#174

But how are we going to trade stocks in nano seconds without C++?!

High speed fiance is mostly done in Java and Haskell, because mistakes are expensive. (And yeah, it's one of the very few fields that Haskell enters the list.)

Wouldn't the tail latency really mess with you tho? You could be doing really bad things with bad data.

Re: The Case for Memory Safe Roadmaps

#175
post #6

Their "Appendix: Memory Safe Languages" lists: C#, Go, Java, Python, Rust & Swift

It's unfortunate that there's no mention that not all these languages are equally safe. Go isn't memory safe when using goroutines. See: Golang data races to break memory safety: https://blog.stalkr.net/2015/04/golang-data-races-to-break-m...

Go is memory safe, that post does not means anything in real life scenario.

Do you have a single example in the last 14 years of memory safety exploit using the Go runtime? I'm talking about public and known exploit not ctf and the like.

Re: The Case for Memory Safe Roadmaps

#176
post #140

Earlier quoted context omitted.

Fortran is probably as bad as C, and Ada isn't truly memory safe - they link to Ada/Spark which is but that doesn't seem to have much widespread use. https://www.adacore.com/about-spark

Isn't Ada/Spark in avionics the main use case for Ada these days? So, huge share of a tiny market?

> Isn't Ada/Spark in avionics the main use case for Ada these days?

Hasn't it always been? I'm no expert but always assumed that it was used basically military and avionics, and perhaps other safety critical equipment.

Re: The Case for Memory Safe Roadmaps

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

Sure, but even the best programmers can write buffer overflows and other memory issues. Not that average shops have any interest in actually training people, though.

Best programmers tend to work on the most complex software though. There are small and relatively simple C/C++ programs around which have no know memory issues (but a person with minimal viable knowledge can introduce new bugs even there and that's where training would be useful).

Re: The Case for Memory Safe Roadmaps

#178

Earlier quoted context omitted.

A lot of shops do this in Java. Rust and Zig are usable but nobody's going to switch.

>A lot of shops do this in Java Absolutely not in the memory-safe subset of Java though.

Haha, it's rough when you don't even get arrays of structs!

Re: The Case for Memory Safe Roadmaps

#179
post #117

Earlier quoted context omitted.

Will we one day be able to use AI to make code memory safe?

Reviewing C/C++ code for memory safety is probably a good use case for LLMs actually. Writing memory safe code from scratch is a much bigger ask.

I bet many, many false alarms

Re: The Case for Memory Safe Roadmaps

#180
post #78
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.

"intentional training" (my term) is one of the most under utilized levers to pull for a team or organization to level up. Your observation aligns with my anecdotal experiences with teams, and it's sad to be honest. The pushback I've received is something I'd categorize as "cart before the horse" - executives want to know exactly what will be achieved with such effort before approving any expenditure. The teams I've b…

[dead]
Post reply on HN