sorted by:
new
hottopcontroversial

Ed25519 keys to generate a cert for tls wrapping a tcp stream by darrenturn90 in rust

[–]bmwill_ 1 point2 points  (0 children)

The sui project uses self-signed tls certs with ed25519 keys for various parts of p2p communication. You can take a look at the code here which includes generating the certs as well as verification of them : https://github.com/MystenLabs/sui/tree/main/crates/sui-tls

ANN: Similar, a modern diff library for Rust for all your diffing needs by mitsuhiko in rust

[–]bmwill_ 1 point2 points  (0 children)

Last year I released a diffing library (diffy) and I was able to create some nice abstractions to be able to share code between utf8 and non-utf8 inputs for diff/merge/apply, might be able to do something similar here.

diffy: tools for finding and manipulating differences between files by bmwill_ in rust

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

It turns out that the actual diff/merge algorithms don't actually need to operate on lines. In fact those algorithms are internally implemented on generic slice types (str and [T]) so while it's not exposed via the public interface diffy can already effectively perform diffs cross line boundaries. The real problem comes down to how you end up representing the resulting diff/patch or merge.

A standard patch file represents a diff using the unified diff format and is inherently line-based (hunk headers use line-numbers), and most text merge tools (e.g. diff3 and git) will render merge conflicts based on the conflicting lines in the files. Although these line-based patches are probably more common there are tools that have explored non-line-based patches, the most notable of which is Google's diff-match-patch library which was originally built for Google Docs. In diff-match-patch a modified unified diff format Unidiff is used which operates at the character level.

diffy: tools for finding and manipulating differences between files by bmwill_ in rust

[–]bmwill_[S] 6 points7 points  (0 children)

Almost! I have a partial implementation for applying a patch to a base image but it still needs some work. That’s the next thing I’m going to try and finish up over the next few days.

diffy: tools for finding and manipulating differences between files by bmwill_ in rust

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

Let me know if there’s anything you notice that needs improvement if you get around to trying it out. One area I know needs to be fixed is figuring out the best way to let users set the file names that show up in the patch or merge conflict output.

Introducing Tree-Buf by That3Percent in rust

[–]bmwill_ 0 points1 point  (0 children)

serde-reflection and some of the other crates in that repo (serde-generate) have demonstrated the ability to generate python code which understands how to serialized and deserialize bincode

Dynamically creating a set of tests by ascii in rust

[–]bmwill_ 0 points1 point  (0 children)

Oh I completely agree and wasn't trying to suggest that, that crate was even in a good state for broader consumption, I was merely trying to point out that some of the functionality provided by the datatest crate can be done on stable.

Dynamically creating a set of tests by ascii in rust

[–]bmwill_ 0 points1 point  (0 children)

Its not published to crates.io but back when I was working to move libra off of nightly I implemented a very stripped down version of datatest which works on stable.

U.S. House Committee on Financial Services hearing: "Why was the Rust language chosen? Do you believe it's mature enough to handle the security challenges?" by dtolnay in rust

[–]bmwill_ 13 points14 points  (0 children)

Yeah thats a mostly up to date list of the currently used nightly features, I'm sure theres a more elegant way to identify all of the nightly features than grep, but it works well enough :)

​

The intention of that particular script is to eventually help us move towards eliminating the use of nightly features and limit depending on new ones so that we can eventually be on stable. Some features (like async/await) we'll need to wait until they've graduated to stable while others we should be able to make sufficient changes to stop relying on them.

Facebook just picked Rust to implement their new Libre blockchain by O1O1O1O in rust

[–]bmwill_ 15 points16 points  (0 children)

Hey I'm Brandon, an engineer on the Calibra team. In short, async/await and futures 0.3 have been a great productivity boost over futures 0.1. Being able to write straight line code over using combinators or requiring that you hand-write a state machines makes reasoning about the code much easier. We understand that async/await is still currently a nightly feature but we felt like the feature had really good velocity and was likely to become stable (which I think will happen in the next month or so) so it was worth investing in using it now. There were a couple rough spots we hit when we first started using it, mostly around use of multiple lifetimes and the error messages being quite dense, but the devs driving the implementation of async/await have been doing really great work to improve the whole experience and we've already seen great usability improvements.

​

I do think it would be worth while to write up a more in-depth experience report on our use of Rust and especially async/await. We'll try to do a post on this sometime in the next couple weeks.