Je suis développeur web freelance et propose des formations à Symfony2 ! Contactez-moi pour en discuter.

I was at Rustfest this weekend. As expected, it was a great conference ! Lots of things to learn, and great people to meet.

I could not attend the workshops (nor the Impl days), but this cool community puts so many things on Github that I’m gonna be able to do them anyway, see for instance:

Also, the videos are on the web already, and you can download lrlna’s zine about memory

What follows is a summary of the talks I liked the most.



Yew, JavaScript without JavaScript

Denis Kolodin talked about Yew, the rust framework he develops.

As a web developper, this is really exciting : we can have both the power and safety of Rust, with the reach of web applications ! Yew looks a lot like doing React development with Redux.

Let’s take an example : imagine we want to create a counter, with 2 buttons to increment/decrement the value. We would:

  1. Create a model
pub struct Model {
    value: i64,
  1. Create the messages
pub enum Msg {
  1. Implement the message handling
impl<CTX> Component<CTX> for Model
    CTX: AsMut<ConsoleService>,
    type Message = Msg;
    type Properties = ();

    fn create(_: Self::Properties, _: &mut Env<CTX, Self>) -> Self {
        Model { value: 0 }

    fn update(&mut self, msg: Self::Message, env: &mut Env<CTX, Self>) -> ShouldRender {
        match msg {
            Msg::Increment => {
                self.value = self.value + 1;
            Msg::Decrement => {
                self.value = self.value - 1;
  1. Create a view that displays the value and the buttons, and sends the messages on a click
impl<CTX> Renderable<CTX, Model> for Model
    CTX: AsMut<ConsoleService> + 'static,
    fn view(&self) -> Html<CTX, Self> {
        html! {
                <nav class="menu",>
                    <button onclick=|_| Msg::Increment,>{ "Increment" }</button>
                    <button onclick=|_| Msg::Decrement,>{ "Decrement" }</button>
                <p>{ self.value }</p>
                <p>{ Date::new().to_string() }</p>

and that’s pretty much it ! It works well with stdweb and cargo web.

… have a look at the examples (I took the counter example there), and enjoy how easy it is to do javascript without writing javascript.

Immutable data structures and why you want them

A great talk with a great slide deck. I’m a bit sad @bodil talked mostly about the data structures, I’d have loved to hear more about the necessity for their immutability.

Anyway, if you wanna learn stuff on

…go watch the talk ! She provides an impressive reading list of papers regarding RRB trees :

After skimming through a few of them… I know I’m gonna need more time during lunch breaks this week to dive deeper on the topic 🙂

She also dropped some cools remarks:

  • nobody is gonna use a library with a bad documentation. Sounds obvious ? It is. And yet as developpers we don’t like to write docs anyway, but we should work on that.
  • I can’t wait for the moment I’m gonna use The « Haskell Defence » in an argument, aka « immutable values make it easier to reason about your program »

Building reliable infrastructure

@spacejam talked about how to introduce verifications in complex architectures… and he introduced tons of great tools that can help us, software developpers, write better applications, with an amazing set of references.

The issue with everything we build stems from our brain : everything we know is subject to bias, and everything we build reflects these biases (see Rationality: From AI to Zombies (confonting assumptions)). Since our code reflects our biases, our automated tests do as well…so our tests tend not to be as effective as they could be.

A solution: don’t write tests. Write expectations instead, and have the machine generate random test cases.

There is a for that, called proptest.

It gives non-determinism in test execution, but with replayability (if a test case crashes, it does not simply crash randomly : you can relaunch it). It is used in im-rs, where there are tons of examples.

Another option is Model based testing:

  1. write a simplified model of a system
  2. apply random sequences of operations on both the implementation and the model
  3. if the model and implementation behave differently, it means we’ve found a problem
  4. the library will rerun the test, dropping out operations until it finds a minimal failing sequence (the machine just wrote a regression test for you!!!)

There’s a crate for that: model

Another option is fault injection. You make your system crash, and see how behaves. Sounds obvious ? Well the problem is not solved anyway. « in 58% of the catastrophic failures, the underlying faults could easily have been detected through simple testing of error handling code. », according to Yuan et al., OSDI 2014. Again, there are crates for that :

There were things about jepsen and TLA+, but by now if you are interested you should at least watch the slides.

He did not cover how to build such architectures, but provided some great references:

Learning how to learn

Link to the slide deck

In 2015, @vaidehijoshi learnt computer science on her own through her project basecs: study a CS topic every week for a year, and publish a blog post. She created her own curriculum through those 52 articles. It had unexpected side effects ! The writen baseCS turned into a podcast, and a video serie.

One the main lesson is that learning new things is extremely hard. So she studied the psychology & science behind learning. It led her to Richard Feynman, a famous phisicist who had a Nobel prize. Unsurprisingly, he also taught physics, but… he was also an artist, a philosopher, a bongo player, and many other things you don’t expect from a Nobel. Like, he particularly liked to break safes.
The thread through all his achievements is that he was super great at learning and understand things he was unconfortable with.

Let’s talk about how he learnt, and then I’ll summarize why it works well.

The Feynman Technique

Feynman left what is now called the Feynman Technique for learning, which has four steps:

  1. Identify the subject, the thing we want to learn

write down everything we know, and add things to this repository

  1. Explain it to someone who’d knw nothing about the topic (teach it as if it was to a 5yo child) => It forces you to use plain, simple terms

« When we speack without jargon, it frees us from hiding behind knowledge we don’t have ». We are pushed to go the the heart of a concept. Brevity is important and necessary, because childs don’t have a long attention span. Do not fear using diagrams. They were one of Feynman’s most important tools.

  1. identify any gaps in your understanding. Arguably the most important, it’s where the learning happens.

  2. Organize & simplify into a narrative. Use simple sentences for story telling, analogies…

Here is how he would explain atoms work, in a sentence:
« all things are made from atoms – little particles that move around in perpetual motion, attracting each other when they are a little distance apart, but repelling upon being squeezed into one another »

Feynman was nicknamed « The Great Explainer » (« the best teacher I never had », bill gates)=> maybe one of the important aspects of learning is to be able to teach things
Another is component is curiosity: he had a notebook « Notebook of things I don’t know about ». In his bio, Genius, he said he tried to find the essential kernels of each subjects.

This methodology:

  • tests our understanding
  • challenges our assumptions. Often, we you start learning a topic, you don’t know what you don’t know. « I’m smart enough to know that I’m dumb », said Feynman.
  • Reinforces what we do know
  • teaches us to be better explainers. By reframing stuff we know, and forcing us to teach things simply, we know that we know something once we are able to do that. Even for particularly complex topics.

Also, it makes knowledge accessible. People get interested to stuff when you explain it to them simply. Tech needs more great explainers !
As a side-effect, it makes our industry more diverse and inclusive.

Supercharging Rust Communities

Matt Gathu (@swissgathu) talked about what made the rust communities such a success.

  • Flat governance. There is no chain of command, no hierarchy. Teams are more or less independant. As a consequence, things get to move very fast, because there is not the bureaucracy of having someone to approve of a choice
  • Diversity & Inclusivity as a goal. Be deliberate about diversity and inclusion.
  • Having a roadmap allows to have a shared vision
  • Collective decision making. In the « RFC decision process », everyone has a say. Decisions are not made behind a closed door, you can always know why a given choise has been made.
  • Having a Code of Conduct. It’s a conscious effort to make sure everyone would be safe. People have joined because other communities were toxic to them.
  • Retrospectives. Take time to reflect on what you did: what is going right ? what can we improve ? This let’s you iterate faster.

It was also noted in another conference that the Rust’s language itself is really good due to the presence of great docs, a build system, package manager, memory safety…


Unable to load the Are You a Human PlayThru™. Please contact the site owner to report the problem.