$ cat ~/.profile GIT_AUTHOR_NAME=Florian Gilcher TWITTER_HANDLE=argorak GITHUB_HANDLE=skade BLOG=skade.

Transcription

1

2

3 Useful Rust

4 $ cat ~/.profile GIT_AUTHOR_NAME=Florian Gilcher TWITTER_HANDLE=argorak GITHUB_HANDLE=skade BLOG=skade.me YAKS=yakshav.es

5 Backend Developer Ruby Programmer since 2003 Rust Programmer since 2013 CEO asquera GmbH

6 Community person Rust UG Berlin/Karlsruhe Search UG Berlin Ex-chairman of Ruby Berlin e.v.

7 Part of the global Rust community team Organiser eurucamp/jrubyconf.eu Organiser RustFest

8 Words of warning Rust is verbose......sometimes willfully obtuse......and rustc is the "Rust Complainer"

9 Rust is great, after the two to three weeks of pain in the beginning.

10 The compiler goes from annoying to your best friend.

11 The language

12 Systems programming language Developed by Mozilla Financed by Mozilla In Firefox!

13 Rust is little over a year old

14 Rust 1.0 is little over a year old

15 Rust itself is far older.

16 Properties C-like curly-braces language Java-like generics syntax expression based, similar to Ruby Rust is not object-oriented

17 Goals of Rust Memory-safety without garbage collection Support for concurrency and parallelism (Predictable) speed "Batteries replaceable"

18 Safety Static typesystem, with type inference No null pointers Unique pointers everywhere

19 Speed No hidden memory allocations Allocation-free core Predictable deallocations Abstractions without runtime overhead

20 Bells and whistles Easy and cost-free C FFI Regular releases (every 6 weeks) Great backwards-compatibility

21 Projects Servo, a web renderer in Rust Parity, an etherium implementation Rust Skylight, a Ruby app performance analyser rust-lang.org/friends.html

22 Solving tough problems

23 Shared mutable state is dangerous

24 Is sharing dangerous?

25 Is mutability dangerous?

26 Mutation of local values with one owner is not dangerous.

27 Sharing of immutable values is not dangerous.

28 Mutability and Sharing combined are dangerous.

29 Shared and mutable state is dangerous

30 Mutability fn main() { let int = 64; int = int + 1; //~^ ERROR re-assignment of immutable variable `a`

31 fn main() { let mut int = 64; int = int + 1;

32 Sharing struct Meal { name: String fn eat(m: Meal) { println!("ate: {", m.name);

33 let meal = Meal { name: String::from("Fish & Chips") ; for i in 1..3 { std::thread::spawn(move { eat(meal); //~^ ERROR capture of moved value: `meal` );

34 Ownership

35 Every value has (exactly) one owner.

36 The owner is responsible for cleanup.

37 The owner can mutate the value, if wanted.

38 Ownership can be passed.

39 fn eat(m: Meal) { println!("ate: {", m.name); // m will be destroyed here

40 fn eat(m: Meal) { println!("ate: {", m.name); drop(m)

41 fn eat(m: Meal) { let mut mutated = m; mutated.name = String::from("Godzilla & Chips"); println!("ate: {", mutated.name); drop(m)

42 This is also called "consuming".

43 I cannot consume a meal 3 times.

44 Borrowing

45 What you own, you can borrow.

46 fn describe_meal(m: &Meal) { println!("you handed me a: {", m.name);

47 fn mutate_meal(m: &mut Meal) { mutated_meal.name = String::from("Godzilla & Chips");

48 fn eat_borrowed_meal(m: &Meal) { eat(*m); //~^ ERROR cannot move out of borrowed content

49 You can borrow mutably once Or multiple times immutably Exclusive: mutable or immutable, never both Immutable borrows can never become mutable.

50 Shared and mutable state is dangerous

51 &mut T and &T are different types.

52 Traits trait Edible { fn eat(self); fn describe(&self);

53 impl Edible for Meal { fn eat(self) { println!("ate: {", self.name); fn describe(&self) { println!("this is: {", self.name);

54 fn main() { let meal = Meal { name: String::from("Fish & Chips") ; meal.describe(); meal.eat(); meal.eat(); //~^ ERROR use of moved value: `meal`

55 Generics fn eat_anything<f: Edible>(f: F) { f.eat();

56 fn eat_anything<f>(f: F) where F: Edible { f.eat();

57 Generic calls are monomorphised and have no runtime overhead.

58 struct Course<F: Edible> { items: Vec<F>

59 Items must be homogenous.

60 Errors and Results

61 We call algebraic datatypes "enums".

62 enum Option<T> { Some(T), None

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

64 Enough theory

65 Example: JSON

66 decode json_string :: Maybe MyData

67 Hey, describe me the data in the way we both know best, and I will derive the rest.

68 extern crate serde_json; // define MyApiMessage fn main() { use serde_json::from_str; let res = from_str::<myapimessage>("...");

69 Uses internal type information Fails early if the received message is unknown Does not raise exceptions

70 Who likes checked exceptions?

71 I do

72 fn main() { use serde_json::from_str; let res = from_str::<myapimessage>("..."); match res { Ok(message) =>..., Err(e) => println!("error: {", e)

73 Rust ships with a lot of machinery around converting errors, though...

74 pub trait From<T>: Sized { fn from(t) -> Self;

75 impl From<MyApiMessage> for MyDomainModel { fn from(t) -> Self { // here be alpaca

76 fn main() { use serde_json::from_str; let res = from_str::<myapimessage>("...").and_then( message { MyDomainModel::from(message) ) //~^ WARNING: unused result which must be used

77 Checking the complainer: compile-test

78 fn main() { use serde_json::from_str; let res = from_str::<myapimessage>("...").and_then( message { MyDomainModel::from(message) ) //~^ WARNING: unused result which must be used

79 It s not unusual for libraries to have test suites for the cases that should error/warn at complain time.

80 It s not unusual for libraries to have test suites for the cases that should error/warn at compile time.

81 Example: CouchDB replication

82 CouchDB Replication protocol

83 Describes the process to replicate a source database to a target database.

84 Replicator pub struct Replicator { source: String, target: String

85 fn main() { let r = Replicator { source: "source_name".into(), target: "target_name".into()

86 Inconvenient Initialisation depending on exact structure Struct fields are by default private, this is not going to work outside of the defining module.

87 Seperation of functions and state impl Replicator { pub fn new(s: String, t: String) -> Replicator { Replicator { source: s, target: t

88 fn main() { let r = Replicator::new( "source_name".into(), "target_name".into() );

89 This is still a bit inconvenient Can we get rid of the into() calls?

90 impl Replicator { pub fn new<s,t>(source: S, target: T) -> Replicator where S: Into<String>, T: Into<String> { Replicator { source: source.into(), target: target.into()

91 fn main() { let r = Replicator::new("source_name", "target_name");

92 The VerifyPeers steps Given a replicator between two databases: Check source existence Check target existence Create target if absent Done

93 Can we describe that in Rust?

94 Defining states pub struct Start; pub struct SourceExisting; pub struct TargetExisting; pub struct TargetAbsent; pub struct VerifiedPeers;

95 A stateful wrapper pub struct VerifyPeers<T> { replicator: Replicator, state: T

96 impl<s> VerifyPeers<S> { pub fn transition<x>(self, new_state: X) -> VerifyPeers<X> { VerifyPeers { replicator: self.replicator, state: new_state

97 let replicator = Replicator::new("source_name", "target_name"); let verification = VerifyPeers::new(replicator); let end = verification.transition(sourceexisting).transition(targetexisting).transition(verifiedpeers);

98 Safety gains

99 let replicator = Replicator::new("source_name", "target_name"); let verification = VerifyPeers::new(replicator); let end = verification.transition(sourceexisting).transition(targetexisting).transition(verifiedpeers); verification.transition(sourceexisting); //~^ ERROR use of moved value: `verification`

100 Obvious flaws

101 Nonsensical transitions struct Counter { count: i32 fn main() { let r = Replicator::new("source", "target"); let v = VerifyPeers::new(r); let counter = Counter { count: 0 ; let end = v.transition(counter);

102 Illegal transitions let end = verification.transition(verifiedpeers).transition(sourceexisting);

103 Marking states pub trait State { impl State for Start { impl State for SourceExisting { impl State for TargetExisting { impl State for TargetAbsent { impl State for VerifiedPeers {

104 Constraining to States impl<s: State> VerifyPeers<S> { pub fn transition<x>(self, new_state: X) -> VerifyPeers<X> where X: State { VerifyPeers { replicator: self.replicator, state: new_state

105 Now failing struct Counter { count: i32 fn main() { let r = Replicator::new("source", "target"); let v = VerifyPeers::new(r); let counter = Counter { count: 0 ; let end = v.transition(counter);

106 the trait bound Counter: statemachines::state is not satisfied

107 Constraining Transitions Rust conversion traits: From, TryFrom Into, TryInto Use is very common!

108 We can use them to model state transitions.

109 impl From<Start> for SourceExisting { fn from(_: Start) -> SourceExisting { SourceExisting

110 We implement in the same fashion: SourceExisting -> TargetAbsent SourceExisting -> TargetExisting TargetAbsent -> TargetExisting TargetExisting -> VerifiedPeers

111 impl<s: State> VerifyPeers<S> { pub fn transition<x>(self, new_state: X) -> VerifyPeers<X> where X: State + From<S> { VerifyPeers { replicator: self.replicator, state: new_state

112 Now failing fn main() { let r = Replicator::new("source", "target"); let v = VerifyPeers::new(r); let end = v.transition(verifiedpeers);

113 the trait bound statemachines::verifiedpeers: std::convert::from<statemachines::start> is not satisfied

114 I was promised Useful Rust and all I got was a lousy state machine!

115 How do we implement work? type Error = String;

116 impl VerifyPeers<Start> { pub fn check_source_existence(self) -> Result<VerifyPeers<SourceExisting>, Error> { if try!(check_source_existence()) { Ok(self.transition(SourceExisting)) else { Err("Source doesn t exist!".into())

117 Horray, we also got the failure state!

118 How do we implement a branch? pub enum TargetChecked { TargetExists(VerifyPeers<TargetExisting>), TargetAbsent(VerifyPeers<TargetAbsent>)

119 impl VerifyPeers<SourceExisting> { pub fn check_target_existence(self) -> Result<TargetChecked, Error> { if try!(target_exists()) { Ok(self.transition(TargetExisting)) else { Ok(self.transition(TargetAbsent))

120 extern crate statemachines; use statemachines::*; fn main() { let r = Replicator::new("source", "target"); let v = VerifyPeers::new(r); let end = v.check_source_existence().and_then( state { state.check_target_existence() ).and_then( state { //...

121 .and_then( state { match state { TargetChecked::TargetExists(s) => { s.finish() TargetChecked::TargetAbsent(s) => { try!(s.create_target()).finish() );

122 Free This abstraction is free!

123 Fully at compile-time Vanishes at runtime

124 A bit of low-level #[test] fn verify_peers_not_larger_then_replicator() { use std::mem::size_of; assert_eq!(size_of::<verifypeers<start>>(), size_of::<replicator>())

125 Final comments

126 We re exclusively using dynamic dispatch The whole state machine is on the stack

127 This pattern extends well and also works with, e.g. Futures instead of Results Other implementations are possible

128 Real-world: Laze RS Experimental CouchDB toolkit, see:

129 Conclusion Rust is sufficiently useful for patterns beyond the main focus to emerge.

130 Rust is focused on usability Usability is tough if you want finegrained control for the user In systems programming, usability is not champion

131 Interview If you have a Rust project, private or commercial, I d like to interview you.

132 twitter.com/argorak

133 rust-lang.org

134 Links