151–160 of 272 posts
Earlier quoted context omitted.
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.
You will never change my mind.
Earlier quoted context omitted.
> but it's still possible to use memory incorrectly Only by misusing unsafe . Using it in regular programs actually isn't that necessary. In languages like C you have unsafe code almost in every line. > My understanding is that a memory bug is when you use memory in an unintended way Memory safety rules are more strict and formalized than you think. Memory safety issues are typically reading uninitialized memory (or…
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…
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 mistakes.
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…
As a user you should be far more worried about running up-to-date software and supply chain risks rather than zero-days related to memory safety.
Earlier quoted context omitted.
In case of such projects like LLVM C++ usage can be tolerated. But for new code or smaller codebases a better alternative should be considered. Also Fil-C can't be used for LLVM anyway, since performance and memory consumption overhead is way too much. Nobody wants clang/rustc working 4x slower and consuming 2x more memory.
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…
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 allows getting rid of old stuff present only for historical reasons.
> BSD variants
Aren't needed if we writing a new kernel from scratch.
> CUDA, OpenCL
Not a huge problem. There are dozens of GPU-related languages. Adding one more isn't that problematic.
> Vulkan, DirectX, Metal
They are language-agnostic (but still unsafe). One can create an implementation in something other than C.
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.
> 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.
> 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 Good to see a praise for C#.
Earlier quoted context omitted.
As a user you should be far more worried about running up-to-date software and supply chain risks rather than zero-days related to memory safety.
You wouldn't have to worry so much about running up to date software if memory safety were pervasive.
I don't particularly care about Rust vs Fil-C shit flinging, I don't even see them as competing since they have effectively near opposite tradeoffs. You could even use Rust alongside Fil-C to ensure the unsafe blocks are safe. It would even be interesting to turn off some of Fil-C's expensive protections in the safe parts of the Rust code, making an average-of-both-worlds sort of solution. What I do care about are C…
Isn't this what MIRI already does?
One of the top two issues with Rust is its cumbersome and overbearing syntax and anything which sidesteps that is automatically attractive to anyone which is worried about memory safety and doesn’t like to encode every little detail about in the type system. That’s the majority of programmers… think about it, that’s one of the big reasons people switched to GC languages which are the most popular languages.
The classic Rust approach to addressing criticism of the syntax was a mix of downplaying, gaslighting and “you’re holding it wrong”. But if easy to use, reasonably ergonomic alternatives become available, I expect that most would prefer them to Rust.
I was not aware of the antagonism from the Zig / Fil-C people to Rust, but it makes absolutely no sense. Like, of course you can prevent all memory safety errors by using a garbage collector. That has been known since the 90s. In fact, there was a good two decades after Java released where all the research on memory safety just stopped, because the standard answer became "use a GC". If you couldn't use GC, you were s…
owning_ref is unsound and shouldn't be used. self_cell/yoke/ouroboros are much better alternatives, ableit more complex