Rust and Memory safety (non-FreeBSD related)

[RetroComputingCollector]

THIS IS NOT ABOUT RUST IN FREEBSD. IT IS ABOUT RUST IN GENERAL. I AM NOT CLAIMING THAT RUST IS ENTERING FREEBSD. THIS IS SPECIFICALLY ABOUT THE LANGUAGE, ITS INTENDED USE, AND MEMORY-SAFETY AS A CONCEPT.

What is the purpose of Rust? I mean it is memory safe, but C can work fine if the code is high-quality. Memory issues often come from low-quality code, so if you make them impossible, the code will still just be low-quality and unreadable. No-consequences coding encourages sloppy work. If there is less of a punishment for coding like a pasta extruder, then people are incentivized to make crap. I am a Java programmer, and Java is memory-safe, but it is also portable without recompilation. Rust isn't. Of course people will write crap Java code, but Java has a purpose besides preventing crap code from being a security risk.
Can someone educate me on the actual purpose of Rust besides being a C-like language that is harder to screw up.

 

[eternal_noob]

Actual purpose of Rust:

View attachment 22818

 

[mer]

No-consequences coding encourages sloppy work. .... I am a Java programmer, and Java is memory-safe,

Java, is it really memory-safe? It has garbage collection, but one can have allocation patterns that get ahead of the GC and cause problems. Sometimes you can tune the GC to alleviate, but often one cannot.

The first part about "no-consequences coding" I don't disagree with the statement but I would posit that GC often makes programmers think there are no consequences.

At least that has been my experience.
I've spent lots of my career doing embedded systems, limited memory etc. I've had others change their data structure, then complain when they ran out of memory. As the "board/os" guy, they came to me and said why can't we enable swap or get more memory. Yes, insert face palm. But they had a good boss: I explained the problem, pointed out their "small change" quadrulped memory use for that one data structure, I got "Yeah this is our problem not yours"

 

[RetroComputingCollector]

Java, is it really memory-safe? It has garbage collection, but one can have allocation patterns that get ahead of the GC and cause problems. Sometimes you can tune the GC to alleviate, but often one cannot.

The first part about "no-consequences coding" I don't disagree with the statement but I would posit that GC often makes programmers think there are no consequences.

At least that has been my experience.
I've spent lots of my career doing embedded systems, limited memory etc. I've had others change their data structure, then complain when they ran out of memory. As the "board/os" guy, they came to me and said why can't we enable swap or get more memory. Yes, insert face palm. But they had a good boss: I explained the problem, pointed out their "small change" quadrulped memory use for that one data structure, I got "Yeah this is our problem not yours"

It's MUCH more memory safe than anything with manual memory management. Also, the newer GCs like G1GC, ZGC, and Shenhandoah are much better than your classic Serial and Parallel.

 

[cracauer@]

Rust, like modern C++, is a much higher level language than C. The ability to build libraries in C is very limited by a lack of generic programming. Just think of quicksort and binary search in C. The library has them, but the interface is a joke of casting things around. It can be hard and error-prone to build reusable data structures in C.

 

[Espionage724]

Also, the newer GCs like G1GC, ZGC, and Shenhandoah are much better than your classic Serial and Parallel.

I got slightly faster server start-up times with Parallel vs Serial (anything else was worst Java 21), and significantly better average/max FPS on a JOGL game with Serial vs Parallel. Java's fun to tweak for

 

[suntzu00]

but C can work fine if the code is high-quality.

that's a very big if. we've learned that's rarely the case

 

[drhowarddrfine]

we've learned that's rarely the case

And so it begins. The casting of aspersions on virtually all C programmers.

 

[mer]

And so it begins. The casting of aspersions on virtually all C programmers.

Ha.
I winder what kind of C code AI would generate for something that requires multithreaded data base access stuff.
Or even validating inputs from a command line.

 

[T-Aoki]

One thing I must note here (, too) is that ANY PROGRAMMING LANGUAGE ARE SOMEHOW FINALLY TRANSLATED INTO NATIVE BINARY, WHICH ARE MUTUALLY MEMORY-UNSAFE.

Yes, I guess (theoretically) "memory safe CPUs" that mutually prohibits memory-unsafe operations (it should include MMU configurations forcibly, before accessing any memory and I/O operations), but this kind of CPUs would be practically unusable in performance and costs, though.

Imagine, every variable (including block of address ranges like fixed size matrixes) and/or I/O port (if not memory-mapped) requires valid MMU entry at some level, and configurations for user level MMU are completely limited by system level MMU allows for the specific user / group.

For large systems, MMU entry could be larger than the main memory at least in some use-cases!

And having UNSAFE block / functionalities in memory-safe language should be mutually silly and nothing other than describing interfaces for another modules written in memory-unsafe languages should be allowed to described in UNSAFE block in the language spec level, and abusing codes should be error out on builds forcibly. If not, what's memory safety?

 

[cracauer@]

And so it begins. The casting of aspersions on virtually all C programmers.

Memory management can be quite challenging in plain C.

And keep in mind that in most large systems code written and designed by one person is modified by another person. It is very easy to lose track of a piece of memory then, or do use one after free(). We are talking about building complex in-memory structures that are all collections of malloc()ed pieces.

The basic premise that many security holes stem from memory management in C is true. Just takes a bit of CVE reading to verify.