The Do's and Don'ts of Error Handling • Joe Armstrong • GOTO 2018

GOTO Conferences · 74K views · 2018 · 45:31

Open on YouTube

Distributed systemsFunctional programmingtalk

Why Hacker News recommends it

Recommended as a conceptual rather than code-heavy talk on failure recovery from Erlang's creator.

What it is

Joe Armstrong, inventor of Erlang, gives a GOTO Chicago 2018 talk on building fault-tolerant systems. He covers what to do and avoid when handling errors, arguing for letting processes fail and recover.

Recommended by 2 HN commenters across 2 different months, 2018 to 2022.

What Hacker News said

Recommends raghava · 2018-12 · on “Ask HN: Best talks of 2018?”

Blockchains Are a Bad Idea (James Mickens) [LINK] I find almost all from GOTO 2018 very insightful. [LINK] esp ones listed below. GOTO 2018 • The Do's and Don'ts of Error Handling • Joe Armstrong [this video] GOTO 2018 • Pragmatic Event-Driven Microservices • Allard Buijze [LINK] GOTO 2018 • Why Business Cases are Toxic • Chris Matts [LINK] GOTO 2018 • Unconditional Code • Michael Feathers [LINK]

Recommends frellus · 2022-12 · on “Phoenix 1.7 is View-less”

Also, if I may, recommend two videos to watch which is what got me into Elixir in the first place. 1. "The Soul of Elixir and Erlang" - [LINK] ; this fast-paced talk by Sasa Juric will highlight exactly what is special about Elixir/Erlang in terms of fault-tolerance and scalability 2. "Using the Beam to Fight COVID-19" - [LINK] ; this highlights a real-world use of Elixir and the speciality of how the BEAM works using an actor model which I found fascinating. Should get your excited about the possibilities of this language. 3. "The Do's and Don'ts of Error Handling" - [this video] ; this talk by Joe Armstrong, inventor of Erlang, again highlights the shift in thinking about error handling and fai

Cites sidmitra · 2021-05 · on “Automatically Make Unit Tests”

Type checking, compile-time errors won't check if the program you wrote is correct, only that it's internally consistent. That is an entirely different thing than checking for correctness. You do need a layer of tests that actually try to prove that given some input your program actually does what it's supposed to do. That is hard to automate. Joe Armstrong(of the Erlang fame), talks about this a bit here: [this video] I've pointed to a specific timestamp, but there might be more details somewhere else in that talk.