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

61–70 of 125 posts

Re: The Rust Libs Blitz

#61

Post by Manishearth »

lossolo wrote: post #58
Manishearth wrote: post #24

Earlier quoted context omitted.

(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 au…

> winning rust benchmarksgame entry C is winning that benchmark, around 2x faster than Rust. http://benchmarksgame.alioth.debian.org/u64q/regexredux.html

Wrong benchmark. I'm talking about k-nucleotide, which tests hashmaps.

http://benchmarksgame.alioth.debian.org/u64q/knucleotide.htm...

(And I was only really talking of the comparison of rust v rust, not rust v c, i.e. that ordermap is faster than the built in hashmap despite not using unsafe)

Re: The Rust Libs Blitz

#62

Post by newsat13 »

z1mm32m4n wrote: post #14

I really love seeing articles like this come out about Rust. It's language design the way it should be: incorporating the cutting edge ideas from academia while still striving to cater to beginners; drawing on the strengths of other languages communities to build out good library and solutions to package management; designing everything in the open, and constantly seeking feedback from their users. It's a great blend…

> I really love seeing articles like this come out about Rust.

Yeah, me as well. It's a perfect marriage of academic know how and pragmatism. Very exciting year for Rust.

Re: The Rust Libs Blitz

#63

Post by Manishearth »

yazaddaruvala wrote: post #50
Manishearth wrote: post #24

Earlier quoted context omitted.

(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 au…

Do you think there is some room for education here? Would it be useful for Crates.io to show some "coverage" metric? eg. "unsafe lines = 5%" or "unsafe instructions = 0.01%" I think that would be a pretty easy way to put this convo to bed yea? Have there been talks about this before? Is it worth me opening an issue/RFC on Cargo?

I don't think it's worth making changes like that to satisfy random misconceptions unless they are widespread.

There are good reasons for having an unsafe-code flag on a crate. This is not one of those.

This has been discussed in the past and the main concern IIRC is that this may make people afraid to use crates that contain unsafe code even if it is well audited. There's a finer balance you want to strike here.

Re: The Rust Libs Blitz

#64

Post by luck_fenovo »

It is an unfortunate name. I don't know why, given how inclusive the Rust community usually is and how eager they were to remove master/slave terminology, that they would choose to announce this effort under the banner of Nazi war tactics.

Re: The Rust Libs Blitz

#65

Post by tveita »

microcolonel wrote: post #45

Rust sorta has a de-facto code style. It'd be interesting to add tooling to cargo to make it obvious how to comply with the evolved standard style for Rust.

Clippy has some checks for naming convention beyond what rustc and rustfmt does. Not nearly as much as https://github.com/brson/rust-api-guidelines, but the wrong_self_convention check helped me make sense of the as/to/into conventions.

https://github.com/Manishearth/rust-clippy

Re: The Rust Libs Blitz

#66

Post by burntsushi »

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.

> Often a premature one.

Can you share the ecosystem wide analysis that you did that led to this conclusion?

Re: The Rust Libs Blitz

#67

Post by epage »

Manishearth wrote: post #25
epage wrote: post #22

Earlier quoted context omitted.

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.

Thanks for your work

> 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.

Thats the work I was thinking of.

Re: The Rust Libs Blitz

#68

Post by epage »

hyperpape wrote: post #34
eximius wrote: post #23

Earlier quoted context omitted.

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.

It's unsafe in roughly the same way that Rust developers call C and C++ unsafe, right? The advantage is that it's a special, relatively uncommon mode, and it's explicitly marked. But I don't think you can minimize the reality that it's unsafe without also minimizing one of the major selling points of the language.

Because only 10% of your code isn't verified by the compiler but instead needs extra review and tests doesn't eliminate the benefit that 90% of your code is verified by the compiler.

Re: The Rust Libs Blitz

#69

Post by lossolo »

Manishearth wrote: post #61
lossolo wrote: post #58

Earlier quoted context omitted.

> winning rust benchmarksgame entry C is winning that benchmark, around 2x faster than Rust. http://benchmarksgame.alioth.debian.org/u64q/regexredux.html

Wrong benchmark. I'm talking about k-nucleotide, which tests hashmaps. http://benchmarksgame.alioth.debian.org/u64q/knucleotide.htm... (And I was only really talking of the comparison of rust v rust, not rust v c, i.e. that ordermap is faster than the built in hashmap despite not using unsafe)

Ah, sorry, you were writing about hashmaps and I was writing regexes in my IDE in background while reading this thread from time to time, probably that's why I've checked regex instead of hashmap benchmark. I even wrote this benchmark in language not listed on benchmarks game lately to compare the speed. Brain can work in interesting ways!
Post reply on HN