3 ms·

Isn't it, independently of that argument ("more eyeballs"), unavoidable to use unsafe code to efficiently implement the new algorithms, new efficient container

by acqq 10y ago

Isn't it, independently of that argument ("more eyeballs"), unavoidable to use unsafe code to efficiently implement the new algorithms, new efficient containers or efficient numerical processing? (And why is there a need to "defend" the idea that it isn't? I already pointed to my answer to that in my topmost post.) Edit: to answer ""unavoidable" is a very strong statement" from the answer of this post: how could the very presence of "unsafe" parts exactly in the code written by the most informed programmers of that language be otherwise explained? I can't imagine anything more representative than the compiler and the libraries, except for the numerical algorithms, which are typically not included in the libraries of a lot of languages.

steveklabnik 10y ago
> unavoidable It's not possible to tell, this question is far too broad. And "unavoidable" is a very strong statement. > And why is there a need to "defend" the idea that it isn't? I'm not; I'm saying that the rust-lang/rust repo is going to have a much higher percentage of unsafe than a random Rust repo. Most applications have no unsafe, most libraries have little to no unsafe. Some libraries have a lot of unsafe. That is, you chose the compiler as something intended to be representative, I don't think that's accurate.
- AsyncAwait 10y ago
  The way I originally meant the "unavoidable", (in response to a comment that there's unsafe code in the Rust compiler), is that in some cases, you'll always need unsafe, since some operations are inherently unsafe, (like writing bytes directly to hardware). This due to the nature of computers, the lower level the code gets, the more likely it is that some unsafe will be needed, not because of any fault of Rust, but because of the nature of computer hardware. Therefore I meant it as in; since a compiler is relatively low-level project, some unsafe code is (most likely) unavoidable, due to the task at hand. The other poster seemed to take the unavoidable comment to mean something wider than what I was talking about.
steveklabnik 10y ago
> ... be otherwise explained? A few things: you asked about it being unavoidable. Remember, the rust compiler and standard library is a near decade long project evolving extremely rapidly. This means that many things in the compiler aren't exactly done the best possible way as if you wrote things from scratch today. The standard library is shaping up. But a _lot_ of time and effort has been put in towards modernizing things. Years of your language changing as you implement your language is a recipe for lots of tech debt. Furthermore, you asked about a lot of stuff that's _not_ in the standard library too, so it's not clear that pointing at the standard library is a good way to demonstrate how those things are developed as well. And while we have developed a decent set of stuff in the standard library for these cases, it's not like stuff just gets added anymore, either. So, lots of reasons.
- acqq 10y ago
  Strange: the changes in the C++ compiler were typically done to allow better standard libraries, and here is implied that it's hard for the libraries to use the language improvements as the Rust compiler gets better, and that they would otherwise use significantly less "unsafe" parts... I'd have to see some examples to be convinced.
  - steveklabnik 10y ago
    I'm not implying that it's hard in a clean-room sense, I'm implying that changing things over time means you might end up with different code than if you did it clean-room today. The interfaces matter a lot more than the implementations; we spent a lot of focus on the actual interfaces, stabilized them, and internal improvements are always landing.

by acqq 10y ago

steveklabnik 10y ago

> unavoidable It's not possible to tell, this question is far too broad. And "unavoidable" is a very strong statement. > And why is there a need to "defend" the idea that it isn't? I'm not; I'm saying that the rust-lang/rust repo is going to have a much higher percentage of unsafe than a random Rust repo. Most applications have no unsafe, most libraries have little to no unsafe. Some libraries have a lot of unsafe. That is, you chose the compiler as something intended to be representative, I don't think that's accurate.

AsyncAwait 10y ago
The way I originally meant the "unavoidable", (in response to a comment that there's unsafe code in the Rust compiler), is that in some cases, you'll always need unsafe, since some operations are inherently unsafe, (like writing bytes directly to hardware). This due to the nature of computers, the lower level the code gets, the more likely it is that some unsafe will be needed, not because of any fault of Rust, but because of the nature of computer hardware. Therefore I meant it as in; since a compiler is relatively low-level project, some unsafe code is (most likely) unavoidable, due to the task at hand. The other poster seemed to take the unavoidable comment to mean something wider than what I was talking about.

steveklabnik 10y ago

> ... be otherwise explained? A few things: you asked about it being unavoidable. Remember, the rust compiler and standard library is a near decade long project evolving extremely rapidly. This means that many things in the compiler aren't exactly done the best possible way as if you wrote things from scratch today. The standard library is shaping up. But a _lot_ of time and effort has been put in towards modernizing things. Years of your language changing as you implement your language is a recipe for lots of tech debt. Furthermore, you asked about a lot of stuff that's _not_ in the standard library too, so it's not clear that pointing at the standard library is a good way to demonstrate how those things are developed as well. And while we have developed a decent set of stuff in the standard library for these cases, it's not like stuff just gets added anymore, either. So, lots of reasons.

acqq 10y ago
Strange: the changes in the C++ compiler were typically done to allow better standard libraries, and here is implied that it's hard for the libraries to use the language improvements as the Rust compiler gets better, and that they would otherwise use significantly less "unsafe" parts... I'd have to see some examples to be convinced.
- steveklabnik 10y ago
  I'm not implying that it's hard in a clean-room sense, I'm implying that changing things over time means you might end up with different code than if you did it clean-room today. The interfaces matter a lot more than the implementations; we spent a lot of focus on the actual interfaces, stabilized them, and internal improvements are always landing.