Viewing profile — _hrfd
_hrfd
HN member- Joined
- Tue, Jun 07, 2016, 11:53 AM UTC
- HN karma
- 180
- Public activity
- 24 items
- HN profile
- View on Hacker News ↗
About _hrfd
No profile information was provided.
Recent public activity
-
comment
Comment #24696302
https://docs.rs/async-compat
-
comment
Comment #24167480
Right, there is a way - to escape braces and print "text {value}" rather than the actual value, you'd use "text {{value}}"
-
comment
Comment #24155406
This is being worked on: https://github.com/rust-lang/rust/issues/67984
-
comment
Comment #23006476
Hi there, thought I might chime in as someone who used to work on tokio and is now working on async-std and smol. :) A month ago I wrote a blog post about the evolution of async Ru…
- story
- story
-
comment
Comment #16445736
Why does option #3 look non-ideal, what are your concerns with it?
-
comment
Comment #16205005
I'd like to read more about those soundness issues - do you have a link?
-
comment
Comment #16077907
Yes, it is. But why 'the worst' aspects of each, though? I see it as the opposite: linked lists built on top of vectors combine good cache efficiency of vectors with algorithmic be…
-
comment
Comment #16075436
But... doubly-linked lists and graphs are easy in Rust! :) Here are a few examples. Doubly-linked list: https://github.com/stjepang/vec-arena/blob/master/examples/l... Splay tree: …
- comment
-
comment
Comment #15144458
It's fairly easy to do this kind of thing using an arena and indices instead of pointers. Here's a simple splay tree with uplinks implemented this way: https://github.com/stjepang/…
-
comment
Comment #14673325
No, the time complexity is the same: O(n log n). The author of the top answer links to his book, where you can find a proof of time complexity: https://sites.google.com/site/algoxy…
-
comment
Comment #14667433
Absolutely - there are cases when branch misprediction is not the bottleneck. It depends on a lot of factors. Another such case is when sorting strings because every comparison cau…
-
comment
Comment #14667136
Basically all comparison-based sort algorithms we use today stem from two basic algorithms: mergesort (stable sort, from 1945) and quicksort (unstable sort, from 1959). Mergesort w…
-
comment
Comment #14666948
That is true - the benchmarks mostly focus on random cases, although there are a few benchmarks with "mostly sorted" arrays (sorted arrays with sqrt(n) random swaps). If the input …
-
comment
Comment #14666849
You're forgetting probably the most important optimization: block partitioning. This one alone makes it almost 2x faster (on random arrays) than typical introsort when sorting item…
-
comment
Comment #14666821
To summarize: If comparison is cheap (e.g. when sorting integers), pdqsort wins because it copies less data around and the instructions are less data-dependency-heavy. If compariso…
-
comment
Comment #14666710
I think it's fair to say that pdqsort (pattern-defeating quicksort) is overall the best unstable sort and timsort is overall the best stable sort in 2017, at least if you're implem…
-
comment
Comment #13254635
There is a chapter in Rustonomicon on subtyping and variance: https://doc.rust-lang.org/nomicon/subtyping.html
-
comment
Comment #13177750
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…
-
comment
Comment #13099689
To transfer ownership, you would wrap the object in Mutex , send it via Sender , use some other synchronization primitive, or simply pass it over at the moment the thread is spawne…
-
comment
Comment #12929386
Yes, there is a simpler approach. If your function returns Result >, then you can use try! or ? operator to return any kind of error. It will be automatically boxed and converted i…
-
comment
Comment #12589819
Chris Lattner on the advantages of reference counting over tracing garbage collection: https://lists.swift.org/pipermail/swift-evolution/Week-of-Mo...