221–230 of 230 posts
Earlier quoted context omitted.
> I usually find myself wishing I could have some macro where I just write in C and have it exposed as an unsafe back in Rust. There’s a macro for doing this with Assembly, I can imagine one could be made for C. But why wouldn’t you just write unsafe rust at that point?
Perhaps because you want to import something you don’t want to rewrite? There’s a lot of tested C code out there.
This claim just killed me: "Apart from [Zig] not having crazy UB like in unsafe Rust". Zig has more UB than even C. Yes, Zig has safety checks you can turn on, but then it's not fast anymore. The claim saying Zig has no UB is like saying C has no UB because you can run it with UB-sanitizers. Don't get me wrong, it's great to have this directly enabled in "safe" mode like Zig does it. But to use that to say Zig is mor…
Earlier quoted context omitted.
I think we’re on the same page here. Neither of us agree with a blanket assertion that code written in Rust is flawless and free of bugs. This can be easily disproved by looking at the bugs fixed in the Rust compiler and standard library, and looking at open soundness issues in the Rust issue tracker. I think CVEs are useful in tracking the security of your code, but can’t be meaningfully compared between languages.…
Yea, I think we're mostly on the same page. For higher level domains where unsafe isn't required and some runtime overhead is acceptable, I believe there's real cases to be made that Rust can be substantially better than the alternatives; Can prevent logical UAF with borrowing, bound checks may be mostly elided, enforced language level checks for nullability like Option and valid values in general like enums, explici…
That said, your concerns are pretty valid, widely echoed and are being taken seriously. Writing unsafe code is a chore and it needn't be. I'm hoping the newly created Operational Semantics team (https://www.rust-lang.org/governance/teams/lang#Operational%...) makes progress here.
Earlier quoted context omitted.
As long as you don't care about UB or edge cases. Every time Rust makes something hard, it's forcing you to handle an edge case up front.
It's blowing my mind how many commenters here don't understand this. Rust isn't hard just for fun. It's hard because the code you've been writing for so long is actually bad and you've not been thinking it through appropriately. This is why we keep finding serious bugs in code that is decades-old, despite the belief that code so old must be well-tested by now.
Earlier quoted context omitted.
I suspect the things that people are reacting to are a mixture of the following: * Types in Rust use prefixing to create derived types whereas C family languages generally use postfixing. A pointer is i32, not int ; an array [i32; 5], not int[5], etc. This makes special characters appear more heavily at the beginning of the scan line, and probably makes them slightly more noticeable as a result. * Lifetimes have the…
> * Passing in explicit generic type arguments for a function requires an extra :: for seemingly no reason. There is a very good reason for this. Behold, the Bastion of the Turbofish. https://github.com/rust-lang/rust/blob/master/tests/ui/parse...
Earlier quoted context omitted.
C or C++ threads on HN are often not about something great. Recend thread on SHA-3 vulnerabilities as example [0]. If security standards providers fail to write secure C code where does this put average Joe? I mean the whole 'pride' threads of people who 'enjoy writing C' or C++ look as strange on HN as Rust brigading. Its funny how there is no C or C++ pride thread on a day when vulnerabilities hit frontpage. PS. I…
You're arguing straw men rather than engaging in the points being made. Virtually every thread means both positive, neutral, and negative stories. Something about Rust makes people feel justified bullying people supporting their families laboring in C or C++ codebases. No other language community has this. The other fallacy is equating laboring with pridefulness. I never said anything about pride. Most C and C++ prog…
What I wanted to say is there are many threads on HN where people who 'aware of problems' do not write and people who are 'having fun writing' code gather in hundreds. These threads are equally bad in my opinion as ones you call 'bullying'. I wish HN would discuss improvements in both C and C++ at the same time with improvements in Rust ecosystem without mixing it up but I understand why it gets mixed.
Earlier quoted context omitted.
Difference of course being that zero of these bugs will be due to buffer overflows or use after free or other memory bugs in safe rust, which is a huge source of bugs in C[1]. I don't understand why this argument keeps coming up. Not all bugs are the same and when you make entire classes of bugs unrepresentable, that's a massive win, especially when they happen to be the class containing >60% of the highest severity…
> zero of these bugs will be due to buffer overflows or use after free or other memory bugs in safe rust buffer overflows [0] [1], use after frees [2] [3], and other memory bugs [4] [5] [6] can appear in safe rust from unsound unsafe internals. [0] https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-2887... [1] https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-1000... [2] https://cve.mitre.org/cgi-bin/cvena…
My point wasn't that rust is bug-free, but that certain classes of bugs will not exist in the safe portion, which significantly reduces attack surface.
Additionally, my point was to compare languages without safety guarantees like C to safe rust. Your statement is true, but it doesn't do anything to counter what I'm saying, which is that entire classes of bugs (namely the most common critical c bugs) are not found in safe rust, which is still the case.
Worded another way, within the boundaries of safe rust, you will not find a cause of a memory corruption bug. Things that can be the cause memory bugs include: unsound unsafe rust, c, kernel-level manipulation, random bit flips, malicious hardware, etc etc. I consider none of those to be bugs in safe rust, and additionally, they can cause bugs in all other programming languages as well.
Earlier quoted context omitted.
Difference of course being that zero of these bugs will be due to buffer overflows or use after free or other memory bugs in safe rust, which is a huge source of bugs in C[1]. I don't understand why this argument keeps coming up. Not all bugs are the same and when you make entire classes of bugs unrepresentable, that's a massive win, especially when they happen to be the class containing >60% of the highest severity…
It’s not that simple. Rust is used in the system’s programming space and as a result it will be used in many places where unsafe ends up required to solve problems. There won’t be memory safety bugs in safe Rust, but there will be in the interop/unsafe layers. I think there is a strong argument to be made that if you need a lot of unsafe, Zig is going to be the safer language.
I could see that. Haven't used zig but it does look very nice.
> in many places where unsafe ends up required
Yes, I definitely agree. I was specifically referring to the boundary of safe rust. I don't know how much more or less safe unsafe rust is vs c, but I do know that safe rust is certainly safer than c.
Earlier quoted context omitted.
So useless that Linux, gcc, and all UNIX system commands is written in C. But you're probably doing much more important things, right?
We should definitely appreciate the craftsmanship. This comment says everything, regardless of how trendy Rust might be, let’s respect the craft, your favourite language doesn’t make you more important. Legends!