pron

55 ms·

811.
by pron 1y ago
I don't agree that "you never have to worry about it" unless you're also using smart pointers, which is rarely what I want. I think that the alternative where all allocations and deallocations are made clear (in Zig, all
812.
by pron 1y ago
I completely agree, but given that even in Java, which eliminates the memory leaks Rust doesn't, programs still have bugs and security vulnerabilities, I don't think it's about what is and isn't memory safety. Most of th
813.
by pron 1y ago
I would say: not the ones with spooky implicit actions and hidden heap allocations, but we won't know until we actually have data. When writing in a low-level language, I always want to know where I'm allocating and where I'm
814.
by pron 1y ago
Fair enough :) I guess one could claim that some feature is useful because it eliminates certain classes of bugs while another is useless because it eliminates certain classes of bugs (which happens to be the more impactful subset of the
815.
by pron 1y ago
Well, when Rust came out I had only been programming in C and C++ for about 15, maybe 20 years, but I think that even then we generally used memory safety to refer to problems that can cause "type confusion". In any event, given t
816.
by pron 1y ago
I am not redefining what safety means. I am using the same definition of safety used in this entire thread by those debating the pros and cons of Rust being safer than Zig. I definitely didn't say that memory leaks don't matter. T
817.
by pron 1y ago
> The same useless claim could be made for C and with the same effect It really can't be. Memory safety is problematic because it's a common cause of some dangerous bugs . Of the two main kinds of memory safety, Rust generally
818.
by pron 1y ago
We keep talking about completely different things. If we're talking about "features that can help reduce some bug" then C++ or Rust have some that Zig doesn't and Zig has some that C++ or Rust don't. Which ends up m
819.
by pron 1y ago
You can rule out a bounds violations from all but specifically marked unsafe code.
820.
by pron 1y ago
The vast majority of catastrophic problems - nearly all of them, in the grand scheme of things - including those that can cause total system failure or theft of all data are not considered memory safety issues (which is one of the reasons t
821.
by pron 1y ago
That's just beautiful!
822.
by pron 1y ago
> Who told you that? There is no one definitive definition of memory safety, but it generally refers to things that can lead to undefined behaviour (in the C and C++ sense), usually due to "type confusion" (or sometimes "h
823.
by pron 1y ago
> When like Zig, C or C++ everything is potentially unsafe It is not true that in Zig "everything is potentially unsafe". Zig offers bounds safety, which, BTW, eliminates the most dangerous kind of memory unsafety ( https:&#x2F
824.
by pron 1y ago
> And C has free, but you have to remember to use it and use it correctly every single time instead of the memory working by default with no intervention. Tangential, but memory leaks are not considered a safety issue, especially by thos
825.
by pron 1y ago
> Then why do my data structures detect if I go out of bounds? I didn't mean you can't write C++ code that enforces that, I said C++ itself doesn't enforce it. > Yes. You can clean up memory allocations automatically wi
826.
by pron 1y ago
> Any rhetorical device that equates Java/C# (any memory safe Turing language ) safety with C is most likely a fallacy. I agree, but I didn't do any of that. If anything my point was that 1. safety is clearly not a binary thing
827.
by pron 1y ago
> I explained in some detail exactly why this equivalence exists. No, you assumed that Zig and C++ are equivalent and concluded that they'll follow a similar trajectory. It's your premise that's unjustified. A problem
828.
by pron 1y ago
> The point is that if you look at the history of programming languages simplicity in general goes against safety... C and assembly are extremely simple compared to java, python, C#, typescript But Java and Python are simpler yet safer t
829.
by pron 1y ago
> Maybe if someone bends over backwards to rationalize it, but not in any real sense. In a simple, real sense. Zig prevents out-of-bounds access just as Rust does; C++ doesn't. Interestingly, almost all of Rust's complexity is
830.
by pron 1y ago
> Unless you actually use the simplicity to apply formal methods I don't think simplicity make a language safer. That depends what you mean by "safer", but it is an empirical fact that unsound methods (like tests and code
831.
by pron 1y ago
Not to mention that `Arc` uses a GC (and not a stellar one, at that)...
832.
by pron 1y ago
Thank you! I did have one once ( https://pron.github.io ) but I don't know how accessible it is :) (two post series are book-length)
833.
by pron 1y ago
> I think people are disappointed because we finally got a language that has memory safety without GC, so Zig seems like a step backwards Memory safety (like soundly ensuring any non-trivial property) must come at a cost (that's j
834.
by pron 1y ago
> C++ already illustrates this idea you're talking about and we know exactly where this goes. No, it doesn't. Zig is safer than C++ (and it's much simpler, which also has an effect on correctness). Making up some binary di
835.
by pron 1y ago
Problem is, like they say the stock market has predicted nine of the last five recessions, the Rust compiler stops nine of every five memory safety issues. Put another way, while both Rust and Zig prevent memory safety issues, Zig does it w
836.
by pron 1y ago
> just another memory unsafe language Also, treating all languages that don't ensure full memory safety as if they're equally problematic is silly. The reason not ensuring memory safety is bad is because memory unsafety as at t
837.
by pron 1y ago
P.S. What's funnier is that their assumption requires an even bigger leap of faith than their conclusion, i.e. more people are inclined to believe that P ≠ NP than that if someday somebody did find a tractable algorithm for SAT, that a
838.
by pron 1y ago
The paper's authors' reply to the comment is really bad. E.g., it says this: > With respect to the assumption, we have clearly elaborated on why a mathematical assumption is essential for proving computational hardness results
839.
by pron 1y ago
The problem is this: a proof of P ≠ NP is likely to appeal to some theorem in some area of mathematics. Whether or not that theorem has already been formalised is actually unimportant, because it's already accepted as convincing. But t
840.
by pron 1y ago
To be more concrete, event though two programs can both be meaningless in C++, i.e. C++ says nothing about what they actually do once compiled and run, we can sometimes say that one of them is much more likely to lead to a security exploi

More ›