Top Themesin the Discussion
| # | Theme | Brief Explanation & Supporting Quote |
|---|---|---|
| 1 | Complex Result shapes make Rust look “weird” |
The code shows a deeply nested type (Result<Option<Result<Message, WsError>>, Elapsed>) that represents multiple failure channels. joshka: “The weird‑looking Rust isn’t really Rust being weird, it’s the type telling the truth.” |
| 2 | “Vibe coding” via LLMs blurs the line between language quirks and bad generated code | Several participants argue that the odd code snippet is less about Rust itself and more about how the LLM produced it. nothinkjustai: “Um? Person vibe codes Rust. Output is stupid. The conclusion is either a) Vibe coding produces bad code b) Rust is weird” |
| 3 | Proper error handling idioms (custom error types) are preferred | The community notes that lingering with anonymous Result<(), ()> or Result<(),> invites lint warnings and that a dedicated error type is the idiomatic path. nasso_dev: “clippy has a lint against this iirc. it’s recommended to just create a custom error type… this lets you implement std::error::Error …” |
Takeaway: The discussion centers on the perception of Rust’s verbose error‑type syntax, the pitfalls of relying on LLM‑generated snippets, and the consensus that explicit, composable error types are the cleanest, most maintainable solution.