HackerTubewatch
Surprise me
Frame from Cory Benfield - Building Protocol Libraries The Right Way - PyCon 2016 Plays via YouTube's privacy-enhanced embed

Cory Benfield - Building Protocol Libraries The Right Way - PyCon 2016

7 videos recommended on HN
YouTube
2 HN users recommended this talk2 months2016–2024 score 2
Years with an HN recommendation, 2007–2026

HN points to it as the foundational argument for sans-I/O protocol library design.

Cory Benfield's PyCon 2016 talk on building protocol libraries that can be reused widely, using the Python Hyper HTTP project as the example. He argues for separating protocol parsing from I/O.

“give some really great brainfood about the way currently all kinds of network protocols are implemented” (HN, 2017)

2 recommendations · 1 citations · Talks · intermediate

3 Hacker News comments

From the HN archive; up to 20 kept per video, favoring different commenters. Recommendations first.

@geofft Jun 2016 Recommends
on HN thread Accidentally nonblocking
Read more
Cory Benfield's PyCon talk last week, "Building Protocol Libraries the Right Way" ( [this video] ), makes the argument that a large number of problems can be traced to not cleanly separating responsibilities of actually physically doing I/O and making semantic sense of the bytes. His primary worry was about reimplementing things like HTTP many times, once for each I/O framework (why do Twisted, Tornado, and asyncio all have their own HTTP implementation?). But it seems the same problem can be seen here: every single part of the code thinks it knows how to actually retrieve data from the network, so it interacts with the network on its own, causing nested polling and similar awkwardness. If every part of the event-processing code thinks it knows how to do network I/O, you have many more opportunities for getting network I/O wrong. If xterm were designed so that e.g. xevents() had only the responsibility of fetching bytes from the X socket and do_xevents() and everything else had only the responsibility of handling bytes from an buffer, there would be no temptation to poll in two different functions. Only one function would even know that the byte source is a socket; the rest just know about the buffer.
Argues for separating I/O from protocol parsing across frameworks.
@mindcrash Dec 2017 Recommends
on HN thread Ask HN: Separate Logic from IO
In some cases it is very practical, even in other (non functional) programming languages. For example, [link] (and its accompanying talk [this video] ) give some really great brainfood about the way currently all kinds of network protocols are implemented, and the benefits of separating the protocol (Logic) from the actual implementation (IO). You might also want to query Google or DDG for "Free monads" if you want to implement a similar layered approach in a functional language such as Scala or Haskell.
Great brainfood on separating protocol logic from IO.

Citations, criticism and jokes

Video list and Hacker News comment labels from HackerTube (prompted by @karpathy), released under ODC-By 1.0, built on the open-index/hacker-news archive. Hacker News data is provided by Y Combinator; comments remain the work of their authors. Video titles, channel names and thumbnails belong to their creators and are shown via YouTube. HackerTube Watch is an unofficial edition. Data export of 2026-10-31.

Keyboard shortcuts

/
Search
j k
Next / previous video
r
Surprise me
l
Like (video page)
w
Watch later (video page)
?
This help
Esc
Close