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

211–220 of 427 posts

Re: The Case for Memory Safe Roadmaps

#211

Post by bjord »

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.

Depends on the company these days. In my initial role, I was given a couple days to "read over the codebase" and was then expected to start producing results. Most of my peers had weeks or months-worth if training before they started contributing.

Re: The Case for Memory Safe Roadmaps

#212

Post by ruszki »

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…

Why you need fixed-size strings?

Btw I don’t know how this works in most languages, but circular references can be still a problem even with these restrictions. (If I remember well dangling references can be more or less handled, but correct me if I’m wrong. I remember that JavaScript definitely had problem with those)

Re: The Case for Memory Safe Roadmaps

#213

Post by projektfu »

marcosdumay wrote: post #71
projektfu wrote: post #44

Earlier quoted context omitted.

Ada people scratching their heads....

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.

Re: The Case for Memory Safe Roadmaps

#214

Post by namtab00 »

marcosdumay wrote: post #119
champagnepapi wrote: post #31

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

Jane Street is all-in on OCaml.

Their podcast titled "Signals and Threads" is quite interesting.

Re: The Case for Memory Safe Roadmaps

#215

Post by bumby »

2devnull wrote: post #170
mikeyouse wrote: post #143

Earlier quoted context omitted.

That’s just a customer with requirements.. like all customers.

But, on the other hand it’s not. The government is a virtual monopsony. One customer has unappealing requirements and you can choose not to serve them. The federal government saying don’t hire c devs will hurt c devs. C devs will be understandably dismayed by this.

But this differs from the above statement that specifically referred to "government-related business". The "business" part implies a contract but it doesn't mean all non-govt contracts need to follow suit.

Re: The Case for Memory Safe Roadmaps

#216

Post by kmeisthax »

lambdaone wrote: post #59

"Undefined behavior" in general is a nightmare. After memory safety, the next target should be the enforcement of underflow/overflow trapping. With the exception of the intentional use to implement modular arithmetic, underflow/overflow should always be an error condition.

Rust is already most of the way there. The default math operators still do implicit underflow and overflow, but the behavior is actually well defined: debug builds panic on overflow and release builds wrap on overflow. There is no way to get a C-style "demons fly out my nose" overflow.

There's also explicit arithmetic functions that let you choose your overflow behavior:

* Checked: return None on overflow

* Wrapping: two's compliment wrapped overflow (the "overflowing" variant gives you a carry bit)

* Saturating: return maximum value on overflow

Re: The Case for Memory Safe Roadmaps

#217

Post by timbit42 »

AdamN wrote: post #69
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.

Startups are likely to fail, big tech is likely to fire the developer (or they quit), and poorly run companies just don't know how to train. End result is it just doesn't happen much anymore.

Employers complain they can't find people with the skills they need yet they refuse to provide training for those skills as it's cheaper to hire someone that was trained in the skills they need by another employer.

Re: The Case for Memory Safe Roadmaps

#218

Post by SAI_Peregrinus »

orwin wrote: post #70
DeathArrow wrote: post #55

Earlier quoted context omitted.

>Really, the only memory unsafe languages still in use are C and C++. Ada, Fortran, assembly?

Isn't Ada memory-safe?

Ada isn't, Ada/SPARK is. That's a subset of Ada, and while it is the main draw of the language for new projects the majority of extant Ada code predates SPARK.

Re: The Case for Memory Safe Roadmaps

#219

Post by zozbot234 »

teunispeters wrote: post #172
jerpint wrote: post #25

Earlier quoted context omitted.

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.

Most javascript engines are JIT-based and that's hard to make safe, you'd need a complete proof that the emitted assembly is correct. It's similar to the problem of proving correctness for any compiler.
Post reply on HN