Talks to Watch

Rust: A Language for the Next 40 Years - Carol Nichols

367K views · May 9, 2019 · 55:08 · 0 HN recommenders · 3 mentions · discussed 2021–2024

Carol Nichols' Philly ETE 2019 talk on what makes Rust unique. It covers memory safety, how editions let the language evolve without breaking code, and who relies on Rust in production.

Why Hacker News points people here: Cited as a talk about Rust's long-term outlook, and as the source of the rail-safety analogy for software safety.

“here's a talk[0] where they aim to be relevant for the next 40 years”HN comment, 2024

What Hacker News said 3

Cites itlsllcMay 2021

“Carol Nichols mentioned this in a Rust video [0] and I thought it was pretty interesting!”

Rust talk where the linked resource was mentioned

Full comment

FYI, Carol Nichols mentioned this in a Rust video [0] and I thought it was pretty interesting! (yes, previously submitted to HN, but long ago with little traction so I think this is within HN guidelines). [0] this video

Cites itasonethDec 2021

Cited as source for analogy with rail safety progress

Full comment

In my opinion, what has been most harmful for evolution of the software engineering profession is the tendency to blame individual developers for not being infallible instead of fixing chronic failures in tooling, processes, and funding. The medical profession, aviation, even rail transportation [1] have all progressed past the point where avoidable failures are entirely the responsibility of the individual. Of course, there was resistance in those fields as well because some considered themselves an "above-average" doctor or pilot who didn't need safeguards, checklists, union rules, or laws. But it empirically improved outcomes. [1] this video

Cites itnorman784Mar 2024

“here's a talk[0] where they aim to be relevant for the next 40 years”

Rust talk about staying relevant for the next 40 years

Full comment

I think Rust team would still have a very small stdlib even if they have more funding, here's a talk[0] where they aim to be relevant for the next 40 years, in that time span there would be a lot of changes and to be backward compatible, you cannot have features in your stdlib that will be irrelevant or change in the next 5, 10, 15, 20 years. [0] this video

in “More powerful Go execution traces” · view on HN