Company has asked me to do a knowledge sharing session about Rust


The software consulting company I work for organizes biweekly "knowledge sessions" about technologies/techniques/frameworks/etc for whomever is interested about that particular topic. The general idea is that a single ~3 hour session is held where first the basics and underlying concepts are explained after which a practical part begins where attendees get some hands-on experience with the topic at hand.

Because apparently I never shut-up about Rust, the company has asked me to do a knowledge session about Rust, something which greatly excites me but at the same time I'm worried a bit about what to include and leave out from the session. Also what kind of practical assignment is doable for total newbies while at the same time shows off Rust's strengths?

So yeah, anyone got any experience with this or has ideas about how to best go about this kind of thing?

1 Like

What kind of programming experience will the newbies have?

Yes. What is the audience for this session?

I can imagine tailoring things very differently for a house full of Javascript/Pythonistas vs those experienced in C/C++. For example.

Pitching the idea to management is another story again.

I suspect that rather than never shutting up about Rust, which might tend to annoy people, it would work wonders to create something in Rust that is useful for the company and demonstrates its advantages. Even just a little thing, a Rust skunkworks project.

It would be hard to teach rust from scratch in 3 hours :stuck_out_tongue:

If I was doing this, I'd probably try to prepare some examples where the rust compiler prevents a mistake leading to a runtime error.

Probably something like a function returning result that isn't "handled" (unwrapped or matched). Or a match statement with a missing arm. You think of less obvious examples.

But you probably also want a good chunk of time to let people try coding their own simple programs. Maybe the guessing game from the book, maybe something related to your work like say, a web server. Make yourself available to answer questions, help explain the compiler errors and what not.

You could consider a run-down of useful/foundational crates as well. I think most programmers can read through the book themselves on their own if they want to after the session. But it can be a bit overwhelming to know that they should/could use thiserr, anyhow, serde, rand, chrono, ...

But go with your gut, they are your teammates, you would know what they will benefit from more than us. These are just some ideas off the top of my head.

Ooh, crazy thought. Not actually suitable for an intro session like this but it might be fun to split into teams and build something in separate pieces. Like, a binary team and a library(s) team. Green team writes a parser, Blue team does the logic, Red team adds command line args... And have teams pull in other teams' crates as a local/git dependency. It might impress them how they can use each others code so easily. Like, with type completions and stuff from rust analyzer.

Bound to end in tears, but could be fun :stuck_out_tongue:

Thanks for the replies everyone! The crowd will be quite diverse from C++ programmers, to pythonistas, to javascript devs. Though I'd say most of them are involved in developing web connected applications in some shape or form.

For this reason I thought I'd set up a small web server project with something like actix or rocket and let them fill in some response/request methods that are stubbed. It'd also be a neat opportunity to showcase the power of serde and the ecosystem around Rust.

1 Like

I'd definitely go with Rust causing compilation errors for things that other languages fail to detect:

  1. For those using dynamic languages, a quick mention of blatant errors not detected without type checking can be a useful first example. I think that nowadays even Pythonistas and javascripters are well acquainted with static linters / type checking and the advantages of it, so it may just be a reminder, but a nice introduction to the whole idea of static / compile-time checking. C / C++ programmers may have a smug on their face while seeing that, but just disregard it.

    • Optionally, you can remove C/C++'s programmers smug with an example of an invalidated pointer, the typical one being to create a vector of at least one element, to take a reference / pointer to it, to then append another element, and to try and print the value the reference points to. If you play with the vector's initial length, you ought to easily stumble upon a ridiculous read since the pointer is actually dangling.
  2. Then, if now the dynamic programmers are the ones making fun of that dangling pointer / reference bug, explain that pointers are not the only kind of reference entities, and that thus "general reference invalidation" bugs can occur in any language, even garbage-collected ones. An example I like to show is that of iterator invalidation, in Python:

    def append_all(dst: List[int], src: Iterable[int]):
        for elem in src:
    elems = [42]
    append_all(elems, elems)  # Infinite loop! (and, eventually, memory exhaustion!)
  3. At that point, take those two / three bug-featuring code snippets, and show them translated to Rust, and show the output of the compiler, which successfully catches all these three bugs at compile time.

  4. If you had the time, you could even talk about thread-safety bugs, which are also caught by Rust (e.g., can't share the same &mut i32 or &Cell<i32> across multiple threads).

    • This is even more relevant that is historically accurate: main motivation of Rust's initial development was for Mozilla to be able to make parts of their engine multi-threaded, which they had never managed to achieve, hence the "you must be this tall to do multi-threading" sign laid out at more than 2m high :grinning_face_with_smiling_eyes:

You can actually find snippets in a similar (but way shorter) presentation I did (in French) a while ago:

  • Key points about what makes Rust special are available in @mbrubeck's excellent blog post: Rust: A unique perspective . I thus personally suggest that &mut references be not called mutable references, but rather, compile-time-guaranteed unique references: this is how Rust is able to catch that many bugs, since many APIs in rust don't require a mutable reference but a unique one (e.g., pushing an element to a Vec requires a unique reference to it to guarantee there are no outstanding references to the vec nor its elements anywhere in the code, and that is guaranteed / checked by the compiler. If that doesn't make experienced C/C++ programmers salivate, I don't know what will :laughing:).

The key rule, for a 3-hour presentation, would be not to try to teach how to program in Rust, but rather, to showcase some of these statically caught bugs, as well as some success stories, especially involving performance (since the one laughing in the corner up until this point would be the fully functional languages, which are indeed great at catching / preventing many bugs thanks to their idioms (e.g., almost no mutation), but those idioms do come with performance penalties).

You can also mention initially overlooked things about a language, such as its tooling (Cargo: adding and using dependencies Just Works™; doc generation is easy and great, leading to an ecosystem or rather well documented crates; the cross compilation story is actually not bad at all, even if it still has some rough edges here and there (mainly when C dependencies are involved)), and its community.


Oh wow that's great, definitely gonna borrow heavily from your presentation! I especially like the Python example, because it looks so innocent on first glance.

If you have lots of prep time, I could imagine a very compelling presentation that shows the same program in many different languages, usually with a few "identical" bugs and how those bugs would be caught. But that sounds really hard.

Perhaps you can take some inspiration from:

Intro to the Rust programming language: Intro to the Rust programming language - YouTube

RustLatam 2019 - Niko Matsakis: What's unique about Rust?: RustLatam 2019 - Niko Matsakis: What's unique about Rust? - YouTube


Jon Gjengset's "Considering Rust": Considering Rust - YouTube

This topic was automatically closed 90 days after the last reply. We invite you to open a new topic if you have further questions or comments.