Memory safety is the new black, fashionable and fit for any occasion | Hacker News Reader

Memory safety is the new black, fashionable and fit for any occasion

theregister.com

37 pointspjmlp66 comments

I think it’s going to be table stakes for all new general-purpose languages. Rust demonstrated that memory safety and speed aren’t mutually exclusive.

I’m convinced that future generations will look at us using C the same way that we look at old race cars withouts seat belts: it’s amazing that people ever managed to use it without immediately dying, but that fatal accidents were horribly common, and that we’d never go back.

> Rust demonstrated that memory safety and speed aren’t mutually exclusive.

memory safety, speed, ergonomics

pick two.

This is fair.

I think Rust is fairly ergonomic, but that's because it happens to work really well with my mental model. I was able to pick it up and produce a multithreaded path tracer in about two weeks.

What are some ergonomic issues, in your opinion?

That's generously assuming that C is ergonomic. Which it is not.

Rust is a heck of a lot more ergonomic than many unsafe languages I've used, so I'm not sure I agree. In fact, it's probably the most ergonomic fast language I've ever used. Zig was pretty close but it had its own issues.

You don‘t have to pick two, you can also just pick one

Looking at you Bjarne

Rust has made some headway in ergonomics too. Obviously the borrow-checker pulls it down quite a bit, but in other areas it makes up a lot of ground: tooling, language features like match expressions, traits (being able to hang new methods off of existing structs) and trait derivations, type inference, and then all the stuff third-party frameworks can do with macros (using something like Rocket isn't too far off from using Flask)

There's still a tradeoff, but they push the boundaries quite a bit

Rust is least ergonomic when you're fighting with the borrow checker.

It might be an interesting strategy to wrap shared objects with Gc<> or Rc<> by default to sidestep the fight. Once you've discovered the slowest parts of your codebase, you could refactor to replace Gc/Rc with zero-cost borrows or well-placed copies.

I haven't tried this myself, but I'm surprised it isn't the standard operating procedure for (non-embedded) Rust programmers.

We should probably have functional programming by default for sanity, wrapping Rust inside it for the speed in inner loops.

Hmm, functional in what sense? Like functions should be pure by default, optionally annotated `impure` or something?

In the sense of allowing at least closures that are garbage collected (without them you can't idiomatically program in a modern functional style)

I think one of the issues is that Rc and Gc are not particularly ergonomic! Used at scale, they add noise/non-readability to any screen of code (Rc::clone, the various approaches for Gc in [0], for instance) that simply wouldn't be there in a dynamic language.

Now, one might argue that this explicitness is good! But it's definitely an extra bunch of things to type when you're building something where you don't care about memory management.

[0] https://manishearth.github.io/blog/2021/04/05/a-tour-of-safe...

FWIW, there's a newer concurrent cycle-tracing GC for Rust known as Samsara. Writeup here: https://redvice.org/2023/samsara-garbage-collector/ It seems that it manages to be more efficient and intuitive to use compared to earlier approaches.

Perhaps Rust syntax could be enhanced to make Gc more ergonomic?

It’s an interesting idea but not sure it works in all spaces. If the goal of something that you’re building is performance, it’s really really hard to convince architectural and API missteps if you’re just liberally throwing around arc everywhere. Additionally, the amount of code you find out you have to rewrite is quite large. A better idea is to recognize where you’re bottlenecks are likely to be and where they’re not and use Rc is the clearly not case, be careful about it in the questionable cases and avoid it like the plague in the cases where it’s a problem.

unsafe { std::transmute(x) } is my favorite go to if I’m sure I have the lifetime mechanics sorted and don’t want to fight the borrow checker right now (oh, and usually the borrow checker is right and I think I’ve done this like maybe 2-3 times where it’s really impossible to convey to the compiler what I’m trying to do, at least with my knowledge of Rust)

Being able to pick two is still an improvement!

Rust binary size is not pretty either.

It isn't "going to be". It is, and it has been for a long time.

Lots of people confusing "memory safety" with the high degree of thread safety offered by Rust. Memory safety is in everything modern except C and C++, and ASM. It's the present baseline, except those.

Nobody is proposing new memory unsafe languages.

Only a few straggler developers, possibly with the same confusion, are loudly insisting they somehow need memory unsafe languages. When you consider what "memory unsafety" means, the claims are transparently risible. Nobody needs the ability to access arrays out of bounds. Nobody needs access to unallocated memory. It's not a serious desire, it's just contrarianism or confusion about what it is.

I recently stumbled upon Jai and Odin, two new languages which are not memory safe.

Ah and Zig is also not memory safe

And Rust, it isn't memory safe since you can go into unsafe anywhere, most languages doesn't allow unsafe code.

Memory safety does not encompass code that is labelled and segregated as "unsafe", because by this definition all or nearly all languages are unsafe. There's always some way to execute some sort of assembly in the end.

You can write 100% safe code in rust. Just don't call into unsafe code or FFI into unsafe languages.

Can you say the same with other languages like C/C++/zig/... ? Van you literally enforce with a compiler switch and/or linter that you're 100 using a safe subset of the language?

You can view unsafe rust as a convenient way to go write in language that resembles rust what you'd otherwise write in C and call via a FFI

Well, then, three languages scratched off my list. At least, assuming y'all are using the correct definition of "memory safe".

There is no sensible reason in 2023 for a language to be memory unsafe. What tiny performance advantages can be eked out are completely and utterly trounced by the multi-decade history of the catastrophic errors made and security vulnerabilities created. Whatever performance optimizations could be made are either A: a bad idea anyhow or B: if not actually a bad idea, available through the use of "unsafe" blocks in an otherwise safe language anyhow.

C.A.R Hoare was already complaining about C in 1980.

The world decided to ignore the likes of Modula-2, compiled BASIC and Pascal dialects, embrace UNIX and C, and so eventually we landed here.

"Advice to software developers and open source maintainers who may be thinking about the transition to memory safe code:"

"First, he advises that developers stop creating more unsafe code by writing new projects in memory unsafe languages" ...

"Second, he says, not everything needs to be rewritten at once. Focus first on security-critical modules."

"Third, he says, open source maintainers don't necessarily need to learn Rust to help with the memory safety transition because many Rust-based modules come with C APIs."

"Finally, he argues that the open source community should understand that the current status quo – an endless parade of memory errors – does not have to continue."

I disagree with point 3. Knowing Rust is key because it is being used to replace C and C++ in performance-critical and low-level applications to ensure memory safety. It has the most momentum and is getting inroads in the Linux kernel, the Chrome web browser and its derivatives, and other places.

C and C++ were great because they were initially simple and let us build fast infrastructure with minimal fuss. They will be with us for years to come as legacy languages. Rust is the present and future because it gives the speed of C and C++ without the recklessness of undefined behavior and "do whatever you want" resource management. It is a choice to embrace a bit more discipline and upfront fuss in exchange for memory safety and data race safety.

While I agree with the sentiment of 2, there is a gap here: a lot of low-level Rust code is necessarily unsafe. In some areas, rewriting in Rust provides margin benefit - an unsafe block is little better than C, for example. We should be searching for targets that are not only critical, but not necessarily unsafe. That being said, any amount of unsafe that can be prevented is better than none.

I appreciate memory safety, but feel memory safety is often discussed to a panacea-like degree, like in this article, that ignores the risks of rewriting to achieve it.

From your example, the idea of porting existing C and C++ code in the kernel or Chrome that has been stable in production for years, or sometimes decades, to Rust. The rewrite itself can create new exploits via the logic, especially considering the level of code being rewritten combined with Hyrum's Law. So is it a higher or lower risk to continue to solidify existing code with better practices and tools (asan, msan, smart pointers, etc), or to rewrite it all in Rust?

I don't know the answer. Because I don't think there's a clear way to evaluate and compare that risk profile ahead of time for any particular piece of non-trivial code. But I do think too many people are discussing rewrites at scale with the justification of memory safety, without considering the risk the nature of a rewrite adds back.

>> I appreciate memory safety, but feel memory safety is often discussed to a panacea-like degree, like in this article, that ignores the risks of rewriting to achieve it.

You are correct. Rewriting working code is a risk, especially for stable, mature projects.

The "panacea-like degree" is probably due to the refreshment, relief, and liberation that developers feel when working in a memory safe environment. When an estimated 70% of errors are due to memory safety issues, the excitement that developers feel is palpable.

>> The rewrite itself can create new exploits via the logic, especially considering the level of code being rewritten combined with Hyrum's Law. So is it a higher or lower risk to continue to solidify existing code with better practices and tools (asan, msan, smart pointers, etc), or to rewrite it all in Rust?

The risks are real and vary on a per-project basis. I think it depends on the needs and expectations of the project.

For example, a mature project that is not adding new features and is not in a critical role or likely to be targetted for security exploitation probably does not need to be changed.

Other projects under active development or in more critical roles may need to be partially rewritten to protect sensitive functionality (e.g. network handling code, input handling, parsers, etc.)

New projects should choose memory safe languages unless there is simply no other option.

>> I don't think there's a clear way to evaluate and compare that risk profile ahead of time for any particular piece of non-trivial code.

Sometimes we don't fully understand the problems until we start writing code. It is part of the nature of software development.

I'm always amazed that people ignore vast ecosystems of libraries on which big systems are built. Libraries and frameworks are not static, and the FFI to (or from) rust is almost always a secondary concern to the developers.

I'm in robotics: A field that absolutely fits the Rust paradigm of safety critical, performance-oriented, and (at least somewhat) progressive (being willing to adopt new things to succeed). And yet Rust is absolutely nowhere to be found in real systems, mostly, I believe, because C++ libraries and frameworks dominate everything and are the foundations on which systems are prototyped and built. These systems are supported by large cloud simulation and metrics frameworks, which are of course built with Python and Javascript.

>> Rust is absolutely nowhere to be found in real systems, mostly, I believe, because C++ libraries and frameworks dominate everything and are the foundations on which systems are prototyped and built.

Industry practices do not change overnight.

Legacy code written in Fortran and COBOL is still in use today. Some of the legacy code we use may not be rewritten. That is fine.

If the benefits outweigh the risks, new code will be written in Rust or another memory safe language.

Either Rust needs to become dramatically simpler or an entirely new memory safe language needs to rise in popularity.

Rust is too complex to go mainstream.

If C++ is mainstream (it is) then complexity is clearly not an obstacle.

There’s historical reasons for that.

C++, if released today, would not result in the same user base.

Pretty sure C++ is mainstream because of C and its own earlier versions, so regardless of the complex mess it became now.

It is not inherently complex, it depends on what components you pick. You can use almost any programming paradigm in C++ nowadays. But I agree that many codebases are complex because of the flexibility and not deliberately choosing a particular paradigm.

For many other languages, it's practical to know the whole language.

C++ is an exercise in trying to make one language do everything and support every paradigm. The explosion of new languages recently shows that that approach is not winning. IMO because it inevitably means a leaky abstraction over a more complicated language, and lots of discipline to avoid the leaky areas. (JS seems to be edging in the same direction, although they have the excuse that browser support for alternate languages is still limited)

Totally agree it's hard to read bit of complex code because you used a reference counted cell.

Rust is already mainstream. Tons of software is built with it and it's already in the Linux kernel. Completely replacing C and C++ is not the bar to clear.

There’s no Rust developer jobs listed on seek.com.au Australias biggest job site.

So not mainstream yet, if usage in companies is a measure.

It’s harder to please the compiler, but simpler to get right than other languages.

> while avoiding the performance cost of automated garbage collection

I think citation needed there. Rust encourages reference counting, which is a very costly form of garbage collection.

Rust supports reference counting through std::rc, but most of its memory management is through lifetime enforcement. Basically C++’s RAII pattern, but baked into the language via the borrow checker.

Not so much when the count is either 0 or 1.

Rust supports reference counting, but it’s a stretch to say it encourages it. I don’t use Rc or Arc all that often.

std::shared_ptr says hello.

IMO reference counting(be it in C, C++, Swift/ObjC or Rust) is a sign that you have ambiguous lifetimes and strongly correlates with a design that has punted on what components "own" what parts of memory.

Even in my C++ designs I push more strongly toward single owner patterns(member vars, std::unique_ptr) and if an adjacent system needs access usually an opaque handle(that can fail to return a value) is the better than using something like std::shared_ptr.

To the point at hand, I would argue that Rust pushes more towards the single owner model with some sets of escape hatches(Rc/Arc, RefCell, etc) when upstream rigid requirements force some of this ambiguity. I've yet to see a non-GC'd language that does a better job here, and I've found the default Rust guard rails to be quite good, even at scale across developers who may not have the depth of background to understand all of the tradeoffs involved.

Rust's type system tracks ownership and one of the main reasons is so the compiler can automatically know when to free memory without runtime reference counting.

I don't think it's correct to say that Rust "encourages" reference counting. Rust's standard library provides `Rc` and `Arc`, but the default paradigm encouraged by Rust is to do no garbage collection at all (since all lifetimes are validated statically.)

Separately, there's a good argument to be made that Rust does reference counting better than C++: `shared_ptr` has to pessimistically assume use across multiple threads, while Rust allows users to safely select `Rc` instead of `Arc` when the compiler can prove that the inner type is `Sync`/`Send`. Consequently, Rust programs that do use reference counting get "free" performance compared to the equivalent C++ APIs.

As others have said it's a bit of a stretch to say Rust "encourages" it, but I'm also not sure it's accurate to call it "very costly". It has different costs than mark and sweep, but Objective-C and Swift specifically use reference-counting because of its performance characteristics

And also in Rust you end up with less increment/decrement on the count, because you can safely borrow the interior without messing with the reference count. You really only need to mess with the count when an owner goes into or out of scope, not every reference.

and you can use non-atomic counts if you’re not multithreaded, which is also cheaper.

True! I wonder how much of the GP's viewpoint came from an assumption that reference-counted pointers have to be pessimistic and always perform locking

Is ARC being very costly the reason why some people prefer Rust over swift?

Give me ECC memory in my laptop. Then we'll talk about software solutions.

Can we have both? This shouldn’t be an either/or situation.

Moving to safer languages may help pushing for ECC, because then it's harder to blame random memory corruption on the executables themselves.

I can imagine a future in which AI analyses C++ and makes it memory safe.

Also, AI assistance will make it alot easier to get stuff done in Rust.

>> I can imagine a future in which AI analyses C++ and makes it memory safe.

Equivalent algorithms are built into the Rust compiler.

Tracking the lifetime of a variable and ensuring that the underlying resources are properly managed does not require artificial intelligence, just good bookkeeping.

There are memory-safe programs that the borrow checker will not let you write because of its limitations (and this will always be true, no matter how smart it gets, and is true of any static type system or checker). This is a conscious tradeoff you make by using the language. It's also why unsafe blocks exist- not so you can intentionally make memory errors, but so you can attempt to safely work around the borrow-checker's limitations

>> This is a conscious tradeoff you make using the language, and it's also why unsafe blocks exist

Agreed. Unsafe Rust is needed to handle specific use cases.

However, unchecked / unsafe blocks are not needed most of the time and should be used sparingly and judiciously.

A future where humans write C++ but then the machine makes it memory safe seems extremely unlikely. Global analysis of non-trivial software is crazy hard. Like, if you have the future tech in a SF novel doing this, there's a fair chance that's the most unrealistic part of the story unless they also have FTL travel.

I'd say it's more likely that a future AI can write perfectly good C++ but, to soothe the poor C++ superfans it will let them type nonsense into a window for a while, then "analyse" their program and substitute one it wrote that's correct. This doesn't involve solving any intractable problems, just confidently presenting a lie.

What is the distinction you're drawing below?

> A future where humans write C++ but then the machine makes it memory safe seems extremely unlikely.

> I'd say it's more likely... it will let them type nonsense into a window for a while, then "analyse" their program and substitute one it wrote that's correct.

The distinction is between successfully understanding an arbitrary program, which we know is not practical, versus just throwing away the human's program and substituting a correct program the machine wrote to solve this problem, which is tractable.

I'm assuming we're telling the machine what the program is for, if we're not it can't analyse anything, maybe my program is supposed to spit out the first million primes, then six more large numbers which aren't prime, and then segfault.

It's much more practical to build memory safety into the language than try to invent a system that is capable of policing logic employing liberal memory access. There were some comments by Bjarne Stroustrup I read the other day that made me believe C++ was not in a hurry to move in that direction.

Give me python syntax, then maybe we can talk.

Python is memory safe, so if you want to use it, you can (?)

Reply on news.ycombinator.com