Fil-C is basically an alternate ABI and libc runtime. Otherwise it is not tied to C and I see no reason it couldn't be targeted by Rust or Zig.
Yes
Memory safety absolutists
61–70 of 272 posts
Re: Memory safety absolutists
#62Earlier quoted context omitted.
> But it turns out there's all sorts of delightful data structures that you can only express with unsafe in Rust. Intrusive doubly linked lists are the coolest thing ever. I don't mean this to be a gotcha, but I think it's important to say that we can have these in rust too! The only difference is that the first thing we have to talk about is you the user can go about using an intrusive collection correctly. I love t…
I think this crate description encapsulates what's difficult about unsafe rust, which is how unergonomic pointers are. Like why do I need to use `addr_of_mut!`? I'm sure there's a good reason, as Rust tends to think these problems through, but it's very unintuitive compared to returning `&mut`. I feel like I'm juggling way more concepts, which to be fair helps with safety, but it can obscure the algorithm itself. Doe…
> Like why do I need to use `addr_of_mut!`? I'm sure there's a good reason, as Rust tends to think these problems through, but it's very unintuitive compared to returning `&mut`.
That documentation appears to be out of date. The `addr_of_mut` macro was elevated to a first-class language feature, `&raw mut` (there's also a corresponding `&raw` operator). These two operators differ from the usual `&mut` and `&` in that they create raw pointers rather than references; prior to the introduction of this feature (or the aforementioned macros that served as precursors) to create a raw pointer you might need to have done a cast like `&foo as *const` in order to create a raw pointer by casting from a reference, but this could have safety consequences if the temporary reference was to an invalid object. Therefore `&raw` and `&raw mut` were introduced to create raw pointers directly without introducing an intermediate reference, which was arguably the most subtle footgun in unsafe Rust for a few years, and it's nice that it's now addressed.
Re: Memory safety absolutists
#63The 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 the language. It’s interesting because us language designers ought to be thinking about how this could be avoided. It’s a hard problem! And that makes it fun!
If you do read what I say on twitter, you’ll find praise for Rust, many concessions about Rust being faster than Fil-C, as well as a wide range of other opinions. When I point out Rust’s unsafety, I’m just citing facts. It’s interesting how doing that really seems to upset some folks.
Pointing out a limitation in a technology does not imply dislike, and it’s best not to take it personally.
Re: Memory safety absolutists
#64Earlier quoted context omitted.
> But it turns out there's all sorts of delightful data structures that you can only express with unsafe in Rust. Intrusive doubly linked lists are the coolest thing ever. I don't mean this to be a gotcha, but I think it's important to say that we can have these in rust too! The only difference is that the first thing we have to talk about is you the user can go about using an intrusive collection correctly. I love t…
I think this crate description encapsulates what's difficult about unsafe rust, which is how unergonomic pointers are. Like why do I need to use `addr_of_mut!`? I'm sure there's a good reason, as Rust tends to think these problems through, but it's very unintuitive compared to returning `&mut`. I feel like I'm juggling way more concepts, which to be fair helps with safety, but it can obscure the algorithm itself. Doe…
> what's difficult about unsafe rust, which is how unergonomic pointers are. Like why do I need to use `addr_of_mut!`?
Things are slowly getting better here! '&raw'/'&raw mut' reference operators were stabilized a couple years ago.
Another ergonomic improvement in the pipeline is a better way to access fields behind pointers, something like C's -> operator. This is taking some time to design because there are things other than raw pointers that would benefit from a generalized field projection mechanism, like Pin, NonNull, and (potentially user-defined) smart pointer types.
Re: Memory safety absolutists
#65Earlier quoted context omitted.
> But it turns out there's all sorts of delightful data structures that you can only express with unsafe in Rust. Intrusive doubly linked lists are the coolest thing ever. I don't mean this to be a gotcha, but I think it's important to say that we can have these in rust too! The only difference is that the first thing we have to talk about is you the user can go about using an intrusive collection correctly. I love t…
I think this crate description encapsulates what's difficult about unsafe rust, which is how unergonomic pointers are. Like why do I need to use `addr_of_mut!`? I'm sure there's a good reason, as Rust tends to think these problems through, but it's very unintuitive compared to returning `&mut`. I feel like I'm juggling way more concepts, which to be fair helps with safety, but it can obscure the algorithm itself. Doe…
> Like why do I need to use `addr_of_mut!`?
As of Rust 1.82.0 [0] you no longer need to!
> I'm sure there's a good reason, as Rust tends to think these problems through, but it's very unintuitive compared to returning `&mut`.
The addr_of_mut docs [1] give a pretty decent explanation of its reason for existence; in short, it lets you get a pointer to something without needing to create potentially-invalid intermediate references. It (and &raw) probably aren't going to be needed if all you need is a &mut, though.
> Does cordyceps have a derive macro?
Doesn't appear to from a quick glance, and given what's in the safety section of the docs [2] it'd probably need to be marked unsafe [3]. Unsafe attributes are new to Rust 2024, though, so that might be a bit new.
[0]: https://blog.rust-lang.org/2024/10/17/Rust-1.82.0/#native-sy...
[1]: https://doc.rust-lang.org/std/ptr/macro.addr_of_mut.html
[2]: https://docs.rs/cordyceps/latest/cordyceps/trait.Linked.html...
[3]: https://doc.rust-lang.org/edition-guide/rust-2024/unsafe-att...
Re: Memory safety absolutists
#66I 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.
Re: Memory safety absolutists
#67Earlier quoted context omitted.
It seems to me that memory safety might be the difference between the software engineering and Software Engineering. As in, an actual Engineering discipline. However, I should probably pipe down, as I would not call myself either one.
There are too many opensource projects that show that even with good engineering discipline humans are flawed creatures. Memory safety is just little thing that makes sure that when you write code at 4am that it will not leak memory via trivial mistakes such as forgetting to free something, freeing something twice or passing a freed pointer. I believe AI agents shine here the most because the they do not get tired an…
How many bugs in qmail though?
Re: Memory safety absolutists
#68I 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.
We can learn a lot about memory safety from Rust. But if we can achieve the same dream of Fil-C for other more common languages that need it, Rust's popularity will likely wane.
Re: Memory safety absolutists
#69My 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.
Re: Memory safety absolutists
#70Earlier quoted context omitted.
There are too many opensource projects that show that even with good engineering discipline humans are flawed creatures. Memory safety is just little thing that makes sure that when you write code at 4am that it will not leak memory via trivial mistakes such as forgetting to free something, freeing something twice or passing a freed pointer. I believe AI agents shine here the most because the they do not get tired an…
How many bugs in qmail though?
It had one bad cve it seems, but that's exactly what I mean. It only takes one mistake, of course you can learn and never make those mistakes again, however, that is an unrealistic expectation in software that receives hundreds of feature updates a year especially when it comes to core applications as basic as communication when it wants to support image previews, reels and whatnot.