161–170 of 272 posts
The real issue is that we came to accept unsafe languages and are taking a really long time to put such features back.
This is perhaps a different take, but one reason I love Zig and C is because I've learned how to reason in pointers. I've worked with Rust in the past on a ~12,000 LOC side project, so I was all in with tree ownership and XOR mutability. 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. The fact tha…
This is a limitation of the rust model. You could have a language where intrusive linked lists are provably safe.
That's not to say rust doesn't work, but it's the first language I'm aware of that's attempted compile time memory safety, and no body seems to be talking about how to do it better.
That's true, though it's worth noting that they do still need unsafe for the FFI. Often this is where the memory safety issues arise in GC languages. So no language is truly "memory safe".
Earlier quoted context omitted.
Yeah, unfortunately there are plenty of such projects, without alternatives. GCC, GNOME, KDE, Linux kernel, BSD variants, CUDA, RocM, OpenCL Vulkan, DirectX, Metal, GNM(X), OpenMP, OpenACC, NVN,.... Hence why somehow fixing C and C++ is also quite relevant for the upcoming decades, assuming humans still matter on the planet. Now it is going to be ARM MTE, SPARC ADI, CHERI, Fil-C, or WG14 and WG21 actually getting the…
> GCC Isn't needed if we rewriting anything in Rust anyway. > GNOME, KDE They aren't that huge. Huge is the overall codebase of applications using them. It's relatively easy to create a native Rust GUI framework and rewrite applications needed such a framework one by one. > Linux kernel It's a good opportunity to rewrite it. Not only because modern languages like Rust are better than C, but because such a rewrite all…
Likewise with all the industry standards based on C and C++.
Looking forward to see how COSMIC ever manages to gain adoption beyond System 76 computers.
Earlier quoted context omitted.
> you can prevent all memory safety errors by using a garbage collector Garbage collection and a higher-level language that controls allocations handles 2/3 of the memory-safety problem space (using memory you shouldn't via use-after-free, or using memory you shouldn't before allocation/via arbitrary address access), but the other 1/3 isn't addressed by GC: out-of-bounds access on properly-allocated structures. GC-or…
You forgot the other three thirds GC doesn't handle: in-bounds writes to memory currently in use by another processor. One of the basic ideas behind Rust's memory safety story is that eliminating race conditions necessarily requires a good memory safety story, especially regarding temporal memory safety. ...of course, the managed code languages had an answer to this: put a lock on every managed object you allocate. B…
Rust does not prevent race conditions. You're getting confused with data races.
However GC's solution to data races (make every load/store act as very relaxed atomic instructions) makes race conditions much easier to write.
Earlier quoted context omitted.
How many bugs in qmail though?
I don't think we should set our expectations based on an extreme outlier. qmail is special, and we can't expect most software to get to its level of security/safety. Put another way: if you have to rely on programmer skill or attention to detail in order to guarantee something, that will always be a losing bet, on average. The existence of a tiny percentage of programmers that can clear that high bar does not make it…
Also in a program similar to qmail, memory safety alone is not sufficient, a lot of bugs in sendmail were related to complexity issues.
Earlier quoted context omitted.
I think the point you missed or don't want to accept is that I think of all layers of memory management as the same thing just on different layers. Where you say that I mix different concepts, I say that it's just different layers of the same problem. So which layer should we care about? All of them? Yes, if we want the most safety. I will give you an example of how I can use memory incorrectly in "safe" rust. Let's…
> we have to care about not using ages as shoe sizes and indexes with the wrong arrays. "Memory safe" languages usually don't help In languages even slightly better than C one can create a wrapper type for int/float with additional semantics like age, shoe size or something else. Since they are different types, using one in place of other isn't possible. This doesn't solve all problems, but at least can prevent silly…
Earlier quoted context omitted.
Fil-C has a large performance impact though, and it'll always be reasonably significant. Rusts popularity has always been the combo of safety and performance, otherwise you might as well just use C#
> Rusts popularity has always been the combo of safety and performance, otherwise you might as well just use C# Combined with the ability to compile to a single native binary, having a solid package management solution, a fairly advanced type system, and a solid selection of nice language features. Usually you need to give up at least one of those.
Earlier quoted context omitted.
You forgot the other three thirds GC doesn't handle: in-bounds writes to memory currently in use by another processor. One of the basic ideas behind Rust's memory safety story is that eliminating race conditions necessarily requires a good memory safety story, especially regarding temporal memory safety. ...of course, the managed code languages had an answer to this: put a lock on every managed object you allocate. B…
> One of the basic ideas behind Rust's memory safety story is that eliminating race conditions Rust does not prevent race conditions. You're getting confused with data races. However GC's solution to data races (make every load/store act as very relaxed atomic instructions) makes race conditions much easier to write.
This is perhaps a different take, but one reason I love Zig and C is because I've learned how to reason in pointers. I've worked with Rust in the past on a ~12,000 LOC side project, so I was all in with tree ownership and XOR mutability. 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. The fact tha…
(part of this I think is some C teaching which tended to overemphasize linked lists because they are useful for teaching the concept of pointers, which gave a lot of people learning C the impression that it should be the default way to represent a list of objects, when it's far more the exception than the rule)