Miss Dada  🏳️‍⚧️

Thinking about what I want from the next RustConf: - Deep dive into rustc internals (frontend, MIR, LLVM use) - Design/impl of: Chalk, NLL, HKT, &c - Technical lore / historical view of rustc - Close comparison against the latest & greatest in C++ - Low-level impl of async/await

Most of those work best as blog posts. The problem with in depth technical talks like that is they're very easy to do poorly, a lot of selection committees avoid them for that reason.

Agree that many of them would be hard to do well. But, I'm thinking about something like what you'd get from a senior team member when learning a new code base: "hey, here's the big picture, here's why it's like this, if you wanted to do e.g. X, here's where you'd start looking".

Another example: "Hi, I'm X, I work on rustc codegen every day. Here's how I conceptualize the problem space, here's what I rely on LLVM for, here's where we're trying to go".

Unfortunately being a good programmer is not the same thing as being a good public speaker -- unless the speaker is already known to have given good technical talks it's risky to accept. And since most CFPs are blind you can't make that assessment.

I am not trying to argue that technical talks are bad, just that they are more frequently done poorly than other talks and are risky to accept for that reason.

I also think that it's rare for a technical talk to actually benefit from being a talk instead of a blog post. Of my own talks, the one I gave at Rustconf 2017 is one of the only ones that was actually better because it was a talk. Most of mine could have been blog posts

Yep, I hear you re risk, the CFP perspective, and orthogonality of expertise/speaking skill, and agree on all counts. That said, I *also* think there might be workarounds to encourage more (safely acceptable) talk submissions in the vein I'd like to see.