91–100 of 272 posts
The problem with choosing Rust over a GC language like the above (or a good one, like OCaml) isn't that it's not "fine" to use Rust, but that manual memory management is an inefficient use of developer time. That's an issue for the developer, and one he inflicts on himself, not an issue for the end-user. Both Rust and (safe) GC languages provide memory safety, after all.
There are only three programs where memory safety matters: HTTP server, browsers, and operating systems. In practice, really just browsers and operating systems. Memory safety schemes that don't work for those systems are primarily cosplaying if their goal is safety.
That's really just not true. Easy counterexample: any codec should be written in a memory safe language. Really anything that deals with untrusted input should be memory safe. Your TLS library. A load balancer. Your password manager.
Trying to figure out Fil-C's "inviscaps".[1] When you allocate space with Fil-C's "malloc", some additional bounds checking data precedes the space the program gets to use. Pointers are "fat pointers", with a pointer to the beginning of the buffer and a pointer to someplace within the buffer, allowing ordinary C pointer manipulation. There's much new verbiage around this. But it's roughly the same idea as GCC "fat po…
Invisicaps are not exactly fat pointers. Fat pointers show up inline in memory, which has a bunch of problems: - sizeof(void*) changes - either you let the bounds get corrupted by bad casts, unions, and other issues, or you impose restrictions that prevent unions from working compatibly, or you end up supporting unions by having issues with races, or you need special hardware. Invisicaps sidestep all of those issues
Earlier quoted context omitted.
Invisicaps are not exactly fat pointers. Fat pointers show up inline in memory, which has a bunch of problems: - sizeof(void*) changes - either you let the bounds get corrupted by bad casts, unions, and other issues, or you impose restrictions that prevent unions from working compatibly, or you end up supporting unions by having issues with races, or you need special hardware. Invisicaps sidestep all of those issues
The "flight pointer" looks an awful lot like a fat pointer. See the diagram at "The intuition of inviscaps" in [1]. A "flight pointer" has a pointer to the beginning of the buffer, which they call the "lower bound ptr", and a pointer to someplace within the buffer, which they call the "integer ptr". The pointer to the beginning of the buffer lets the checker find the size of the buffer, which is stored preceding the…
The closest technique to invisicaps is softbound, but that has issues that invisicaps resolve (better story for races, more comprehensive safety for all of the C and C++ languages, no need for large virtual memory reservations, and lock freedom)
I think the "Fil-C is safer than Rust" thing is an understandable reaction to 10 years of Rust evangelists telling people they have to use Rust otherwise they're stupid and wrong.
It’s tiresome when other language communities start engaging in a battle with a vocal minority of another community.
Every language has its annoying maximalist pushers. The play is to ignore them and do what decisions are best for the language, not to let yourself get dragged down into petty language wars where nobody wins.
My biggest problem with the refusal to be memory safe is the fact that those problems end up becoming my problems when I am forced to use these applications and I have to think about how there might be a zero-click zero-day that uses an overflow in some random codec. Not as a software developer, but a regular person I want my application to be written in rust or at least use fil-c at bare minimum. Now as a software d…
If as a user you're willing to pay these library/application owners and premium to do so, by all means; this is a reasonable demand. But short of a massive campaign to educate and change minds, I can't see the average user caring enough.
The problem with this post is the extent to which it shows that its author has an unhealthy obsession with me personally. It’s weird but also oddly flattering. I don’t dislike Rust, and when I point out that Rust is not fully memory safe, it’s because I find the details here super interesting. It’s interesting that Rust deliberately chooses to have an unsafe subset. It’s interesting how that leaks out to the rest of…
As someone who really enjoys seeing all of the different programming languages and their approaches to different problems, it’s becoming obnoxious to hear the constant battles among people who think programming languages need to become part of your identity. The endless battles of superiority and tit-for-tat responses feel petty and distracting.
It’s refreshing to get back to people who just want to try different things and experiment without making everything into a battle where each side scores points against the other.
As long as rowhammer is still out there, aint none of your memory safe. Fixing rowhammer is the memory safety absolutism I want to hear more about.
ECC memory fixes rowhammer. And random bitflips. Everyone should have ECC memory, but Intel disagrees because they are greedy. My system sometimes detects a few bitflips per day.
Perhaps you should replace your RAM, or it's a sign that you have a massive source of radiation lurking somewhere?
Pizlo is not a memory safety absolutist. His rhetoric towards rust is a tactic specifically designed to draw more attention to him and his project. It is amplified by people who already had a bone to pick with rust and take joy in giving rust folk "a taste of their own medicine," so to speak. Articles like this are taking the bait.
What a weird take. I think the limits of Rust’s memory safety are interesting to discuss, as are the limits of Fil-C’s perf and practicality. It’s best to discuss these things rationally, rather than accusing folks of trying to draw attention