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

SeaHash: A fast, portable hash function in Rust

docs.rs

Post reply on HN
Print view View original

101–110 of 116 posts

Re: SeaHash: A fast, portable hash function in Rust

#101

Post by yazaddaruvala »

steveklabnik wrote: post #77
yazaddaruvala wrote: post #53

Earlier quoted context omitted.

While I mostly agree with you, I'd like to play devil's advocate: The Rust core team is relatively relaxed about the community's usage of `unsafe`. I say this because they do not seem to be interested in actively discouraging it's usage. i.e. `unsafe` is discouraged in documentation, not via tools. "Hey please don't use `unsafe` unless you know what you're doing". Is like writing a comment in Javascript, `function(x…

> Ideally, the usage of `unsafe` should be discouraged by the compiler via friction. This is enforced via tools: you have to say 'unsafe' to use something unsafe. That's the speed bump. In addition, there's a lint that you can on to fail the build if you use `unsafe`. This won't apply to your dependencies, but you can make it apply to your code.

Explain to me why, ticki, who is a relatively experienced Rust dev choose to retype `unsafe` over re-using a crate (byteorder) which is supposedly equivalent?

1. Crate discoverability could be improved.

2. He wanted full control of the abstraction.

3. This particular library is just an experiment.

4. ...

Regardless of the reason, the reality is the same, `unsafe` could have been ignored but wasn't. Instead, the path of least resistance was to re-write `unsafe` blocks. IMO, it is not truly "friction"/discouraged if it is also the path of least resistance.

Re: SeaHash: A fast, portable hash function in Rust

#103

Post by yazaddaruvala »

duaneb wrote: post #70
Manishearth wrote: post #58

Earlier quoted context omitted.

Nobody is putting effort into propaganda about unsafe because the community is already very strongly averse to this, and is careful about writing unsafe code. It's not a problem. If it becomes a problem (I doubt it) we can put effort into it. People learn about the language through discussion or documentation, and both of these venues actively discourage unsafe. The one resource out there that teaches unsafe code in…

Have you ever been bitten by unsafe code? IMHO any metrics would be gamed and prioritized above actually quality. As actual quality isn't suffering, why add the unsafe metric in at all? Seems like paranoia not born out of experience.

I have been bitten by the lack of a type checker.

I have been bitten by inexplicit casts.

I have been bitten by segfaults.

I have been bitten by poor/no tests.

I have been bitten by mutable containers.

In every case, more constraints and more explicitness have liberated portions of my cognitive load. I've ended up with fewer bugs, more flexibility to play, reduced ramp-up time for new devs, increased speed of iteration. Why would this trend, to add constraints and explicitness, not continue to be beneficial?

P.S. You haven't been bitten by unsafe code, yet, because the people that write Rust, are still builders of the language. It is still in the early adopter stage. Think about Java, which is now predominantly written by users of the language, imagine that for Rust. The teams currently working with Rust, chose to do so as an experiment. They don't have to get a feature out tomorrow, but that will come. Similarly, there isn't "legacy Rust", yet (except in the compiler - which is fine because it is literally maintained by the experts). Is it really worth waiting for crappy code to get written, then re-written, then forgotten and finally broken, and to relive our mistakes, before we fix a predictable problem?

Re: SeaHash: A fast, portable hash function in Rust

#104

Post by steveklabnik »

yazaddaruvala wrote: post #101
steveklabnik wrote: post #77

Earlier quoted context omitted.

> Ideally, the usage of `unsafe` should be discouraged by the compiler via friction. This is enforced via tools: you have to say 'unsafe' to use something unsafe. That's the speed bump. In addition, there's a lint that you can on to fail the build if you use `unsafe`. This won't apply to your dependencies, but you can make it apply to your code.

Explain to me why, ticki, who is a relatively experienced Rust dev choose to retype `unsafe` over re-using a crate (byteorder) which is supposedly equivalent? 1. Crate discoverability could be improved. 2. He wanted full control of the abstraction. 3. This particular library is just an experiment. 4. ... Regardless of the reason, the reality is the same, `unsafe` could have been ignored but wasn't. Instead, the path…

I can't read ticki's mind, so I can't really say why they made this decision. But I don't think you're right to suggest that this is inherently about using the path of least resistance; #2 on your list is not about that, for example.

Re: SeaHash: A fast, portable hash function in Rust

#105

Post by Manishearth »

yazaddaruvala wrote: post #101
steveklabnik wrote: post #77

Earlier quoted context omitted.

> Ideally, the usage of `unsafe` should be discouraged by the compiler via friction. This is enforced via tools: you have to say 'unsafe' to use something unsafe. That's the speed bump. In addition, there's a lint that you can on to fail the build if you use `unsafe`. This won't apply to your dependencies, but you can make it apply to your code.

Explain to me why, ticki, who is a relatively experienced Rust dev choose to retype `unsafe` over re-using a crate (byteorder) which is supposedly equivalent? 1. Crate discoverability could be improved. 2. He wanted full control of the abstraction. 3. This particular library is just an experiment. 4. ... Regardless of the reason, the reality is the same, `unsafe` could have been ignored but wasn't. Instead, the path…

> is a relatively experienced Rust dev choose to retype

Probably because they were an experienced dev and are experienced enough with unsafe code to write good unsafe code without worrying about it. It was a minor unsafe operation of which the validity is easily proven. Doesn't really prove that there isn't an aversion to unsafe code in the community.

I would generally put the folks who work on Redox in the bucket of "experienced people who know how to write unsafe code" and am pretty sure that they're more comfortable with writing unsafe code than most. Byteorder is a crate that handles this neatly and well (including endianness and stuff), but for ticki's purposes, really, a simple type pun on integers is not that bad. It's like the left-pad of unsafe code.

Re: SeaHash: A fast, portable hash function in Rust

#106

Post by yazaddaruvala »

Manishearth wrote: post #105
yazaddaruvala wrote: post #101

Earlier quoted context omitted.

Explain to me why, ticki, who is a relatively experienced Rust dev choose to retype `unsafe` over re-using a crate (byteorder) which is supposedly equivalent? 1. Crate discoverability could be improved. 2. He wanted full control of the abstraction. 3. This particular library is just an experiment. 4. ... Regardless of the reason, the reality is the same, `unsafe` could have been ignored but wasn't. Instead, the path…

> is a relatively experienced Rust dev choose to retype Probably because they were an experienced dev and are experienced enough with unsafe code to write good unsafe code without worrying about it. It was a minor unsafe operation of which the validity is easily proven. Doesn't really prove that there isn't an aversion to unsafe code in the community. I would generally put the folks who work on Redox in the bucket of…

To paraphrase - "If you're experienced, the Rust community doesn't discourage it. They likely know what they're doing." :)

This sounds very similar to C or C++ developers who criticize Rust. "Experienced C / C++ developers know what they are doing. Why do we need the borrow checker. In my code, these issues Rust claims to solve haven't been an issue for a decade."

The argument seems a little hypocritical. Anyways, its not a big deal, it just seems like an easy problem to solve today, but a tedious problem to live with tomorrow. I'll stop playing devil's advocate now.

Re: SeaHash: A fast, portable hash function in Rust

#107

Post by yazaddaruvala »

steveklabnik wrote: post #104
yazaddaruvala wrote: post #101

Earlier quoted context omitted.

Explain to me why, ticki, who is a relatively experienced Rust dev choose to retype `unsafe` over re-using a crate (byteorder) which is supposedly equivalent? 1. Crate discoverability could be improved. 2. He wanted full control of the abstraction. 3. This particular library is just an experiment. 4. ... Regardless of the reason, the reality is the same, `unsafe` could have been ignored but wasn't. Instead, the path…

I can't read ticki's mind, so I can't really say why they made this decision. But I don't think you're right to suggest that this is inherently about using the path of least resistance; #2 on your list is not about that, for example.

Disagree.

Unless improving the flexibility of the existing abstraction has been explored and deemed infeasible, re-building an abstraction instead of working with the existing abstraction's owner, to improve its flexibility, is taking the path of least resistance.

Re: SeaHash: A fast, portable hash function in Rust

#108

Post by Manishearth »

yazaddaruvala wrote: post #106
Manishearth wrote: post #105

Earlier quoted context omitted.

> is a relatively experienced Rust dev choose to retype Probably because they were an experienced dev and are experienced enough with unsafe code to write good unsafe code without worrying about it. It was a minor unsafe operation of which the validity is easily proven. Doesn't really prove that there isn't an aversion to unsafe code in the community. I would generally put the folks who work on Redox in the bucket of…

To paraphrase - "If you're experienced, the Rust community doesn't discourage it. They likely know what they're doing." :) This sounds very similar to C or C++ developers who criticize Rust. "Experienced C / C++ developers know what they are doing. Why do we need the borrow checker. In my code, these issues Rust claims to solve haven't been an issue for a decade." The argument seems a little hypocritical. Anyways, it…

> "If you're experienced, the Rust community doesn't discourage it. They likely know what they're doing."

That's not what I'm saying. I'm saying that I can understand why ticki just reimplemented it here; because they are experienced enough to know what they're doing, AND because this isn't a dangerous unsafe operation. The AND is important here. There are a couple of unsafe operations which are basically no big deal, and this is one of them (another is the use of unchecked indexing in some cases).

An inexperienced Rust programmer would generally still avoid unsafe like the plague and ask around before doing this. We get this often enough -- folks asking how to do lower level operations well (and often getting pointed to crates like byteorder).

An experienced Rust programmer knows that this specific operation is trivial enough to not worry that much. I know about byteorder, so I would use it in this case, but if I hadn't I'm pretty sure I wouldn't be too averse to just doing the type pun.

I'm not talking about general unsafe code here. I've seen very experienced Rust programmers ask for help in getting rid of or double-checking unsafe code. I'm talking about this specific instance, and saying that it's not in the category of unsafe code that needs to be worried about.

Re: SeaHash: A fast, portable hash function in Rust

#109

Post by dbaupp »

Manishearth wrote: post #108
yazaddaruvala wrote: post #106

Earlier quoted context omitted.

To paraphrase - "If you're experienced, the Rust community doesn't discourage it. They likely know what they're doing." :) This sounds very similar to C or C++ developers who criticize Rust. "Experienced C / C++ developers know what they are doing. Why do we need the borrow checker. In my code, these issues Rust claims to solve haven't been an issue for a decade." The argument seems a little hypocritical. Anyways, it…

> "If you're experienced, the Rust community doesn't discourage it. They likely know what they're doing." That's not what I'm saying. I'm saying that I can understand why ticki just reimplemented it here; because they are experienced enough to know what they're doing, AND because this isn't a dangerous unsafe operation. The AND is important here. There are a couple of unsafe operations which are basically no big deal…

I disagree: this sort of operation that seems safe is some of the most deceptive code to write... there's always the risk of reading a little bit more than intended or incrementing a pointer a little too far and hitting undefined behaviour. (There is in fact a bug (or two) in the type punning `read_u64` code, fortunately just a correctness one, but the small amount of code in that function is enough to obscure it, let alone the long sequence of copy-pasted `unsafe` code that makes up the main algorithm.)

It is definitely a red flag for a function that just reads some bytes to be entirely wrapped in an unsafe block, and I don't think it makes sense to defend it while also saying that the Rust community discourages gratuitous use of `unsafe`. The whole point of Rust is the "experts know what they're doing" argument doesn't work in practice, and people shouldn't get a free pass for large amounts of seemingly undocumented and unjustified `unsafe` just because they have some prominent projects.

Re: SeaHash: A fast, portable hash function in Rust

#110

Post by Manishearth »

dbaupp wrote: post #109
Manishearth wrote: post #108

Earlier quoted context omitted.

> "If you're experienced, the Rust community doesn't discourage it. They likely know what they're doing." That's not what I'm saying. I'm saying that I can understand why ticki just reimplemented it here; because they are experienced enough to know what they're doing, AND because this isn't a dangerous unsafe operation. The AND is important here. There are a couple of unsafe operations which are basically no big deal…

I disagree: this sort of operation that seems safe is some of the most deceptive code to write... there's always the risk of reading a little bit more than intended or incrementing a pointer a little too far and hitting undefined behaviour. (There is in fact a bug (or two) in the type punning `read_u64` code, fortunately just a correctness one, but the small amount of code in that function is enough to obscure it, le…

Fair; I guess I'm wrong here. Perhaps we should be doing something to prevent gratuitous use of unsafe code. I'm quite wary that we may overly stigmatize unsafe code this way, though (leading to people avoiding even the use of libraries like byteorder that contain unsafe code). It's a careful balance to maintain.
Post reply on HN