Rust Before Main - Ryan Levick - Rust Linz, July 2022

When you run a Rust program, you may be tempted to think that the first code to execute is the main function. However, this is far from the case. In this talk, we'll explore what happens before the main function runs. By the end, you'll have a deeper understanding of what happens before the bits that rustc compiles your program into ever run.

Ryan has been writing Rust since around version 0.10. He now focuses on Rust full time at Microsoft. When he's not doing Rust, he enjoys cooking, traveling and exploring Berlin where he lives.

Resources:

[cthutu]

It would be nice if the resource links at the end of the talk were in the youtube description too. But great talk btw!

[leonie]

Wow, this was amazingly informative! Thank you so much, Ryan!
Especially awesome: You always help to orient after each section, and at the end of the talk. This helps tremendously to put the pieces together in one's head!

[cloudsquall]

Really really amazing talk! One of the rare ones where you get taught things you didn't even know you wanted to learn. Ryan is a treasure, for real. Many thanks!

[rauno]

5:30 in, and already very valuable! Thanks, Ryan!

[Mane]

Incredible talk, would love to learn more in this direction, keep it coming Ryan!

[blenderpanzi]

Small note: "All the shell does is to call exec*()." It calls fork() before it, because exec*() _replaces_ the currently running process with the new binary. And between fork() and exec*() the shell might set up stdio redirection and such.

Linux does not have a system call that does both in one, which can be a problem for huge processes, because while the cloned memory is copy on write, the page-tables need to be copied, and if those alone are huge it is still a heavy operation. They say its a problem for PostgreSQL and why you should limit connections to your PostgreSQL server? There is the posix_spawn() function, but under Linux it just does fork()+exec*(). Some BSDs actually implement posix_spawn() as system call. I think Windows only has something like that and no way to exec*() without spawning a new process.

[XiaoZhang-xa]

One of the best, if not the best, I’ve watched on YouTube so far. Thanks!

[Shan]

This was extraordinarily illuminating. Thank you! I’m grateful

[barower]

9:06 why does cargo/rustc have to statically embed entirety of standard library into final binary, and not only used elements, since it should know which of those are actually used?

[VmA]

Wow, such a nice intro. After half a minute I am really interested in the content of the talk.

[simonfarre]

The vdso basically is a couple of system calls that are loaded into the process space so that the application can call those without having to actually make the system call "dance" as it were, no going into kernel space for it. For instance, I think gettimeofday or something like that, lives there. Why is this important? Its because system calls are a lot more costly than normal user space function calls. So, pulling these small syscalls into the process space, removes the need for context switching back and forth between user space and kernel space, making those calls almost equivalent to a normal function call.

[CjqNslXUcM]

I like that he basically gives therapy for people with impostor syndrome for the first few minutes.

[elgalas]

"My life is very much consumed by Rust" :)

[alter_igel]

This is a great resource, thanks a lot!

[edgeeffect]

As an assembly language geek and a fan of `#![no_std]` ... this was always a favourite topic of mine even before Rust came along.
I love that "Not necessarily wrong... just a bit too simple".

[docteurklein]

I think it spells exec-ve (arg Vector and Env), not exe-cve

[thingsiplay]

__start -> __lib_start_main -> main

But if we don't have a main in our Rust program anymore, how can this work?

[ozanmuyes]

Great presentation, thank you. Also very informative content.