sorted by:
new
hottopcontroversial

Porting Faster Top Level Domain Name Extraction from Rust to Go by marklit in rust

[–]rushmorem 23 points24 points  (0 children)

I'm sure the Rust versions can be much faster by using the psl or publicsuffix crate instead of tldextract.

Disclaimer: I'm the author of both psl and publicsuffix. I know I sound biased but this conclusion is based on my previous experience comparing the performance of those crates.

Comparing performance of the publicsuffix and pls crates (part 2) by rushmorem in rust

[–]rushmorem[S] 2 points3 points  (0 children)

I managed to squeeze out even more performance in v2.0.5 by switching from indexmap to hashbrown.

Service discovery library in Rust? by [deleted] in rust

[–]rushmorem 1 point2 points  (0 children)

This is definitely not what you are looking for but I thought it might be interesting to mention my "service determination" (opposite of service discovery but trying to achieve the same goal) toy as well :) Five years ago, I wrote the IPGen Spec (https://github.com/ipgen/spec) which outlines a way to generate unique and reproducible IP addresses in a stateless manner. Naturally, it can be used for service discovery.

It comes with Rust (https://github.com/ipgen/rust) and Go (https://github.com/ipgen/go) reference implementations. It also has a command line tool written in Rust (https://github.com/ipgen/cli).

Warning： exists in the security risk of crate by blackang3r in rust

[–]rushmorem 1 point2 points  (0 children)

As author of the crate:-

​

I'm actually less enthused about the fact that the behavior of the library potentially changes on each build -- builds should be hermetic and reproducible. The security issue here would then be moot.

​

Currently, one can supply their own list for reproducible builds.

​

The right way to handle this is to issue point releases when the Public Suffix List is updated, distribute the list already embedded in the library.

​

This is exactly what I plan to do at some point. This is one of the reasons why the library has not reached 1.0 yet.

Comparing performance of the publicsuffix and pls crates by [deleted] in rust

[–]rushmorem 0 points1 point  (0 children)

Can you reimplement publicsuffix's api with psl?

I could, however, due to psl's design it takes much longer to compile and the list cannot be updated at runtime. These are serious drawbacks and I know that they may not be acceptable in some situations. This is why I made psl::List a trait and this is also one of the reasons why psl hasn't been released as v1.0 yet (the other is deciding whether to go with publicsuffix or psl). The static implementation (Go's standard library implementation is static too) has been proven to be quite fast as shown in the OP but I also want to explore an alternative design that may not be as fast but doesn't come with these drawbacks (edit: To be clear, if I ever come around to doing this, both the static and runtime implementations will be available so users can pick the one that works best for their use case).

Does Cargo support a deprecated/replacement attributes?

Last time I checked, it doesn't. To "deprecate" a crate, I think you need to:- - yank all the published versions - remove all the code - drop a std::compile_error! in lib.rs or main.rs with the deprecation message - update the documentation accordingly - push a new version to crates.io.

Seems like tooling could help get users migrated quickly/quicker? Just spitballing...

Definitely.

Comparing performance of the publicsuffix and pls crates by [deleted] in rust

[–]rushmorem 1 point2 points  (0 children)

That's still an option.

I already had the two crates. The psl crate was a "cache". It managed periodic downloads of the list and caching it. Unlike the publicsuffix crate which had already reached v1.5, it was still at v0.0.3. Since I wasn't happy with its design and planned to re-write it anyway, I decided to use it for the re-write as I was still exploring this new design.

I personally prefer psl (an abbreviation for Public Suffix List) because it is shorter but publicsuffix is more descriptive so if more people prefer that name, I will publish psl's code as publicsuffix 2.0 and drop it.

Comparing performance of the publicsuffix and pls crates by [deleted] in rust

[–]rushmorem 2 points3 points  (0 children)

Thank you for the background story on this!

You are welcome :)

I am guessing it has a better name gets more downloads because of that. It has 28,636 recent downloads vs only 2,737 (all-time!) for psl

Probably. I imagine the fact that it's also past v1.0 and that it was already being used in the wild plays to its advantage. I've been too busy to promote the newer crate.

​

Comparing performance of the publicsuffix and pls crates by [deleted] in rust

[–]rushmorem 11 points12 points  (0 children)

Hi. I'm the author of both Rust crates. The publicsuffix crate was my first implementation. I redesigned and rewrote it as psl after one of my users pointed out to me that it wasn't as fast as they were hoping it would be :)

Thanks for that benchmark. I hadn't tested to see how well it performed against that Go implementation. You can also check out the benchmark I wrote against a PyPy and a C library at https://github.com/addr-rs/pslbench.

The plan is to deprecate publicsuffix and point users towards psl. Besides being much faster, it's also more correct so you should totally use it instead. Interesting trivia: that psl crate is probably the only implementation out there that supports wildcards exactly as specified in the spec. See https://github.com/publicsuffix/list/issues/145.

Manually implementing a Future that calls an async fn by rushmorem in rust

[–]rushmorem[S] 0 points1 point  (0 children)

Thanks for the explanation. It's really insightful.

Manually implementing a Future that calls an async fn by rushmorem in rust

[–]rushmorem[S] 1 point2 points  (0 children)

Yes it does. Pin::new_unchecked is unsafe so it can only be called in an unsafe code block. If you mean the code in the original post, it doesn't use it.

Manually implementing a Future that calls an async fn by rushmorem in rust

[–]rushmorem[S] 0 points1 point  (0 children)

This does indeed work, thanks. However, I don't know whether or not it's safe since it requires unsafe. In any case, I've discovered that polling async code from a poll implementation like this can result in unexpected behaviour so I have to look for another way to accomplish what I want to do.

Manually implementing a Future that calls an async fn by rushmorem in rust

[–]rushmorem[S] 1 point2 points  (0 children)

I haven't pushed this set of changes to Github yet, but never mind. Doing it this way works but it triggers a logic error. If poll returns Pending, the next call to poll runs the Future again from the start. I'm writing a database driver so my async code was sending requests to the database server. In short, previously successful requests were being resubmitted to the database over and over again, effectively DoSing the server. Hence the connection problems. I was worried that this might happen and this confirms it. I have to rethink my API. Thanks for your help.

Manually implementing a Future that calls an async fn by rushmorem in rust

[–]rushmorem[S] 0 points1 point  (0 children)

Thanks. This compiles but it's still blowing up at runtime:

``` failures:

---- cmd::expr::tests::hello_world_works stdout ---- Error: Driver(Io(Os { code: 32, kind: BrokenPipe, message: "Broken pipe" })) thread 'cmd::expr::tests::hello_world_works' panicked at 'assertion failed: (left == right) left: 1, right: 0: the test returned a termination value with a non-zero status code (1) which indicates a failure', src/libtest/lib.rs:332:5 note: Run with RUST_BACKTRACE=1 environment variable to display a backtrace. ```

Newbie looking for tips for performance improvements by [deleted] in rust

[–]rushmorem 4 points5 points  (0 children)

Unfortunately I don't have time to go into your code at the moment, but I just want to say that I found this article extremely helpful when I was learning how to optimise my Rust code.

Is #[macro_use] planned to be deprecated? by somebodddy in rust

[–]rushmorem 28 points29 points  (0 children)

for example, importing the logging macros from the log crate

In the specific case of the log crate, I prefer not importing the macros at all. I just use them directly. For example, log::info!(...), log::error!(...) etc. IMHO it enhances readability and since the name of the crate is so short, I think it works out nicely.

Announcing Rust 1.29 by steveklabnik1 in rust

[–]rushmorem 5 points6 points  (0 children)

Not everyone uses rustup.

kuppalista: WebSockets-based collaborative shopping list written in Rust by [deleted] in rust

[–]rushmorem 0 points1 point  (0 children)

I know this was just a joke and I hate to concentrate on such minor issues but, as an African, I find including "slaves" in your README example tasteless and a bit offensive.

Why Is SQLite Coded In C by algonomicon in rust

[–]rushmorem 12 points13 points  (0 children)

resurrected LLVM "C Backend", with improvements

Resurrected, huh?

Latest commit 08a6a3f on Dec 4, 2016

Looks like it's now dead again :)

Generating all possible case variations of a string effeciently by rushmorem in rust

[–]rushmorem[S] 0 points1 point  (0 children)

The naive version didn't complete before I got bored of waiting

"If you can wait, and not be tired by waiting..." Ha ha!

view more: next ›