--- title: "Your Interface Has Two Channels" url: https://daily.dev/posts/your-interface-has-two-channels-cd2wefzni source_url: https://tomeraberba.ch/your-interface-has-two-channels type: article source: "Lobsters" published: 2026-06-12T11:56:29.854Z updated: 2026-08-16T23:50:57.933Z tags: ["architecture", "type-systems"] reading_time: 12 upvotes: 1 comments: 0 language: en --- > ## Documentation Index > Fetch the complete documentation index at: https://daily.dev/llms.txt > Use this file to discover all available pages before exploring further. # Your Interface Has Two Channels **[Lobsters](https://daily.dev/sources/lobsters)** · 12 min read · 1 upvotes · 0 comments ## Summary A framework for thinking about interface design through the lens of 'concern signaling', borrowed from telecommunications. Every interface concern either travels in-band (forcing the user to confront it) or out-of-band (allowing it to be silently ignored). The post illustrates this with examples across error handling (Rust Result vs JS exceptions vs Java checked exceptions), naming (HashSet vs TreeSet), union types (KeyboardEvent), required parameters (Java String charset), randomization (Go map iteration), and UI design (Slack threading). Six principles guide the choice between in-band and out-of-band: sensible defaults, safe defaults, actionability, self-revealing behavior, audience expectations, and proportionality. The core tradeoff: in-band concerns tax attention, out-of-band concerns risk silent bugs. ## Full article daily.dev links to this article rather than hosting it. Read it at the original source: ## Community take How the wider developer community reacted, aggregated from 3 discussions and 10 comments across lobsters, hackernews (as of 2026-08-16). **TL;DR:** Discussion centers on Lobsters, where people appreciate the writeup and its examples but repeatedly push back on whether the 'in-band/out-of-band' terminology itself is the right or useful framing. **Sentiment:** 25% positive · 55% mixed · 20% skeptical **The case for** - Several found the piece well-written and a helpful articulation of previously loose intuitions. - The GUI/Slack threading example was specifically called out as a highlight. - The discussion on 'actionability' was seen as a genuinely useful idea, with one commenter contrasting Zig's try favorably against Go's error checks. **The pushback** - Multiple commenters argued the in-band/out-of-band framing is applied inconsistently or too loosely, especially when extended beyond error handling to things like naming or iteration order. - One commenter suggested 'explicit/implicit' would be clearer terminology than 'in-band/out-of-band'. - A back-and-forth debate emerged over whether Go/Zig error returns count as in-band or out-of-band by the essay's own logic, with a proposed 'enforced/unenforced' framing suggested as less confusing. - A technical error was flagged: a code comment claimed undefined behavior for read() with fd == -1, which is incorrect per POSIX (though the author fixed it). **By community** - lobsters (mixed): Appreciation for the writing and examples is mixed with sustained critical pushback on whether the core framing actually holds up. - hackernews (mixed): No comments were available, so no discernible community take. **Hottest debate:** Whether the 'in-band/out-of-band' terminology is coherently applied, particularly around whether Go/Zig-style error returns count as in-band or out-of-band. **Open questions** - Can 'in-band' and 'out-of-band' be cleanly separated as distinct channels, or do they inevitably blur together as the article's critics argue? - Would an 'enforced/unenforced' or 'explicit/implicit' framing better capture the intended distinction? **Highlights** > The exhibits in the article and the surrounding discussion is mostly interesting, but I don't think the “in-band”⇋“out-of-band” framing is useful or properly applied. As I understand it, the author is trying to distinguish between the representation of error values in a language and the mechanisms by which the language enforces consideration of error values. This is an interesting distinction to discuss, especially in the comparison of programming languages. However, I'm not certain that these two are so trivially separably, and it's hard for me to agree with the conclusion that there are “two channels” for any given “interface.” Similarly, it seems like an over-extension to broaden “concerns” from the consideration of errors to consideration of arbitrary programme details, such as iteration order. (I don't find the provided `TreeSet` vs `HashSet` exhibit particularly convincing in this regards, nor do I think the suggestiveness of the naming is something that's useful to fit into the “in-band” framing.) As a result it's hard to say that “concern signalling” is a framing that's worth pursuing further, especially since “[one] might think every concern should be in-band” seems like a contraïndicated conclusion (i.e., that, in most framings that employ “in-band”⇋“out-of-band,” it seems like the conclusion is that “out-of-band” signallings or encodings are more desirable, given the inherent tendency toward ambiguity in “in-band” approaches.) The principles proposed seem mostly reasonable. Choosing good defaults is, obviously, important, and the article hints at how interface design requires a degree of meta-knowledge—not just “what does this do,” but “what will someone think or assume that this does.” I think discussing “actionability” is very useful (and could even be a counterpoint to language designs mandating error handling even in the absence of being able to do something meaningful about the error, other than propagating it. Recent experience leads me to believe that Zig's `try` is a better overall design here than Go's `if err != nil`.) > — [dutc on lobsters · 2 points, 1 comments](https://lobste.rs/s/khavt4/your_interface_has_two_channels#c_cxok1k) > The tricky thing about discussions of “in-band” vs “out-of-band” encodings is that they are an extremely artificial projection onto the “real world.” As far as I can measure it, the reality in which we reside is comprised of a single (continuous?) medium; thus, strictly speaking, it seems that all encodings are necessarily “in-band.” It is only within a certain context that this classification is viable, and it's clear that it is only in a subset of those contexts that the classification is meaningful. For example, if we compare how errors are represented in, say, Go, Zig, Python and C, we see the a meaningful distinction between “in-band” and “out-of-band” encodings. In a C programme, it is very likely to see errors encoded “in-band,” since other formulations are simply very clumsy. Thus, we will see signatures returning a signed `int` for quantities that represent counts, so that we can encode an error as a `-1`. The article correctly mentions that this style of error reporting may lend itself to misuse by a human (who may incorrectly assume the choice of return type was not deliberate or who may simple miss this detail); however, from an encoding perspective, this choice is not strictly *wrong* in that errors and non-errors are unambiguously represented. However, the tendency of the C programmer to rely on this encoding makes it very easy for them to mistakenly use an “in-band” encoding even in the presence of an ambiguity, and we, indeed, see this mistake commonly made in library functions. The “in-band”⇋“out-of-band” framing is very useful here, because it gives us an operational process by which we can both identify and qualify the risk of ambiguity and employ a set of well-known techniques to eliminate it (e.g., partitioning, prefixing, quoting/escaping, &c.) In Zig and Go, error values are often represented with an “out-of-band” encoding—either as a union type or as a tuple type—and the exact choice of this encoding is largely immaterial to its correctness. Both allow us to represent error values in a completely unambiguous fashion. In Python, we may represent the error as an `Exception`, which is an “out-of-band” encoding which is unambiguous as well. How these three mechanisms interact with the features of the language is an important aspect of their design (since a Shell script's error handling, that occurs in the form of a non-zero exit code and bytes emitted to `stderr` is not particularly different than Python's approach in how unambiguous of an encoding it is; it is different primarily because Python `Exception`s mandate the user's attention and the latter does not.) > — [dutc on lobsters · 2 points, 1 comments](https://lobste.rs/s/khavt4/your_interface_has_two_channels#c_409ovh) > > In Zig and Go, error values are often represented with an “out-of-band” encoding—either as a union type or as a tuple type By the essay’s lingo, this is in-band *concern* signalling: you can’t proceed without acknowledging the concern (well this is not quite true of go but we’ll ignore that). > — [masklinn on lobsters · 2 points, 1 comments](https://lobste.rs/s/khavt4/your_interface_has_two_channels#c_zjomrg) > I’m not entirely convinced by the ‘in-band/out-of-band’ terminology and would probably have preferred ‘explicit/implicit’. That aside, it’s well worth a read. > — [klingtnet on lobsters · 1 points](https://lobste.rs/s/khavt4/your_interface_has_two_channels#c_tm1mbz) > > // Undefined behavior if `fd == -1`. > > read(fd, buf, sizeof(buf)); It’s not undefined behavior according to either POSIX or any other standards that regulate read(). Actually, POSIX says it shall fail with EBADF in this case. > — [shdown on lobsters · 3 points, 1 comments](https://lobste.rs/s/khavt4/your_interface_has_two_channels#c_trbjo6) **Source threads** - [lobsters](https://lobste.rs/s/khavt4/your_interface_has_two_channels) · 28 points · 10 comments - [hackernews](https://news.ycombinator.com/item?id=48490283) · 4 points · 0 comments - [hackernews](https://news.ycombinator.com/item?id=48659033) · 3 points · 0 comments ## Similar posts on daily.dev - [The Two Abstractions of System Design: Hide or Reduce](https://daily.dev/posts/the-two-abstractions-of-system-design-hide-or-reduce-nrvfw7szp) · Metadata · 1 upvotes · 0 comments - [Intuitive Interfaces: What Actually Makes Them Clear](https://daily.dev/posts/intuitive-interfaces-what-actually-makes-them-clear-mzdcjxau3) · UX Planet · 64 upvotes · 0 comments - [Interface is everything, and everything is an interface](https://daily.dev/posts/interface-is-everything-and-everything-is-an-interface-wgdp1yjtm) · Stack Overflow Blog · 2 upvotes · 1 comments --- Tags: [#architecture](https://daily.dev/tags/architecture), [#type-systems](https://daily.dev/tags/type-systems) [View this post on daily.dev](https://daily.dev/posts/your-interface-has-two-channels-cd2wefzni)