4 ms·
Alright, thanks for clearing that up. I missed those in the documentation, since it doesn’t specify any of this directly. Though, still wide registers aren’t a
by dreta 10y ago
Alright, thanks for clearing that up. I missed those in the documentation, since it doesn’t specify any of this directly.
Though, still wide registers aren’t a language feature. I don’t care, nor do i think any other seasoned programmer does, about the language “freeing me from the need to deal with raw memory”. It doesn’t. The types of problems you solve by introducing built-in string types and vectors aren’t problems in the first place. The problem is writing custom allocators for the data you have, and needing some basic bounds checking. Problem is working with structures of arrays instead of arrays of structures, because that can get messy and introduce basic typing bugs. I’d love to see any modern programming language at least make an attempt at making working with raw memory easier.
- pcwalton 10y ago> I don’t care, nor do i think any other seasoned programmer does, about the language “freeing me from the need to deal with raw memory”. I do. Am I a bad programmer? > The types of problems you solve by introducing built-in string types and vectors aren’t problems in the first place. Buffer overflows aren't problems?
- dreta 10y agoI’m not saying you’re bad. I’m saying there’s always a point where you want to go down to managing your own memory when performance is an issue, and no amount of language features is going to change that. What i’d want is a generic support for preventing buffer overflows, or bad memory access where i need it. Writing my own growable data type using malloc and free is something i can do once, and i just have it, it’s not something that i have to worry about for more than 5 minutes at the beginning of a project.
- pjmlp 10y agoNot everyone has the privilege to be a single C coder owning the code without anyone else from different skill levels coding in it and without any additional use of third party libraries.
- dbaupp 10y ago> What i’d want is a generic support for preventing buffer overflows, or bad memory access where i need it You have that. For example, if you have contiguous memory, the various forms of the [T] slice type can be used, they don't impose any allocation expectations. (And, once the standard library allows pluggable allocators, you'll likely be able to use Vec directly, for a growable vector type.) If you don't have contiguous memory, then it's a bit more work, but one can still use features like generics and privacy to spend a few lines building abstractions that bounds check in the right places. It's not like using a proof language to extract a program that is guaranteed to have no out of bounds accesses, or a compiler that some how deduces what the bounds of your data structure is, but the former has its own complexity downsides, and the latter seems infeasible, in general.
- dreta 10y agoNone of the things you mentioned, other than the slice type, which i don’t see how it would work on raw memory, are a language feature.
- dbaupp 10y agoAs I said, a slice can point to any memory, it doesn't matter where it came from: i.e. your allocator/things using it can expose slices instead of just plain pointers. Generics and privacy are definitely language features, and they're core to the ease with which one can create abstractions. Rust is a systems language, it tries to give programmers the power to create their own safe abstractions as needed.
- dreta 10y agoI wasn't talking about that. What i meant was, if i have to implement it myself, that's not a point in favor of Rust. Though the slice does help with rudimentary bounds checking, so that's a start, though i don't see how that differs from a generic accessor method or an overloaded operator.
- dbaupp 10y ago
- xenadu02 10y agoClearly you haven't done even basic research into Rust. That's OK, but I don't think you should be spouting off in HN comments about how useless it is. Rust is all about memory safety. The borrow checker gives you compile-time memory safety guarantees (sans unsafe blocks). The address of the struct you passed to some function which then took the address of an inner field and populated a value in a returned object? Yeah... Rust knows whether that's safe or you've set yourself up for a dangling pointer. Bounds-checking is child's play to Rust. The bulk (if not the majority) of high-impact security vulnerabilities are related to memory safety in some form. Rust eliminates those as an entire class of problem.
- dreta 10y agoI went through all the Rust features. It doesn’t eliminate memory safety issues at all.
- dbaupp 10y agoWhat's a specific memory safety issue Rust has outside `unsafe` code?
- dreta 10y agoThe memory safety issues happen inside of “unsafe” code, thus it doesn’t eliminate memory safety issues.
- dbaupp 10y agoI don't think this is a useful point, because by the same logic: - Haskell doesn't eliminate memory safety issues, they happen when using unsafePerformIO (or Foreign.*Ptr, or inside the runtime, your choice), - Python doesn't eliminate memory safety issues, they happen when using ctypes, - JavaScript doesn't eliminate memory safety issues, they happen when calling into the C++ code of the browser, - Java doesn't eliminate memory safety issues, they happen when using JNI. All languages have some sort of escape hatch that can be used to drop to a lower level, in order to actually interface with the operating system (etc.), Rust is slightly unique in that it makes this escape hatch fairly explicit/prominent at the language level and also provides the power needed do that interfacing/implementation itself (additionally, one gets all the normal benefits of Rust inside `unsafe`, the feature just lets one do more, not change the semantics of existing code).