Password Generation in Ruby and Rust Writing the same small program in two different languages. 2018-08-25

I've been doing a fair bit of Rust lately. Honestly, I haven't been so smitten with a language since I started writing Ruby back in 1999.

Rust is many of the things Ruby isn't—precompiled, screaming fast, meticulously efficient, static, explicit, type-safe. But it's also expressive and, above all, fun. I think this rare mix makes it a good companion language for Ruby developers, particularly with things like Helix and rutie making it easy to bridge the two.

The best way of learning is by doing, so why not avoid that and just read about me doing something instead?

The Exercise🔗

This is basically a simplified version of mkpass.

I'm going to be making this simple password generator, once in Ruby so we have something familiar to reference, and once in Rust, to get a feel for what the same sort of code looks like there:

-% simplepass --separator . --length 4 --number 6 --dictionary /usr/share/dict/words leprosy.hemispheroid.diagnosable.antlerless omnivalent.nonstellar.Latinate.convenient narghile.mortally.toytown.heteroeciousness blastplate.spectrological.kenosis.cheddite gyrose.gooserumped.rastik.jigger cogency.widow.sealant.banausic

This is a nice little starter project, exercising a reasonable subset of a language without biting off more than we can chew.

Starting Up🔗

If you don't already have Rust installed, rustup is more or less its equivalent of rbenv or rvm . Or if your OS offers a native package, by all means use that.

Once we're ready, we'll want to make a project using cargo:

-% cargo new simplepass && cd simplepass Created binary (application) `simplepass` project -% cargo run Compiling simplepass v0.1.0 (file:///home/freaky/code/simplepass) Finished dev [unoptimized + debuginfo] target(s) in 1.00s Running `target/debug/simplepass` Hello, world!

I won't hold your hand too much here—cargo will feel fairly familiar if you're used to gem and bundler .

Tip: cargo install cargo-edit .

Argument Parsing🔗

First we need to parse our command line, handling errors and providing a useful --help . Not by hand, obviously, we're not savages.

There are lots of argument parsing libraries for Ruby, but I like to minimise run-time dependencies, and we have minimal needs, so let's just use the stdlib optparse :

require ' optparse ' Options = Struct .new( :length , :number , :separator , :dict ) .new( 4 , 1 , ' ' , ' /usr/share/dict/words ' ) OptionParser .new do | opts | opts.on( ' -l LEN ' , ' --length LEN ' , Integer, ' Length of the password ' ) do | v | Options .length = v end opts.on( ' -n NUM ' , ' --number NUM ' , Integer, ' Number of passwords ' ) do | v | Options .number = v end opts.on( ' -s SEP ' , ' --separator SEP ' , ' Word separator ' ) do | v | Options .separator = v end opts.on( ' -d FILE ' , ' --dictionary FILE ' , ' Dictionary to use ' ) do | v | Options .dict = v end end .parse!( ARGV )

Could be a bit more declarative—we're having to bridge the gap between our options Struct and the flags by hand, but it's all pretty straightforward.

Usage: simplepass [options] -l, --length LEN Length of the password -n, --number NUM Number of passwords -s, --separator SEPARATOR Word separator -d, --dictionary FILE Dictionary to use

Rust's standard library is quite small, so we're going to need to slurp in a dependency for this unless we want to be bashing rocks together. Thankfully, Rust both has great dependency management, and also statically links by default—everything will be in one self-contained executable.

We have a lot of choice, but my favourite by far is structopt :

-% cargo add structopt Adding structopt v0.2.10 to dependencies

Just like with bundle add editing Gemfile , this edits our Cargo.toml so Rust knows what we're talking about when we say:

#[ macro_use ] extern crate structopt;

The upcoming (as of August 2018) Rust 2018 is getting rid of this, but fear not, these sort of changes are opt-in and largely automated.

This is a bit like gem 'structopt' —it tells Rust we're using a crate. We're also telling it we're going to be using the macros it defines.

Macros are Rust's metaprogramming special-sauce, allowing for flexible code generation at compile time—that's where our argument parsing code is going to come from, specialised code generated specifically for our purposes.

use structopt::StructOpt;

Next, we use the StructOpt trait, in order to bring the methods we need in it into scope. Traits are a little bit like Ruby mixins—groups of methods that can be added to other types—and they form the basis for a large chunk of the Rust type system.

For example, IO in Rust works in terms of Read , Write and Seek traits, which can be implemented by any type. Methods that use IO-capable types limit themselves to the traits they need, rather than to concrete types. You can think of this as a bit like explicit duck typing—you don't care if it's a File or a Socket or a StringIO , you care if it supports read() , write() , and seek() .

You can also see a hint of refinements in this—traits are only available if you use them. You're free to implement your own traits on other types, without fear of polluting the global namespace.

#[ derive (StructOpt)]

derive is a way of asking Rust to generate code for us—in this case we're asking it to derive argument parsing code from the structure we're about to define, using the procedural macros slurped in from structopt .

#[ structopt (name = " simplepass " )] struct Options { /// Length of the password #[structopt(short = "l", long = "length", default_value = "4")] length : usize , /// Number of passwords #[structopt(short = "n", long = "number", default_value = "1")] number : usize , /// Word separator #[structopt(short = "s", long = "separator", default_value = " ")] separator : String, /// Dictionary to use #[structopt( short = "d", long = "dictionary", default_value = "/usr/share/dict/words", parse(from_os_str) )] dict : std::path::PathBuf, }

Now we define our struct , giving it named fields with appropriate types, decorating it with documentation comments ( /// ) and using structopt() attributes to control the argument parsing code generation.

The only slightly tricky bit here is the filename handling. Rust String s are always UTF-8, but filenames are OS-dependant—on Unix they can be almost any string of bytes except NULL and / , on Windows they're a wonky 16-bit Unicode format.

More generally, Rust provides OsString , which types like PathBuf are built on top of.

PathBuf is a type that abstracts away these details. It's not that we can't just use a String , but if we do that, our program won't necessarily work when it should.

Interestingly, our --help is a fair bit fancier: thanks to the Cargo.toml , structopt knows who I am and what version this has:

simplepass 0.1.0 Thomas Hurst <tom@hur.st> USAGE: simplepass [OPTIONS] FLAGS: -h, --help Prints help information -V, --version Prints version information OPTIONS: -d, --dictionary <dict> Dictionary to use [default: /usr/share/dict/words] -l, --length <length> Length of the password [default: 4] -n, --number <number> Number of passwords [default: 1] -s, --separator <separator> Word separator [default: ]

Dictionary Loading🔗

For real passwords, I suggest the EFF Diceware Wordlist. You'll need to preprocess it before it'll work properly with simplepass .

Next up, we want to load the dictionary—a list of line-separated words. On Linux, BSD, etc you should have one in /usr/share/dict/words , so we'll default to that.

As a bit of defensiveness, we'll strip whitespace, and ensure the words are both unique and non-empty.

dict = begin File .readlines( Options .dict) .map(& :strip ) .reject(& :empty? ) .uniq rescue SystemCallError => e abort( " #{ Options .dict}: #{e.message} " ) end

Quite straight-forward, but a little inefficient—we're making four separate Array instances here, one with each line, one with each stripped line (with a copy of the line), one without blank lines, and finally an Array without any duplicates.

We can avoid this by being a little less idiomatic and mutating in place:

File .readlines( Options .dict).tap do | lines | lines.each(& :strip! ) lines.reject!(& :empty? ) lines.uniq! end

Interestingly, TruffleRuby ought to be able to do this sort of optimisation for us, eliding the temporary intermediate instances automatically without us having to sacrifice safety or looks.

This is a bit more involved, and a lot less familiar, so I'll decompose it some.

fn main () -> Result<(), String> {

Unlike Ruby, Rust needs an entry-point function for your application. Like C, it's called main . Also like C, error handling is done by returning things from functions, though Rust does it in a rather more structured way.

The bit after the -> is our return type, which probably looks a bit weird to you. Result is an enum , a so-called sum-type, an abstract type that is made up of one of several possible variants. Two, in this case:

enum Result <T, E> { Ok(T), Err(E) }

In a real-world program, something more structured than just a String will often be called for, particularly in a library, but for our purposes this is fine.

The <..> bits are the type parameters, and we're passing in () (read: nothing) for the Ok side and String for the Err side.

If we return an Err , Rust's built-in error handling for main will exit with our message and a non-zero exit code.

let opts = Options::from_args();

Unlike Ruby, Rust demands we declare our variables explicitly with let . We can also specify a type ( let opts: Options = ... ) but Rust tries very hard to work it out from context.

from_args() is implemented in that structopt::StructOpt trait we slurped in earlier, building an instance of our Options struct from the command-line arguments.

let dict = std::fs::read_to_string(&opts.dict)

This is where our Err can come from—opening the file and slurping it into a String .

We have to pass in the filename using a & —lending it a reference, so we retain ownership of the value itself—otherwise it would want to move into the function we're calling.

This is part of Rust's "big gamble", ensuring you're very precise about the ownership of data in your program. It can be tricky to get used to, but the payoff is efficient, predictable automatic resource management, safer and more explicit mutability, and by virtue of that, a guarantee that data races simply cannot happen.

.map_err(| e | format!( " {} : {} " , &opts.dict.display(), e))?;

Rust's io::Error doesn't carry the erroring filename around, in part for efficiency, in part because you can do IO on all sorts of things and it might not make sense. If we drop the map_err it will still work, it just won't display the name of the file that errored.

So, that Result I mentioned? That's what read_to_string returns, not a String , but a Result<String, io::Error> . With map_err , we're asking the Result to transform the Err side of things from that rather clinical Err(io::Result) into a formatted Err(String) containing the filename.

As you might imagine, there is also a map() for transforming the Ok(String) side.

Finally we have the question mark operator. It's easy to miss, but fear not—the compiler would complain if we missed it thanks to its type checks.

If you've ever looked at Go, you'll have seen if err != nil { return _, err } just about everywhere. This pattern puts a lot of people off, considering how often you need to write it in any non-trivial application.

Rust recognises the pain of this, and reduces all that boilerplate down to a single character, ? . It will either return the entire function with the Err(String) for the caller to handle, or it'll unwrap the OK(String) to a plain String for our function to continue with.

An Interlude🔗

If this is all a bit confusing, let's take a quick Ruby break, and imagine how Result might work in the context of a familiar language:

module Result def initialize ( thing ) @thing = thing end def map () self end def map_err () self end def unwrap () expect( " unwrap failed " ) end end class Ok include Result def map () Ok .new( yield @thing ) end def expect ( str ) @thing end end class Err include Result def map_err () Err .new( yield @thing ) end def expect ( str ) abort(str) end end success = Ok .new( " it worked " ) failure = Err .new( " it didn't work " ) success.map(& :length ).map_err(& :upcase ) # Ok(9) failure.map(& :length ).map_err(& :upcase ) # Err("IT DIDN'T WORK") success.expect( " it should have worked " ) # => "it worked" success.unwrap # => "it worked" failure.expect( " it should have worked " ) # => aborts with "it should have worked"

Rust handles nil similarly—instead of a bare value, you use an Option enum that is either Some(thing) or None , with behaviour very similar to Result . You basically can't miss a necessary nil check, because the type system won't let you.

It's worth thinking about this pattern, and the other methods you might implement. Perhaps you could have default values for failures, or chain together multiple Results, or even make them Enumerable ? This is basically how errors work in Rust.

The ? operator would replace this sort of boilerplate:

dict = case result = File .read_to_string(file) when Ok then result.unwrap when Err then return result end # or... dict = File .read_to_string(file)?

If you're interested in seeing how the Result pattern might be used in Ruby, you might look at dry-monads.

Back to Rust🔗

let mut dict: Vec<& str > = dict .lines() .map( str ::trim) .filter(| s | !s.is_empty()) .collect();

We ask for it to be mut , or mutable, so we're allowed to modify the dict. Unexpected mutations are a common source of bugs, so Rust makes sure we opt-in to the more unsafe behaviour.

Wait, didn't we already use dict for a String ? How is it now a mutable Vec<&str> , given Rust is statically typed?

While that is true, we're not changing the original variable here—we're shadowing it with a new variable with the same name. This is a relatively common pattern with Rust—reusing a simple descriptive name can, at times, be clearer than having to give every step in a transformation a brand new one.

lines() returns an iterator over slices of the String on line boundaries. Slices aren't standalone objects, but references to chunks of existing ones, making them very efficient—little more than a pointer and a length. They reference the original dict , and Rust will make sure they don't outlive it.

The call to map trims the slices, similar to Ruby's map(&:strip) . Here we're referring to the trim method using its fully qualified name.

We could define our own reject() method using extension traits if we found ourselves using this pattern a lot.

filter() is basically Ruby's select() —unfortunately standard Rust has no reject() , so we use Rust's syntax for a closure here instead, much like the Ruby select { |s| !s.empty? } .

Finally, we collect() into the final Vec<&str> - a vector (array) of string slices. It's important to note that nothing actually happens until this point— collect() drives the iterator, which is otherwise completely inert, like a Ruby lazy Enumerator.

collect() is quite powerful, and can build many different types of collection.

Like a lazy Enumerator, there are no intermediate vectors here—each stage runs a step at a time: finding the next line, trimming the resulting slice, and if it isn't empty, pushing it onto the Vec.

dict.sort_unstable(); dict.dedup();

Now we want to deduplicate the dictionary. In Ruby, uniq builds a hash table so it can remove all duplicates from arbitrary collections, but with considerable memory cost.

Rust's dedup() takes a much cheaper path: iterate over the collection and remove consecutive repeated elements. This is less flexible, but consumes very little memory.

Because it can only deduplicate consecutive items, we need to sort our dictionary. sort_unstable() is fast and in-place, but can swap the order of already-sorted items (i.e. it's allowed to use a quicksort). If we cared about that, and were willing to use more memory, we could use the more conservative sort() (which uses a variant of merge sort).

Alternatively, we could have used a similar approach to Ruby—collecting into a HashSet, for example. You might like to try that.

Password Generation🔗

Now we need to loop over our password count, securely pluck out entries from our dictionary, and join them with our separator, before printing the result.

Options .number.times do password = Options .length.times.map do dict.sample( random: SecureRandom ) end .join( Options .separator) puts password end

Array#sample does take a count, but it removes each selection from the pool of candidates—we want independent samples so we can make all passwords.

That's quite pretty, don't you think? Each line has a specific meaning, mapping precisely to our task with minimal noise. Go Ruby.

We're careful to use SecureRandom , and not the default, relatively predictable random number generator, though I had to prove to myself that it would notice if I misspelled the keyword and left it at the default...

Again, we'll need a crate here, this time for random selection. rand is a de-facto standard for this:

extern crate rand; use rand::Rng; // later, in main()... let mut rng = rand::EntropyRng::new();

Just like with structopt , we tell Rust we're using the crate, use the rng trait we need out of it, and finally we instantiate EntropyRng , its generic secure random generator.

use std::iter::repeat_with; let mkpass = || { repeat_with(|| rng.choose(&dict).expect( " dictionary shouldn't be empty " )) .take(opts.length) .map(| s | *s) .collect::<Vec<& str >>() .join(&opts.separator) };

Braces are optional for a single statement.

|| { .. } is how Rust spells lambda { || .. } , so we're making a block of code (a closure) and stuffing it into mkpass , capturing local variables from the environment like we might in Ruby.

repeat_with makes an iterator that calls the closure repeatedly (we use it so we don't need to spell out the full name later); take() is just like the method of the same name in Ruby, it limits us to the first n elements.

But what's that map(|s| *s) doing? rng.choose() returns a reference to the item it selects, so we're getting a &&str instead of a &str . So we apply the dereference operator * to get back our &str .

Finally, we collect into a vec: this time using the beloved turbofish operator to specify the type of thing we want it to collect into, and then we join in a mostly-familiar way to get our final password.

for password in repeat_with(mkpass).take(opts.number) { println!( " {} " , password); }

Finally, we iterate over repeated calls to the closure we just made, and print their result. There are other ways we could have written this: for example, iterating over a range, or using for_each . Give them a try, see which you prefer.

Dubious Expectations🔗

If you've been paying attention, that expect() in mkpass should be bugging you.

rng.choose(&dict).expect( " dictionary shouldn't be empty " )

We're explicitly advising Rust to panic if our expectation isn't met:

-% simplepass -d /dev/null thread 'main' panicked at 'dictionary shouldn't be empty', libcore/option.rs:1000:5 note: Run with `RUST_BACKTRACE=1` for a backtrace.

Panics are a bit like Exceptions—they can actually be caught—but they have meaning more like abort , as a safe means of exiting a program, or occasionally a thread, because something went unexpectedly wrong.

Often expect and unwrap are used during development as a placeholder for future error handling, but they can also be used as a run-time assertion if the programmer is sure a value will never be None or Err .

Think about how you might fix this bug.

So what was the point of all of this? Why write it in Rust if it's both more effort, and less pretty?

"Speed" is the easy answer, but Rust's only about twice as fast here—450ms vs 250ms on my ancient Xeon. It's about six times more memory-efficient too, but I'm not going to get worked up over 60MB vs 10MB. Sometimes—even often—Ruby is good enough.

For me, the most striking difference is the errors I encountered during development. For example:

#<Enumerator:0x000000080782a690> simplepass.rb:39:in `block in <main>': undefined method `join' for nil:NilClass (NoMethodError) from simplepass.rb:36:in `times' from simplepass.rb:36:in `<main>'

From this quite straight-forward mistake:

puts Options .length.times.map do dict.sample( random: SecureRandom ) end .join( Options .separator)

This does work, but it needs one small change. Hint: this is almost a one-liner.

Specifically, Ruby first noticed something was wrong while executing the code. It parsed my arguments, slurped in the file, printed some junk output, and then exploded due to, effectively, a type error.

While I certainly experienced a lot more errors while writing the Rust version, with the exception of that expect() panic (which I expected!), every single one happened before a single line of code was executed. In fact, most were reported in my text editor without me even having to do anything.

While Rust's no panacea against buggy code, it offers a degree of confidence not easily found when writing Ruby, without painstakingly-written test suites that cover every last conditional.