4 ms·

Yep, and its pretty much going to become the next C++ - i.e widely adopted at first, and driven into a shit state. Specifically because of this https://doc.rus

Yep, and its pretty much going to become the next C++ - i.e widely adopted at first, and driven into a shit state. Specifically because of this https://doc.rust-lang.org/book/ch19-01-unsafe-rust.html https://doc.rust-lang.org/book/ch19-01-unsafe-rust.html This needs to exist in Rust for it to get adopted, because forcing good developers to get explicit with code for memory safety when they are doing simple operations is going to result in them ignoring the language. So eventually code bases are going to be exactly like C++ code bases - C++ has a standard library and smart pointers that eliminate a lot of errors with dangling pointers, and if people use those exclusively (or better yet, the language disallowed any C style pointers or arrays), the language would be dramatically more safe. If you want to improve development, focus on smarter compilers/interpreters, not languages.

gary17the 4y ago
Being "explicit with code for memory safety [even for] simple operations" is the whole point of Rust. Otherwise, sooner or later, as a codebase grows, you make mistakes that your compiler cannot catch (e.g., you give an immutable reference to a component and later on unexpectedly mutate that same referenced memory from under that component). > [Rust] [will be] driven into a shit state. Specifically because of [unsafe Rust] Using unsafe Rust is actually frowned upon in the Rust community, unless you specifically need it in order to interface with another programming language (e.g., Foreign Function Interface), work around some OS issue (e.g., memory pinning for Linux driver development) and so on. Otherwise, you are supposed to always write safe Rust code. Way more than unsafe Rust, what worries me is the potential future, long-term language feature bloat. I wholeheartedly do hope that Rust core team will keep the language as simple and consistent as humanly possible. > If you want to improve development, focus on smarter compilers/interpreters, not languages. Well, in order to get a smarter compiler, you need new language features to be able to feed additional information about programmer's intent into that compiler - hence Rust's new language features, for example (memory reference) lifetime annotations that all newcomers have a problem with :).
- ActorNightly 4y ago
  Rust community can't control what happens in enterprise, and enterprise has a nasty habit of prioritizing delivery times over robustness. >Well, in order to get a smarter compiler, you need new language features to be able to feed additional information about programmer's intent into that compiler Yes and no. There are some things you want to specify for compiler to check, but a lot of behavior can be inferred from the code. Think about some backend server functionality for a website that has to do processing on some json data. You could take that code in python and write absolutely safe C code, and the process to translate it wouldn't be that hard.
int_19h 4y ago
This needs to exist in order for the Rust standard library to be written in Rust.
dureuill 4y ago
> C++ has a standard library and smart pointers that eliminate a lot of errors with dangling pointers, and if people use those exclusively You can't use smart pointers exclusively, because there is no "smart observational pointer", and there cannot be one, because that would be a reference type checked by a borrow checker, which is exactly what rust uses. You can emulate it with shared pointers, but then you're left with basically a reference counted language. Why not using swift at this point? Also this creates a semantic impedance mismatch that tends to manifest with cycles. Source: walked a codebase that would (ab)use shared pointers
- ActorNightly 4y ago
  The point is you can still write memory safe code and avoid all the double free and user after free bugs if you just use smart pointers correctly and standard namespace constructs. You can be extra safe and use unique pointers and transfer ownership. Sure, there are some things that Rust makes nice, like compile time checking for errors, however with C++ codebases, they will just result in runtime errors rather than usable exploits.
cercatrova 4y ago
> focus on smarter compilers/interpreters, not languages That's...exactly what Rust is doing with their compiler, which checks ownership and lifetimes, so I don't understand your point here. Maybe they didn't need to write a whole new language, but why not add modern features like pattern matching along the way?

gary17the 4y ago

Being "explicit with code for memory safety [even for] simple operations" is the whole point of Rust. Otherwise, sooner or later, as a codebase grows, you make mistakes that your compiler cannot catch (e.g., you give an immutable reference to a component and later on unexpectedly mutate that same referenced memory from under that component). > [Rust] [will be] driven into a shit state. Specifically because of [unsafe Rust] Using unsafe Rust is actually frowned upon in the Rust community, unless you specifically need it in order to interface with another programming language (e.g., Foreign Function Interface), work around some OS issue (e.g., memory pinning for Linux driver development) and so on. Otherwise, you are supposed to always write safe Rust code. Way more than unsafe Rust, what worries me is the potential future, long-term language feature bloat. I wholeheartedly do hope that Rust core team will keep the language as simple and consistent as humanly possible. > If you want to improve development, focus on smarter compilers/interpreters, not languages. Well, in order to get a smarter compiler, you need new language features to be able to feed additional information about programmer's intent into that compiler - hence Rust's new language features, for example (memory reference) lifetime annotations that all newcomers have a problem with :).

ActorNightly 4y ago
Rust community can't control what happens in enterprise, and enterprise has a nasty habit of prioritizing delivery times over robustness. >Well, in order to get a smarter compiler, you need new language features to be able to feed additional information about programmer's intent into that compiler Yes and no. There are some things you want to specify for compiler to check, but a lot of behavior can be inferred from the code. Think about some backend server functionality for a website that has to do processing on some json data. You could take that code in python and write absolutely safe C code, and the process to translate it wouldn't be that hard.

int_19h 4y ago

This needs to exist in order for the Rust standard library to be written in Rust.

dureuill 4y ago

> C++ has a standard library and smart pointers that eliminate a lot of errors with dangling pointers, and if people use those exclusively You can't use smart pointers exclusively, because there is no "smart observational pointer", and there cannot be one, because that would be a reference type checked by a borrow checker, which is exactly what rust uses. You can emulate it with shared pointers, but then you're left with basically a reference counted language. Why not using swift at this point? Also this creates a semantic impedance mismatch that tends to manifest with cycles. Source: walked a codebase that would (ab)use shared pointers

ActorNightly 4y ago
The point is you can still write memory safe code and avoid all the double free and user after free bugs if you just use smart pointers correctly and standard namespace constructs. You can be extra safe and use unique pointers and transfer ownership. Sure, there are some things that Rust makes nice, like compile time checking for errors, however with C++ codebases, they will just result in runtime errors rather than usable exploits.

cercatrova 4y ago

> focus on smarter compilers/interpreters, not languages That's...exactly what Rust is doing with their compiler, which checks ownership and lifetimes, so I don't understand your point here. Maybe they didn't need to write a whole new language, but why not add modern features like pattern matching along the way?