huonw

Announcement:

With Rust's first birthday upon us on May 15th, 2016, we should take this opportunity to reflect on where we've been, and where we're going. As part of the celebrations, we are pleased to announce the official 2016 State of the Rust Language Survey! Whether or not you use Rust today, we want to to know your opinions. Your responses will help the project understand its strengths and weaknesses, and to establish development priorities for the future.

The 2016 State of Rust Survey

Completing this survey should take about 5 to 10 minutes, and is anonymous unless you give us your contact information. We will be accepting submissions until June 8th, 2016.

Please help us spread the word by sharing the above link on your social network feeds, at meetups, and around your office and other communities.

huonw

#![crate_type = "lib"]
pub fn soa(xs: &mut [f64], ys: &mut [f64]) {
    for (x, y) in xs.iter_mut().zip(ys.iter_mut()) {
        *x += 1.0;
        *y *= 3.5;
    }
}
pub fn aos(points: &mut [(f64, f64)]) {
    for point in points.iter_mut() {
        point.0 += 1.0;

huonw

extern crate rand;

use rand::Rng;

struct Bag {
    contents: Vec<char>,
    rng: rand::ThreadRng,
}

impl Bag {

huonw

use std::cmp::max;
use std::cmp::min;
use std::i16;

const FILTER_SIZE : usize = 16;

pub struct FilterState {
    // Must use doubles for these arrays, otherwise can be noisy.
    input: [f64; FILTER_SIZE],
    output: [f64; FILTER_SIZE],

huonw

Conversation about lifetimes on #rust, on mozilla's irc network, prompted by hamnox and lahwran attempting to understand lifetimes.

Timestamps are in Mountain time.

1-30 07:09.06pm so we're reading this http://doc.rust-lang.org/book/ownership.html 1-30 07:09.28pm it mentions lifetimes a lot, and gives examples of where to use lifetimes, and the effects of lifetimes, but it has yet to actually, you know, describe what a lifetime is 1-30 07:09.48pm lahwran, I actually treat lifetimes as dependency markers 1-30 07:10.05pm we (my partner and I) have made several guesses as we read as to what lifetimes are, based on inference, but then we got to the point where a function used a lifetime both for an input and an output 1-30 07:10.06pm They're descriptions to how long a value lives.

huonw

    * The `Copy` trait is no longer implemented automatically. Unsafe pointers no longer implement `Sync`
      and `Send` so types containing them don't automatically either. `Sync` and `Send` are now 'unsafe
      traits' so one can "forcibly" implement them via `unsafe impl` if a type confirms to the requirements for them even though the internals do not (e.g. structs containing unsafe pointers like `Arc`). These changes are intended to prevent some footguns
      and are collectively known as [opt-in built-in traits][oibit]
      (though `Sync` and `Share` will soon become pure library types
      unknown to the compiler).

huonw

extern crate collections;

use collections::TrieMap;

fn main() {
  let workers = vec!(
    ("Jack", vec!((0000, 200), (500, 1200))),
    ("Jackie", vec!((0000, 600), (800, 1300))),
    ("Marty", vec!((400, 600), (1100, 1600), (1700, 2359))),
    ("Ronald", vec!((600, 1200), (1300, 1800), (1900, 2359))),

huonw

//! Chain macro in Rust
//!
//! A typical usage is to avoid nested match expressions.
//!
//! Supports:
//! - Pattern matching
//! - Or expressions (A | B => ...)
//! - Guarded statements (x if <cond> => ...)
//! - Implicit else (requires all arms to return same type)

huonw

extern crate collections;
use collections::hashmap::HashMap;

struct Node {
    data : ~str,
    children : ~HashMap<~str, Node>,
}

impl Node {
    fn new(data: ~str) -> Node {

huonw

//! Monad macro in Rust
//!
//! A typical usage is to avoid nested match expressions.
//!
//! Supports:
//! - Pattern matching
//! - Or expressions (A | B => ...)
//! - Guarded statements (x if <cond> => ...)

#[feature(macro_rules)];