Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The Rust Libs Blitz

blog.rust-lang.org

Post reply on HN
Print view View original

21–30 of 125 posts

Re: The Rust Libs Blitz

#21

Post by Animats »

eridius wrote: post #15
Animats wrote: post #9

Does the "Rust standard of quality" for these crucial crates include "no unsafe code"? "Vec" currently needs unsafe code, because Rust doesn't have the expressive power to talk about a partially initialized array. Everything else with unsafe code is an optimization. Often a premature one. Maps should be built on "Vec", for example.

Why do you say premature? Maps, for example, being such a crucial and widely-used data type, should be optimized as much as possible. There's nothing premature about using `unsafe` to build a highly-efficient Map.

Let's see the benchmarks justifying the use of "unsafe" for maps. Maybe there's a better way to do it without much of a performance penalty. It's a good way to find out what optimizations the compiler is missing. It may even turn out that unsafe code written early no longer is a performance win, since the Rust compiler is getting better at optimizing out redundant subscript checks.

When you start looking through Rust libraries, "unsafe" turns up way too often.

Re: The Rust Libs Blitz

#22

Post by epage »

Animats wrote: post #9

Does the "Rust standard of quality" for these crucial crates include "no unsafe code"? "Vec" currently needs unsafe code, because Rust doesn't have the expressive power to talk about a partially initialized array. Everything else with unsafe code is an optimization. Often a premature one. Maps should be built on "Vec", for example.

I suspect removing unsafe is outside of the scope of Rust.

Rust tries to help you as much as possible but recognizes that it sometimes gets in the way and provides an escape hatch. The idea is to minimize and abstract the use of the escape hatch so its easily auditable.

I wish they hadn't named the escape hatch "unsafe". I think I heard the name came from PL theory but it makes it sound scarier than it is.

I remember hearing something about wanting to improve documentation around unsafe for how to best use it without running into problems.

Re: The Rust Libs Blitz

#23

Post by eximius »

Animats wrote: post #9

Does the "Rust standard of quality" for these crucial crates include "no unsafe code"? "Vec" currently needs unsafe code, because Rust doesn't have the expressive power to talk about a partially initialized array. Everything else with unsafe code is an optimization. Often a premature one. Maps should be built on "Vec", for example.

In Rust, 'unsafe code' is really 'partially compiler check exempt'. It does not mean the code is unsafe. You can manually verify the 'unsafe' parts.

It is very unfortunately named.

Re: The Rust Libs Blitz

#24

Post by Manishearth »

Animats wrote: post #21
eridius wrote: post #15

Earlier quoted context omitted.

Why do you say premature? Maps, for example, being such a crucial and widely-used data type, should be optimized as much as possible. There's nothing premature about using `unsafe` to build a highly-efficient Map.

Let's see the benchmarks justifying the use of "unsafe" for maps. Maybe there's a better way to do it without much of a performance penalty. It's a good way to find out what optimizations the compiler is missing. It may even turn out that unsafe code written early no longer is a performance win, since the Rust compiler is getting better at optimizing out redundant subscript checks. When you start looking through Rust…

(The hashmap that is used in the winning rust benchmarksgame entry is 100% safe, fwiw)

> When you start looking through Rust libraries, "unsafe" turns up way too often.

You keep making this claim without substantiation. Yes, there is some level of unnecessary unsafe, but certainly not "way too often". I recall going through all the crates in my .cargo and finding very little unnecessary unsafe, and showing you the audit: https://news.ycombinator.com/item?id=13280347

Please stop throwing around this claim without substantiation.

Re: The Rust Libs Blitz

#25

Post by Manishearth »

epage wrote: post #22
Animats wrote: post #9

Does the "Rust standard of quality" for these crucial crates include "no unsafe code"? "Vec" currently needs unsafe code, because Rust doesn't have the expressive power to talk about a partially initialized array. Everything else with unsafe code is an optimization. Often a premature one. Maps should be built on "Vec", for example.

I suspect removing unsafe is outside of the scope of Rust. Rust tries to help you as much as possible but recognizes that it sometimes gets in the way and provides an escape hatch. The idea is to minimize and abstract the use of the escape hatch so its easily auditable. I wish they hadn't named the escape hatch "unsafe". I think I heard the name came from PL theory but it makes it sound scarier than it is. I remember…

IMO it's good that it's scarier than it actually is :)

http://doc.rust-lang.org/doc/stable/nomicon/ is the documentation for unsafe. I do plan on improving it heavily, but I'm very busy right now, and I'd like to wait for some of the unsafe semantics stuff to be pinned down so that I can go in full depth when I write this.

Re: The Rust Libs Blitz

#26

Post by lmkg »

Animats wrote: post #9

Does the "Rust standard of quality" for these crucial crates include "no unsafe code"? "Vec" currently needs unsafe code, because Rust doesn't have the expressive power to talk about a partially initialized array. Everything else with unsafe code is an optimization. Often a premature one. Maps should be built on "Vec", for example.

I would actually hope for the opposite. If your application needs unsafe code, it would be better for that code to be isolated into a "blessed" (i.e. widely vetted by those with the relevant expertise) library with a safe interface, rather than rolling your own.

Re: The Rust Libs Blitz

#27

Post by ronjouch »

dtolnay wrote: post #8
wyldfire wrote: post #6

> The product of this process will be a mature core of libraries together with a set of API guidelines that Rust authors can follow to gain insight into the design of Rust and level up crates of their own interest. Is there a plan to make these things statically checkable by rustc/rustfmt/rust-tidy or some sort?

Yes! The statically checkable ones will be checked by rustc or Clippy. Though some of the guidelines are at a higher level than what those would be able to check. For example: rustc wouldn't be able to tell whether a particular one of your traits would be valuable to make accessible as a trait object.

Beginner question: what would make a crate non-statically-checkable?

Re: The Rust Libs Blitz

#28

Post by Manishearth »

eximius wrote: post #23
Animats wrote: post #9

Does the "Rust standard of quality" for these crucial crates include "no unsafe code"? "Vec" currently needs unsafe code, because Rust doesn't have the expressive power to talk about a partially initialized array. Everything else with unsafe code is an optimization. Often a premature one. Maps should be built on "Vec", for example.

In Rust, 'unsafe code' is really 'partially compiler check exempt'. It does not mean the code is unsafe. You can manually verify the 'unsafe' parts. It is very unfortunately named.

Yes, but the few exemptions means that you can effectively do basically anything. If you needed unsafe {} for something that block definitely needs more scrutiny and if possible should be avoided.

Re: The Rust Libs Blitz

#29

Post by Animats »

Manishearth wrote: post #17
Animats wrote: post #9

Does the "Rust standard of quality" for these crucial crates include "no unsafe code"? "Vec" currently needs unsafe code, because Rust doesn't have the expressive power to talk about a partially initialized array. Everything else with unsafe code is an optimization. Often a premature one. Maps should be built on "Vec", for example.

https://github.com/bluss/ordermap is 100% safe rust and pretty fast I believe the stdlib one could be refactored, but I'm not sure. There are a lot of optimizations in that one. IMO "no unsafe code" is a stretch. "no unnecessary unsafe code" is what it should be.

That "ordermap" is nice. Could that replace std::collections::hash_map as the main supported map crate?

It imports std::collections::hash_map, which has unsafe code, but only for RandomState, which does not. If RandomState were pulled out of hash_map and moved to a crate with no unsafe code, that dependency could be removed and it would be safe crates all the way down.

IMO "no unsafe code" is a stretch. "no unnecessary unsafe code" is what it should be.

The author of the code doesn't get to determine "unnecessary". That should require extensive and hard to get justification.

Re: The Rust Libs Blitz

#30

Post by leshow »

Animats wrote: post #21
eridius wrote: post #15

Earlier quoted context omitted.

Why do you say premature? Maps, for example, being such a crucial and widely-used data type, should be optimized as much as possible. There's nothing premature about using `unsafe` to build a highly-efficient Map.

Let's see the benchmarks justifying the use of "unsafe" for maps. Maybe there's a better way to do it without much of a performance penalty. It's a good way to find out what optimizations the compiler is missing. It may even turn out that unsafe code written early no longer is a performance win, since the Rust compiler is getting better at optimizing out redundant subscript checks. When you start looking through Rust…

Unsafe rarely turns up in any of the libraries I've used. Where are you getting this from?
Post reply on HN