Rust gets a faster sort implementation | Hacker News Reader

Rust gets a faster sort implementation

github.com

224 pointskzrdude20 comments

The code review here is excellent and supportive. I'm very impressed.

I've submitted a couple of small patches and the Rust core team has always been very helpful and pleasant.

In this case of the sort improvement, nobody in the literal Rust core team was involved in reviewing the PR.

I once submitted a patch to Cargo. Despite being uninformed and violating code style rules which I should have read and known about, they patiently guided me, I resolved the issues, and it ended up being merged. They're great folks.

IMO the LLVM community could learn a few things from the Rust team. I know that the activity level is not the same but it's really encouraging to new folks that reviews get engagement and disposition: "this is good, but fix that" instead of wilting without any clear indication of whether it could be merged.

Also, the fact that the CI triggers and lets you know whether your change causes any collateral damage before you merge takes away a lot of the fear factor of contributing. This is also in stark contrast to LLVM's "merge it if it LGTM, revert it soon after when we find out what it broke."

As an example of this, Zoxc has been trying to get stack probe support into LLVM for two years to no avail [0]. This is important to make sure that stack overflow or buffer overrun actually trigger the guard page and cause termination.

I admit it's not really fair to LLVM to pick on one patch like this but it's frustrating to me even as an outsider.

[0]: https://reviews.llvm.org/p/Zoxc/

Is that just a stack canary? Hasn't gcc had this for years?

No, stack canaries are different. Stack canaries defend against some classes of buffer overflows. Stack probes defend against some classes of stack overflows.

Zoxc has repeatedly refused reasonable requests to alter the patch to fit the standards of upstream. Because of this (and because I am rather tired of not having stack probes, with my embedded system not having functional guard pages), I'll make a hostile fork of their patch soon and get it through the pipeline. Stay tuned.

Ah, interesting. I hadn't gleamed that from the threads. It's great to hear that there's a chance that this will be supported though!

Late comment, but aren't stack probes entirely predicated on having working guard pages? I.e. they only exist to guarantee that the guard page is accessed before anything else, when a frame is larger than the page.

The PR author's initial write-up and responses to comments were excellent too.

That struck me, too. I've found the Rust community generally very helpful, but this is really superb feedback and discussion.

The original TimSort had a problem:

http://envisage-project.eu/proving-android-java-and-python-s...

I assume the author knows about that and/or it does not apply to this modified version.

Author here. Yes, this is an interesting problem TimSort used to have. A counterexample to incorrect TimSort is sequence "120, 80, 25, 20, 30". This simple sequence could have been easily discovered by generating sequences randomly and verifying that the TimSort invariants hold on it. The fact that it took 13 years to discover the bug (using formal verification!) is just silly :)

Fortunately, the problem is easy to fix and there's a brief mention of it in the comments: https://is.gd/txKd4I

Enjoyed reading the review process. Thanks for sharing on HN!

I don't mean to be off-topic (sorry!), but what's the best CGI/FastCGI library for Rust? My impression is that it's not ideal for webapps at the moment, and I'm comfortable with that. Putting all of Python into a webserver chroot isn't exactly ideal either. I specifically ask about Rust because when I looked at it a while back, it just felt so right to me.

It looks like there are a few CGI crates on crates.io, but they're not super popular. Crates.io uses https://github.com/emk/heroku-buildpack-rust in combination with https://github.com/ryandotsmith/nginx-buildpack, which puts nginx in front of a Rust application server, communicating over a socket. See here: https://github.com/ryandotsmith/nginx-buildpack/blob/master/... for the default config, https://github.com/rust-lang/crates.io/blob/0f3adf36108dfac6... for the one we actually use.

(Given this is offtopic, I'll leave it at that. Happy to answer questions over at https://users.rust-lang.org/ )

> Crates.io uses https://github.com/emk/heroku-buildpack-rust

Oh, wow, maintainer here. I had no idea. :-) Thanks for making my morning, and never hesitate to send PRs!

Ask this on the #rust-webdev IRC channel, you'll get more help there.

Reply on news.ycombinator.com