Live data from Hacker News

The Case for Memory Safe Roadmaps

nsa.gov

301–310 of 427 posts

Re: The Case for Memory Safe Roadmaps

#301

Earlier quoted context omitted.

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

You can also cause a segfault in Go by dereferencing a null pointer. That's another example of not being entirely memory safe.

In this case it's not memory unsafe. It is guaranteed to crash the program (or get caught). It's closer to a NullReferenceException than it is to reading from a null pointer in C. There's no memory exploitation you can pull off from this bug being in a Go program, but you could in a C program

Re: The Case for Memory Safe Roadmaps

#302

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

Now a "high speed fiance" is something you should be really careful around

Re: The Case for Memory Safe Roadmaps

#303

Earlier quoted context omitted.

Rust is memory safe by default, with unsafety as an optional feature that you basically never need to use unless you’re writing extremely low-level code, need absolute maximum performance, or are interfacing with libraries written in other languages. C++ is unsafe by default. Of course it’s just as easy to write bugs in unsafe Rust as it is in C++ (actually, it’s probably even easier), but defaults matter.

This is a common conception, and I agree to a point. However, interfaces matter. At the interface to _literally any_ system call, unsafe starts to creep out. Either in the wrapper implementation, or in the interface _to_ the system, or even leaking through the wrapper to the caller. At that point, if we have to re-wrap everything in rust to hide the unsafety of the interfaces to the system (sockets, shared mem, etc e…

> At the interface to _literally any_ system call, unsafe starts to creep out. Either in the wrapper implementation, or in the interface _to_ the system, or even leaking through the wrapper to the caller.

It’s quite rare to have to make syscalls directly in Rust, just like it is in c++. Most code in any large enough system is related to the internal logic of the system, not to its interface with the outside world. And when you _do_ need to interface with the outside world, you can use a wrapper (lots of the standard library is basically wrappers around syscalls; this is true in any language). And no, in Rust unsafety doesn’t typically “leak through” interfaces, unless those interfaces are buggy.

> why not just write safe cpp wrappers?

There’s no such thing. It’s not possible to write a safe interface to c++ code in the sense that that term is used by the Rust community. In Rust, “safe interface” means: assuming there are no bugs in the underlying code, and the client code never invokes `unsafe`, using the interface cannot cause undefined behavior. This is impossible to guarantee in c++.

> I love Rust, but using it for anything nontrivial makes the "safe" patina really fade. You're quickly writing what feels like C, with MaybeUninit all over.

This is not true at all in my experience. I work on Materialize, surely one of the more non-trivial Rust programs that exists. We use very little unsafe/MaybeUninit/C-like code. Do you have an example of a codebase you’re thinking of that does this?

Re: The Case for Memory Safe Roadmaps

#304

Isn't C++ with RAII reasonably safe? I tried to learn/like Rust but it's against how I use to think. If no friendlier safe high speed programming language appears, I rather use C/C++ and trade safety for friendliness.

I was shocked to learn that reaching an end of a function without returning is actually UB and the compiler doesn't stop you; only warns. For example: ``` class Foo; Foo get_foo() { std::cout int main() { const auto foo = get_foo(); } ```

(HN weak markdown, indent 2 spaces for code-block)

Re: The Case for Memory Safe Roadmaps

#305
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?

There are categories of software for which C++ is still the clear best choice due to its superior expressiveness as a systems language. There are also other types of safety beyond memory safety that are better supported in C++ than other systems languages. As a practical matter I haven't seen a pointer issue in years, working from a C++17 foundation, so the expressiveness and other safety benefits are more valuable t…

> There are also other types of safety beyond memory safety that are better supported in C++ than other systems languages.

Such as? Genuinely curious.

Re: The Case for Memory Safe Roadmaps

#306

In the world of graphics programming, you've got: - continuing accumulation of documentation and utility libraries from Khronos - excellent learning materials from the community - tons of legacy code all using C++. https://github.com/KhronosGroup/Vulkan-Utility-Libraries https://github.com/cg-tuwien/VulkanLaunchpad https://cescg.org/our-services/an-introduction-to-vulkan/ Until I see professionals get funding to buil…

important comment.

Re: The Case for Memory Safe Roadmaps

#307
post #50

Earlier quoted context omitted.

Commenting bc I had the same question. My impression of historical Python is that is an old, partially arcane language that due to D.S/AI is now popular; I would initially think it would be no better than those other interpreted. Python does these things well... mainly due to pandas/dataframes/polars.

Language wise, Python is basically just Perl with its arms cut off and bunch of makeup added. It's just very popular in the scientific community, so they have to add it.

I don’t know how you can possibly come away with this conclusion after studying both languages. Maybe if your point of reference is an ancient version of Python?

Re: The Case for Memory Safe Roadmaps

#308

Earlier quoted context omitted.

Rust programmers want the government dollarinos? Amazing. It did feel a bit coordinated.

"${LANGUAGE} programmers" aren't really a thing. Our important skills translate fairly cleanly between ecosystems.

Ok fine, then to quote the parent to whom I was responding, “Rust advocates.”

I am willing to bet that most of those “Rust advocates” are programmers who code in Rust but I’m fine with not calling them that. I agree that good programmers should be able to work in different languages, operating systems, countries.

Re: The Case for Memory Safe Roadmaps

#309
post #70

Earlier quoted context omitted.

Isn't Ada memory-safe?

the internet says "it tries to be". http://www.ada-auth.org/standards/rm12_w_tc1/html/RM-13-9-1.... https://old.reddit.com/r/ada/comments/mme3jk/is_ada_memory_s...

In summary, Ada tries to be memory safe by default -- as far as that can be done without requiring automatic memory management and garbage collection -- but deliberate use of "unchecked" language features can break memory safety.

In other words, if you go out of your way to use unsafe features, and don't use the features that compensate, Ada is memory unsafe. This has become the goto dismissal of Ada, apparently more popular than "eww...a BEGIN..END language" and "designed by committee/government tainted".

Re: The Case for Memory Safe Roadmaps

#310

What is their stance on using C++ with sanitizers? Anyone know?

The framework they're working with here isn't about specific recommendations like this. It is about non-memory safe languages, mitigations you can try to add safety, and a framework for moving towards memory safe languages over time. It's at a higher level of abstraction than "specific language with specific technique."

In the PDF the closest things they talk about to sanitizers are SAST/DAST tooling, which isn't exactly the same thing, and compiler mitigations, which aren't exactly the same thing, but I also don't believe this is intended to be fully comprehensive at this level of detail.

Post reply on HN