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

331–340 of 427 posts

Re: The Case for Memory Safe Roadmaps

#331

Post by disgruntledphd2 »

0cf8612b2e1e wrote: post #289
synergy20 wrote: post #207

Earlier quoted context omitted.

I recall meta expects new hires to do first commit the first day, not sure how its training will help in this scenario, this is in no way saying meta has no good training, it just does not add up here though.

How is that possible? It takes over a week just to get a new employee configured. Laptop, IDE, permissions to the hundred needed things, etc. Let alone opening up an unfamiliar codebase. Unless it is a “hello world” commit to confirm tooling is operational, I have strong doubts.

> How is that possible? It takes over a week just to get a new employee configured. Laptop, IDE, permissions to the hundred needed things, etc. Let alone opening up an unfamiliar codebase.

When I started at FB in 2013, I had all the laptop/permissions things done by end of the first day.

At the time, the presumption was that you'd push a really small change by the end of the week, but all of the tasks available tended to be pretty easy (note I wasn't in eng then, so all my info is second hand here).

Re: The Case for Memory Safe Roadmaps

#332

Post by inamberclad »

helsinkiandrew wrote: post #176
KMag wrote: post #140

Earlier quoted context omitted.

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.

I think it's also used in high speed rail.

Re: The Case for Memory Safe Roadmaps

#333

Post by Xylakant »

steveklabnik wrote: post #315
chasil wrote: post #135

Earlier quoted context omitted.

SQLite is able to carry most of the justification for C itself at this point. Duplicating the DO-178B certification that it has obtained in an endorsed language will be an incredible burden for any who attempt it.

Ferrocene has said in the past they plan on going for DO-178 in the future.

But we do not plan on rewriting SQLite, that much I can say :)

(My reading is that the GP points to the exemplary achievement that SQLite has reached a close to (security) bugfree, at what I consider a nearly superhuman effort)

Re: The Case for Memory Safe Roadmaps

#334

Post by lostin »

ahmedfromtunis wrote: post #194

How about a new drop-in replacement language for c/c++? I'm in no way an expert in any aspect that relates to this problem, but it's reasonable to believe that it would be but a mildly challenging task if companies like Google, meta, Microsoft and the likes joined forces. A year of concentrated efforts might be sufficient to rid us with this problem once and for all. Billions of lines of codes would gain (some) safet…

Do you mean something like Carbon? https://github.com/carbon-language/carbon-lang

Re: The Case for Memory Safe Roadmaps

#335

Post by ryao »

kmeisthax wrote: post #216
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:…

Do you mean the C compiler's optimization passes can do strange things to code paths that overflow? The last I checked, C would wrap on overflow too. Rust uses the same compiler backend as C, so it could very well have the same behavior emerge from compiler optimization passes.

Re: The Case for Memory Safe Roadmaps

#336

Post by jmclnx »

natsucks wrote: post #163
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.

"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…

>"In attempts to mitigate the dangers of memory unsafe code in C and C++, many software manufacturers invest in training programs for their developers

I have seen that too over the years and even been to a couple when I went to other companies, 99% of the time these classes are worthless and consists of marketing drivel. Half the class contains statements like "You can do it the hard way, or the easy way if you purchase ....".

One instructor even stated "You do not need to worry about running out of memory, allocate as much as you want". That class was 20+ years ago. After that I told my manager I will not go to any more vendor classes.

The training I am referring to is by experienced peers and goes on for many months where your work is reviewed in detail, 1 line at a time with you there. That use to happen decades ago, now no more.

Re: The Case for Memory Safe Roadmaps

#337

Post by stouset »

jerf wrote: post #272
stouset wrote: post #262

Earlier quoted context omitted.

> 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. Will somebody please tell me why everyone seems obsessed with optimizing for programmers going from zero to minimally productive? I have been using Ruby for twenty years, Rust for eight, golang for nine, and C for twenty-six. Most programmers will…

Conversion friction. Very important. Arguably the reason why Haskell is not 10-100 times more popular than it currently is; the conversion friction is just too much, and even if all the tooling was perfect and the libraries were perfect and the documentation was perfect it would still have too high a conversion friction to attract a community the size of Go or C# or something.

I can sympathize somewhat with this argument. But it’s also kind of circular to me.

Go being easy to pick up and learn is certainly a virtuous cycle insofar as it helps bootstrap a large community. And that’s absolutely happened!

But that is—in my mind—more of an explanation for why Go has become so popular so quickly more than it is a compelling argument for the language itself. Haskell having conversion friction might explain its lack of adoption, and that’s certainly a great argument in a discussion about why or why not to adopt it for yourself or your team! But it seems like an overvalued axis on which people seem to evaluate languages on their own.

As a counterexample: PHP classically had a reputation as being a language that was very easy for beginners to pick up. And it’s even memory safe! But it also had a reputation for having poor long-term prospects for projects written it as well as being a limiting factor in the growth of engineers using it (note: I make no claims as to the fairness of this reputation, nor to its applicability on “modern” PHP).

PHP is arguably even easier to learn than Go. So why is it that virtually nobody jumps in these discussions trumpeting that?

Re: The Case for Memory Safe Roadmaps

#338

Post by caskstrength »

jerf wrote: post #22
wodow wrote: post #6

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

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…

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

It is not only or even mostly legacy. I'm a systems programmer (in classical sense, not "but my web service is soooo highly loaded and scalable that I will call it systems programming!") and from what I see on the job people start new projects in C and C++ all the time.

Re: The Case for Memory Safe Roadmaps

#339

Post by ryao »

logicchains wrote: post #72
anonymoushn wrote: post #43

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.

What is the memory-safe subset of Java? Java is memory safe by definition. Sadly, the definition might not give people what they want, which is bug-free code.

Re: The Case for Memory Safe Roadmaps

#340

Post by ryao »

It is a shame that there is no open source equivalent to tools like Astree:

https://www.absint.com/astree/index.htm

In theory, it is possible to write completely memory safe code in C/C++ using it. As long as its analysis generates no complaints, there are no memory safety issues in the analyzed code.

Post reply on HN