6 ms·
> Coding it in Rust does not, in fact, guarantee it is correct. Of course. > Coding C++, you need only choose known-correct primitives to get the same level o
by Diggsey 4y ago
> Coding it in Rust does not, in fact, guarantee it is correct.
Of course.
> Coding C++, you need only choose known-correct primitives to get the same level of assurance.
C++ does not even have the means to express "known-correct" primitives. The compiler will not tell you if you accidentally access a non-thread-safe type from another thread. It will not tell you if you accidentally resize a vector while having an outstanding reference to one of its elements. These are not "bad primitives" you can blame - getting this stuff right requires higher-level reasoning which the C++ compiler cannot do for you, and the Rust compiler can.
> is exactly as safe as Rust eBPF, but likely less annoying to code.
Personally I find C++ far more annoying to code. I mean header files... In 2022? Text based macros? No standardised way to manage dependencies?
- ncmncm 4y ago
- davidatbu 4y agoWhat about this part "the compiler will not tell you if you accidentally access a non-thread-safe type from another thread"?
- ncmncm 4y ago
- davidatbu 4y agoThanks! Could you point me to the C++ primitives that prevent cross-thread access of non-thread-safe data? I'd honestly love to learn about this. If it's not asking too much, could you also point me to the C++ primitives that prevent dangling pointers as well? EDIT: Also, the primitives that prevents the mutation of what a const reference refers to? (Much in the way that shared references and exclusive references can't co-exist in Rust)? I'd hope the C++ primitives for the above all perform their job at compile time of course.
- jdright 4y agoHe can't because he doesn't understand what you're asking.
- davidatbu 4y agoTbh, I'm also a Rust beginner and know even less about C++, so I'm sincerely trying to learn here.
- Filligree 4y agoC++ doesn’t provide any of the checks being talked about here. There’s nothing much to learn; they just don’t exist.
- davidatbu 4y agoThank you! Still waiting on you @ncmncm, if you think differently.
- ncmncm 4y agoIf you can see it at all, it will be an atomic type.
- davidatbu 4y agoI skimmed docs for std::atomic, and I believe what you're suggesting is a super-brief version of what was outlined here[0]. If so, thanks! Through I don't yet "see it" that C++ has safety primitives that "equal" that of Rust's, I've learnt a lot about C++'s safety features from other folks' replies in this thread. So again, thanks! [0] https://news.ycombinator.com/reply?id=32824168 https://news.ycombinator.com/reply?id=32824168
- ncmncm 4y agoTrolling is unwelcome here.
- sophacles 4y agoWhy not provide some sort of useful statement of how a lack of compiler checked memory access provides compiler checked memory safety? To quote you: Trolling is unwelcome here.
- seabrookmx 4y agoFrom hackernews guidelines: > Comments should get more thoughtful and substantive, not less, as a topic gets more divisive. > Please don't post shallow dismissals If you have a real rebuttal, add it. Otherwise don't bother commenting.
- tialaramex 4y ago> Hint: use of std::vector would not appear in kernel code, in any case. They didn't ask for std::vector, just for a vector, which in this context is any extensible array type. So that seems like a disadvantage straight away. Rust for Linux provides Vec like your userspace Rust code. Of course, the alloc::Vec in Rust for Linux doesn't have yolo-allocation, if you want space for 615 items in your Vec you will need Vec::try_with_capacity(615) rather than Vec::with_capacity(615) because you must decide what to do if the allocation fails, and if you want to push an item you'll need to try_push(item) not just push_item) for the same reason as the Vec might be full and unable to grow. Rust's usual promises hold up though, if I try to Vec::truncate() a Vec I need to provide a mutable reference to the Vec (&mut self) and Rust won't give me one of those while I still have outstanding references, even immutable ones, to that Vec, my code won't compile.
- selfmodruntime 4y agoThe module system in CPP is dead on arrival. Almost no libraries and build systems support them. Modules still produce bad output on gcc.
- mathstuf 4y agoIt is being worked on (at the build system level). Even so, I don't think Linux would support modules because it'd require some…unfortunate behaviors to support in `make`, namely at least one recursive make level. Though if `gmake` is assumed, there is `libcody` support that's in a patch that can do it without recursive `make` at the expense of having an unknown number of outstanding compilation processes open waiting to figure out what their topological order is at build time. I do not know what the behavior of such a solution is in the presence of import cycles or unsatisfied imports, but that's also why I prefer the "scanning" solution. FD: CMake developer working on C++ modules support.
- throwaway894345 4y ago> Personally I find C++ far more annoying to code. I mean header files... In 2022? Text based macros? No standardised way to manage dependencies? Yep. This is basically why I switched to Rust from C++, but I stayed for the coherent language design, the rapid pace of improvement, and the borrow checker.