4 ms·

>> I just do not see why people seem to use "unsafe" so much >Because it’s impossible to implement any non-trivial data structures in safe Rust. Even Vec has u

>> I just do not see why people seem to use "unsafe" so much >Because it’s impossible to implement any non-trivial data structures in safe Rust. Even Vec has unsafe code Hmm.. wasn't memory safety the main selling point for rust? If not the only. Now mix of two languages looks even worst than one complex. Especially taking into account that it can be paired with safe language from long list. Don't know what rust fans are thinking, but from outside it doesn't look very attractive. Definitely not enough to make a switch. Julia looked better at first, but turned out to be just a graveyard of abandoned academic projects.

eddd-ddde 2y ago
You fan wrap unsafe implementations with safe APIs. The point is there's an explicit boundary between unsafe an safe.
pcwalton 2y ago
> Now mix of two languages looks even worst than one complex. The point is that the vast majority of code doesn't have to be unsafe. Empirically, Rust code has far fewer memory safety problems than non-memory-safe languages.
deleted 2y ago
[deleted]
TheRoque 2y ago
Memory safety without gc is not the only reason people use rust. It's also nicer to use than C++ for multiple reasons (language features, included package manager, easy to integrate tests...)
- guappa 2y ago
  I use Qt, and I think if you have the Qt libraries then C++ is way better than rust. Most things are there instead of having to go and find a crate and then decide which one to use and hope it will remain maintained.
okanat 2y ago
Nope it isn't. You just aren't experienced in system programming. Working with hardware is unsafe since it has state that one cannot completely encapsulate in a single program. The entire specific design of a chip isn't available to programmer; only the machine code is. We usually don't know how a processor decides to cache things or switch to kernel permission level. Usually this isn't even the level we're at, OSes have private internals that change behind the programs and they are not accessible from user space. Pressing Ctrl+C to interrupt changes so many things in memory, it would be outright impossible to write programs that handle every single thing. The fundamental / syntactic promise of Rust is providing mechanisms to handle and encapsulate unsafety such that it is possible to construct a set of libraries that handle the unsafety in designated places. Therefore the rest of the program can be mathematically proven to be safe. Only the unsafe parts can be unsafe. Coming from Java or Go or Js or Python angle wouldn't be the same. Those languages don't come with mechanisms to let you to make system calls directly or handle the precise memory structure of the data which is necessary when one is communicating with hardware or the OS or just wants to have an acceptable amount of performance. In C++, the compiler can literally remove your code if you sum or multiply integers wrong or assume the char is signed/unsigned. There is no designated syntax that limits the places possible memory overflow error happen. The design of the language is such that some most trivial oversight can break your program silently and significantly. It is too broad so it is not possible to create a safe and mathematically proven and performant subset with the C and C++ syntax. It is possible with Rust. It is like the difference of chips that didn't have a hardware mechanism to switch between user and kernel mode so everything was simply "all programs should behave well and no writes to other programs' memory pinky promise". Rust doesn't leave this just as a possibility. Its standard library is mostly safe and one can already write completely safe and useful utilities with the standard library. The purpose of the standard library is provide you ways to avoid unsafe as much as possible. Of course more hardware access or extremely efficient implementations would require unsafe. However again, only the unsafe parts can cause safety bugs. They are much easier to find and debug compared to C++. People write libraries for encapsulating unsafe so there are even less places that use unsafe. If people are out of their C++ habit, reaching for the big unsafe stick way too often, then they are using Rust wrong. Whatever you do, there will be always a need for people and software that enables a certain hardware mode, multiply matrices fast, allocates a part of display for rendering a window etc. We can encapsulate the critical parts of those operations with unsafe and the rest of the business logic can be safe.
School-Cotton 2y ago
> Hmm.. wasn't memory safety the main selling point for rust? The vast majority of Rust programmers aren't spending their time re-implementing core data structures like Vec, so memory safety (and the fact that library authors can build safe abstractions on top of unsafe code, which is impossible in C or C++) still benefits them.

eddd-ddde 2y ago

You fan wrap unsafe implementations with safe APIs. The point is there's an explicit boundary between unsafe an safe.

pcwalton 2y ago

> Now mix of two languages looks even worst than one complex. The point is that the vast majority of code doesn't have to be unsafe. Empirically, Rust code has far fewer memory safety problems than non-memory-safe languages.

deleted 2y ago

[deleted]

TheRoque 2y ago

Memory safety without gc is not the only reason people use rust. It's also nicer to use than C++ for multiple reasons (language features, included package manager, easy to integrate tests...)

guappa 2y ago
I use Qt, and I think if you have the Qt libraries then C++ is way better than rust. Most things are there instead of having to go and find a crate and then decide which one to use and hope it will remain maintained.

okanat 2y ago

Nope it isn't. You just aren't experienced in system programming. Working with hardware is unsafe since it has state that one cannot completely encapsulate in a single program. The entire specific design of a chip isn't available to programmer; only the machine code is. We usually don't know how a processor decides to cache things or switch to kernel permission level. Usually this isn't even the level we're at, OSes have private internals that change behind the programs and they are not accessible from user space. Pressing Ctrl+C to interrupt changes so many things in memory, it would be outright impossible to write programs that handle every single thing. The fundamental / syntactic promise of Rust is providing mechanisms to handle and encapsulate unsafety such that it is possible to construct a set of libraries that handle the unsafety in designated places. Therefore the rest of the program can be mathematically proven to be safe. Only the unsafe parts can be unsafe. Coming from Java or Go or Js or Python angle wouldn't be the same. Those languages don't come with mechanisms to let you to make system calls directly or handle the precise memory structure of the data which is necessary when one is communicating with hardware or the OS or just wants to have an acceptable amount of performance. In C++, the compiler can literally remove your code if you sum or multiply integers wrong or assume the char is signed/unsigned. There is no designated syntax that limits the places possible memory overflow error happen. The design of the language is such that some most trivial oversight can break your program silently and significantly. It is too broad so it is not possible to create a safe and mathematically proven and performant subset with the C and C++ syntax. It is possible with Rust. It is like the difference of chips that didn't have a hardware mechanism to switch between user and kernel mode so everything was simply "all programs should behave well and no writes to other programs' memory pinky promise". Rust doesn't leave this just as a possibility. Its standard library is mostly safe and one can already write completely safe and useful utilities with the standard library. The purpose of the standard library is provide you ways to avoid unsafe as much as possible. Of course more hardware access or extremely efficient implementations would require unsafe. However again, only the unsafe parts can cause safety bugs. They are much easier to find and debug compared to C++. People write libraries for encapsulating unsafe so there are even less places that use unsafe. If people are out of their C++ habit, reaching for the big unsafe stick way too often, then they are using Rust wrong. Whatever you do, there will be always a need for people and software that enables a certain hardware mode, multiply matrices fast, allocates a part of display for rendering a window etc. We can encapsulate the critical parts of those operations with unsafe and the rest of the business logic can be safe.

School-Cotton 2y ago

> Hmm.. wasn't memory safety the main selling point for rust? The vast majority of Rust programmers aren't spending their time re-implementing core data structures like Vec, so memory safety (and the fact that library authors can build safe abstractions on top of unsafe code, which is impossible in C or C++) still benefits them.