51–60 of 131 posts
Earlier quoted context omitted.
I went through all the Rust features. It doesn’t eliminate memory safety issues at all.
What's a specific memory safety issue Rust has outside `unsafe` code?
Earlier quoted context omitted.
You've never hit a NPE or null pointer? Data races or use after free? Const is nothing like references, not even close. I would suggest you spend a bit more time with the language to better understand exactly what Rust brings to the table.
The number of cases where i have to use a generic memory allocator like malloc in a typical project are extremely rare, so no. I never said that const is like anything, i just used it as an example.
In fact, "how to to either of these things" is such a common question for new rust programmers trying to solve their borrow checker complaints that it constitutes pretty good evidence people are doing these things all the time with little understanding of why they are problematic.
And even if you _do_ know better, circumventing the borrow checker is fairly trivial.
Earlier quoted context omitted.
> 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 con…
None 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.
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.
Earlier quoted context omitted.
> 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 con…
None 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.
We actually used to implement Vec as a language feature, and it was a lot of work to write things like growth in raw LLVM IR (which is a miserable programming language) instead of just using a real programming language—Rust—to do it.
Earlier quoted context omitted.
What's a specific memory safety issue Rust has outside `unsafe` code?
The memory safety issues happen inside of “unsafe” code, thus it doesn’t eliminate memory safety issues.
- 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).
Earlier quoted context omitted.
I'm sorry, I have plenty of gripes about the Rust team touting safety as much as they do but your comment just misses the mark, in my opinion. To begin with, "safety" isn't solved by just using const. It simply isn't feasible to write safe code in C without restricted feature usage to the point of being crippled. It's much easier in C++, but requires an incredible level of focus and "cruft constructs" like ' 'const &…
My point was that i haven’t come across a Rust feature i felt would save me from creating a bug.
Earlier quoted context omitted.
The memory safety issues happen inside of “unsafe” code, thus it doesn’t eliminate memory safety issues.
I 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 elim…
Earlier quoted context omitted.
None 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.
Why would it be safer to implement Vec as a "language feature" as opposed to implementing it in the library? We actually used to implement Vec as a language feature, and it was a lot of work to write things like growth in raw LLVM IR (which is a miserable programming language) instead of just using a real programming language—Rust—to do it.
I cannot wait. I cannot wait until this happens. Rust will become my main language.
Earlier quoted context omitted.
None 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.
As 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.