ARC 067 - read ints and find the best choices
Learn to love rustfmt.


No space between a method name and the parens, space after the parens.

-fn main (){
+fn main() {

Multiple statements belong on different lines.

-    let a = input_one[1]; let b = input_one[2];
+    let a = input_one[1];
+    let b = input_one[2];

Spaces go between comma-separated items.

-    println!("{}", solve(&amp;a,&amp;b,&amp;xs));
+    println!("{}", solve(&amp;a, &amp;b, &amp;xs));

Spaces go after the : in declarations.

-fn distances(xs:&amp;[u64]) -&gt; Vec&lt;u64&gt;{
+fn distances(xs: &amp;[u64]) -&gt; Vec&lt;u64&gt; {


Using Result::ok is not appropriate error handling. If there had been a failure while reading from standard input, your program would continue with an empty string. That's unlikely to be what you want.
unwrapping a Result is better than losing an error, expecting is better than that as you get a little bit of a clue as to where there was a problem, and returning a Result is even better.
If you are going to document a function, use doc comments, not programmer comments.
Zipping the slice with itself is fine, but using slice::windows is a bit shorter, and may be easier to understand when reading the code.
folding over the distances is fine, but a combination of map and sum is probably easier to understand and is as efficient.
There's no real benefit to taking values like u64 by reference. They are small and implement Copy. I'd expect that passing by value would be the same speed if not faster.
a, b, 'xs' are bad variable names. Make them something useful.




use std::io;
use std::cmp::min;

fn main() {
    let input_one = read_ints();
    let walk_cost = input_one[1];
    let teleport_cost = input_one[2];
    let locations = read_ints();
    println!("{}", solve(walk_cost, teleport_cost, &amp;locations));
}

/// Find the distances between adjacent towns
fn distances(locations: &amp;[u64]) -&gt; Vec&lt;u64&gt; {
    locations.windows(2).map(|w| w[1] - w[0]).collect()
}

fn solve(walk_cost: u64, teleport_cost: u64, locations: &amp;[u64]) -&gt; u64 {
    let dists = distances(locations);
    dists.iter().map(|dist| min(walk_cost * dist, teleport_cost)).sum()
}

fn read_ints() -&gt; Vec&lt;u64&gt; {
    get_line()
        .trim()
        .split_whitespace()
        .map(|n| n.parse().expect("Unable to parse"))
        .collect()
}

fn get_line() -&gt; String {
    let mut buf = String::new();
    io::stdin().read_line(&amp;mut buf).expect("Unable to read");
    buf
}


Overall, your code was easy to read and understand. 



However, it feels like there's more allocation than there needs to be. Specifically, taking an iterator and making a Vec to make it into an iterator to make a Vec to just iterate through it again seems unfortunate.

One silly alternative would be something like this:

extern crate itertools;

use std::io::{self, BufRead};
use std::cmp::min;

use itertools::Itertools;

fn main() {
    let input = io::stdin();
    let input = input.lock();
    let mut lines = input.lines();

    let line = lines.next().expect("no line").expect("Unable to read line");
    let mut config_line = line.split_whitespace().map(|n| n.parse::&lt;u64&gt;().expect("not an integer")).skip(1);
    let walk_cost = config_line.next().expect("no walk cost provided");
    let teleport_cost = config_line.next().expect("no teleport cost provided");

    let line = lines.next().expect("no line").expect("Unable to read line");
    let locations = line.split_whitespace().map(|n| n.parse::&lt;u64&gt;().expect("not an integer"));
    let distances = locations.tuple_windows().map(|(a, b)| b - a);
    let costs = distances.map(|dist| min(walk_cost * dist, teleport_cost));
    let total_cost: u64 = costs.sum();

    println!("{}", total_cost);
}


This is not what I'd consider idiomatic Rust code, however. I always find iterators that return Results to be a bit awkward to deal with while still passing up errors to the calling function.