Conversation

Notices

1. Embed this notice
   Wolf480pl (wolf480pl@mstdn.io)'s status on Wednesday, 19-Nov-2025 22:34:09 JST Wolf480pl

   Cloudflare published a very good article exolaining how yesterday's outage happened.

   https://blog.cloudflare.com/18-november-2025-outage/

   I encourage everyone to read it.

   I also think people are focusing on that particular unwrap() too much, and not enough on a bigger picture: lack of fallbacks

   Without fallbacks at the interfaces between different subsystems, there's nothing to stop an error in one place from cascading throughout the whole infra

   Config parsing is not the only place where such fallback was missing

   • Embed this notice
     Haelwenn /элвэн/ :triskell: (lanodan@queer.hacktivis.me)'s status on Wednesday, 19-Nov-2025 22:34:07 JST Haelwenn /элвэн/ :triskell:

     in reply to

     • Haelwenn /элвэн/ :triskell:
     @wolf480pl Also the config parsing thing reminds me of why I think critical services should have this kind of split: human-rewritable configuration files allowing to produce machine-oriented files.
     
     That way you can have the config being thoroughly validated prior to it being applied, which can even include additional linters or checks against other data (like checking for matching entries in DNS).
   • Embed this notice
     Haelwenn /элвэн/ :triskell: (lanodan@queer.hacktivis.me)'s status on Wednesday, 19-Nov-2025 22:34:08 JST Haelwenn /элвэн/ :triskell:

     in reply to
     @wolf480pl Yeah, unwrap thing seems like a normal thing to me, services can and *will* crash/abort/segfault/… or even get killed by stuff like the oom-killer.
     It's an architectural failure to turn that into such a big issue, plus an organisational failure in terms of deployments.
   • Embed this notice
     Phantasm (phnt@fluffytail.org)'s status on Wednesday, 19-Nov-2025 22:36:56 JST Phantasm

     in reply to

     • Haelwenn /элвэн/ :triskell:
     @lanodan @wolf480pl On the other hand it is explicitly mentioned in Rust docs that you shouldn't use unwrap in production code, while the correct way to do error handling is more complicated and less intuitive, which makes me think that Rust error handling isn't the greatest. Also a compiler flag to throw errors on .unwrap when compiling prod binaries would be useful.
     
     It feels the same way as Golang in this regard, where error handling was "cooked in the pot" completely, but worse.
     Haelwenn /элвэн/ :triskell: likes this.
   • Embed this notice
     Haelwenn /элвэн/ :triskell: (lanodan@queer.hacktivis.me)'s status on Wednesday, 19-Nov-2025 22:40:49 JST Haelwenn /элвэн/ :triskell:

     in reply to

     • Phantasm
     @phnt @wolf480pl For Go I'd even say the error handling was cooked in pot. :weed:
     
     And I've read on fedi there's a nightly (of course it's nightly) compiler flag for it, which to me makes sense to check against, humans are lazy and forgetful, and corporate workflows sometimes are so bad it's a mess to apply proactive/small fixes, …
   • Embed this notice
     Phantasm (phnt@fluffytail.org)'s status on Wednesday, 19-Nov-2025 22:41:03 JST Phantasm

     in reply to

     • Haelwenn /элвэн/ :triskell:
     • Phantasm
     @lanodan @wolf480pl Kinda makes me wonder why they didn't rip off more of Erlang when they clearly got inspired by it. Error handling there feels much more natural and doesn't break function structure.
     Haelwenn /элвэн/ :triskell: likes this.
   • Embed this notice
     Haelwenn /элвэн/ :triskell: (lanodan@queer.hacktivis.me)'s status on Wednesday, 19-Nov-2025 22:54:51 JST Haelwenn /элвэн/ :triskell:

     in reply to

     • Haelwenn /элвэн/ :triskell:
     • Phantasm

     @phnt @wolf480pl In fact from what I remember, Go error handling is basically just at the level of C now thanks to [[nodiscard]] of C23.
     Or maybe even worse as GCC and LLVM includes static analyzers, so it could approach languages with more proper checks on the error handling being actually handled rather than say thrown in a variable and never checked.

   • Embed this notice
     Phantasm (phnt@fluffytail.org)'s status on Wednesday, 19-Nov-2025 23:04:47 JST Phantasm

     in reply to

     • Haelwenn /элвэн/ :triskell:
     • :blank:
     @i @wolf480pl @lanodan The syntax is already horrible, you can't make it much worse :D
     That's why I said that a compiler flag for prod binaries would be useful. You can keep your .unwrap and .expect, but they'll be gated behind reachability in debug build type.
     
     I've also read on here that .expect would be better and prevented this which is false. That also panics while giving you a specified error instead and programs like this shouldn't panic when they can't parse config files while reloading configuration.
     Haelwenn /элвэн/ :triskell: likes this.
   • Embed this notice
     :blank: (i@declin.eu)'s status on Wednesday, 19-Nov-2025 23:04:48 JST :blank:

     in reply to

     • Haelwenn /элвэн/ :triskell:
     • Phantasm
     @phnt @wolf480pl @lanodan you can give a man his fp, but you can't get him to stop being terse
   • Embed this notice
     Ignas Kiela (ignaloidas@not.acu.lt)'s status on Wednesday, 19-Nov-2025 23:20:01 JST Ignas Kiela

     in reply to

     • Haelwenn /элвэн/ :triskell:
     • Phantasm

     @phnt@fluffytail.org @lanodan@queer.hacktivis.me @wolf480pl@mstdn.io Rust's error handling is fine, it's more of a culture around it that sometimes isn't because of functional purists leaking in
     
     the unwrap recommendation is roughly equivalent to saying "you should always wrap your code in a try: else:" in python - it simply disregards how many people build software, where just dying on failure to do something is not only acceptable, but the norm.

     Haelwenn /элвэн/ :triskell: likes this.
   • Embed this notice
     Wolf480pl (wolf480pl@mstdn.io)'s status on Thursday, 20-Nov-2025 00:03:25 JST Wolf480pl

     in reply to

     • Haelwenn /элвэн/ :triskell:

     @lanodan
     Yeah, parsing the config with the same parser as the bot filtering service uses before deploying it would've likely caught it.

     Also, I've seen many classic Unix daemons that have a config validation subcommand that you're supposed to run before telling the main process to reload its config.

     As for human re-writable - sure, but in this case version-controlled would've helped more.

   • Embed this notice
     Wolf480pl (wolf480pl@mstdn.io)'s status on Thursday, 20-Nov-2025 00:04:36 JST Wolf480pl

     in reply to

     • Haelwenn /элвэн/ :triskell:
     • Phantasm

     @lanodan
     Go error handling is a ripoff of Lua's error handling, and Lua is a very "here's the minimal set of things a language needs to do, go build the rest on top yourself"
     @phnt

     Haelwenn /элвэн/ :triskell: likes this.
   • Embed this notice
     Wolf480pl (wolf480pl@mstdn.io)'s status on Thursday, 20-Nov-2025 08:15:04 JST Wolf480pl

     in reply to

     • Haelwenn /элвэн/ :triskell:
     • Ignas Kiela
     • Phantasm

     @ignaloidas
     Still, unless you can locally prove (using the invariants you available in that particular context) that the error cannot happen, you should pass the error to the caller instead of unwrapping, because the caller may be better equipped to handle it - eg. by falling back to the old config.

     But if passing the error to the caller is as simple as a question mark 90% of the time, then I agree Rust's error handling is fine.

     @lanodan @phnt

     Haelwenn /элвэн/ :triskell: likes this.
   • Embed this notice
     Ignas Kiela (ignaloidas@not.acu.lt)'s status on Thursday, 20-Nov-2025 08:15:06 JST Ignas Kiela

     in reply to

     • Haelwenn /элвэн/ :triskell:
     • Phantasm

     @wolf480pl@mstdn.io @lanodan@queer.hacktivis.me @phnt@fluffytail.org this is type purity coming into effect more than anything else tbh
     
     Sure, it's "forced", but considering that most of the time the "handling" will be the using the question mark operator which passes it up to the caller - congratulations, you have Python exceptions, except every call that could throw has a question mark next to it, and some handling at the top level for an error message at best
     
     unwrap is basically equivalent to "aggressively" not handling the error, assuming nothing above it will.

   • Embed this notice
     Wolf480pl (wolf480pl@mstdn.io)'s status on Thursday, 20-Nov-2025 08:15:07 JST Wolf480pl

     in reply to

     • Haelwenn /элвэн/ :triskell:
     • Ignas Kiela
     • Phantasm

     @ignaloidas
     Not quite.

     In python, if you call a function and do nothing about error handling, any exceptions will propagate to your caller, who can handle them.

     On Rust, if you do nothing, it won't compile.
     But if you unwrap, any errors from the called function will crash right in the unwrap, without giving your caller a chance.

     AFAIK propagating the error to your caller requires some weird type casting or sth...
     @lanodan @phnt

   • Embed this notice
     Haelwenn /элвэн/ :triskell: (lanodan@queer.hacktivis.me)'s status on Thursday, 20-Nov-2025 08:26:58 JST Haelwenn /элвэн/ :triskell:

     in reply to

     • Ignas Kiela
     • Phantasm

     @ignaloidas @wolf480pl @phnt Can mean a bit of API-churn but I think that's fine, much better than having a library panic on unhandled errors.

     That said I have barely written any Rust, so maybe it's a pain in the ass to deal with errors in it.

     Like in Hare you avoid a lot of API churn by making a union type for the errors your library/module has, and then write an strerror function for it, so caller can have a somewhat generic fallback, and it's not erasing the types so caller can still opt into handling specific errors.

   • Embed this notice
     Ignas Kiela (ignaloidas@not.acu.lt)'s status on Thursday, 20-Nov-2025 08:27:00 JST Ignas Kiela

     in reply to

     • Haelwenn /элвэн/ :triskell:
     • Phantasm

     @wolf480pl@mstdn.io @lanodan@queer.hacktivis.me @phnt@fluffytail.org the problem is that pushing errors up makes some stuff annoying to deal with, because errors are in the type signatures, and you can get into an API design hell if you refuse to use unwrap
     
     it's there entirely to deal with this

   • Embed this notice
     Haelwenn /элвэн/ :triskell: (lanodan@queer.hacktivis.me)'s status on Thursday, 20-Nov-2025 08:40:34 JST Haelwenn /элвэн/ :triskell:

     in reply to

     • Ignas Kiela
     • Phantasm

     @wolf480pl @phnt @ignaloidas Dependencies don't have much difference compared to stdlib modules.

     Like fs here could be a module from a dependency or from stdlib (thankfully it's stdlib):

     const ent: fs::dirent = match (fs::next(iter)) { case let ent: fs::dirent => yield ent; case let e: fs::error => fmt::errorfln("deblob: error: Failed walking directory '{}': {}", dirname, fs::strerror(e))?; break; case done => break; };

     (Snippet from https://hacktivis.me/git/deblob/file/main.ha.html#l333 )

   • Embed this notice
     Wolf480pl (wolf480pl@mstdn.io)'s status on Thursday, 20-Nov-2025 08:40:35 JST Wolf480pl

     in reply to

     • Haelwenn /элвэн/ :triskell:
     • Ignas Kiela
     • Phantasm

     @lanodan @phnt @ignaloidas
     How do you handle errors from your dependencies?

   • Embed this notice
     Haelwenn /элвэн/ :triskell: (lanodan@queer.hacktivis.me)'s status on Thursday, 20-Nov-2025 08:43:36 JST Haelwenn /элвэн/ :triskell:

     in reply to

     • Ignas Kiela
     • Phantasm
     @wolf480pl @phnt @ignaloidas Are you not familiar with type unions?
   • Embed this notice
     Wolf480pl (wolf480pl@mstdn.io)'s status on Thursday, 20-Nov-2025 08:43:37 JST Wolf480pl

     in reply to

     • Haelwenn /элвэн/ :triskell:
     • Ignas Kiela
     • Phantasm

     @lanodan @phnt @ignaloidas
     wait... so it's creating a new error with an error message that contains the fs::error's strerror, but not the fs:error itself?

   • Embed this notice
     Haelwenn /элвэн/ :triskell: (lanodan@queer.hacktivis.me)'s status on Thursday, 20-Nov-2025 08:47:05 JST Haelwenn /элвэн/ :triskell:

     in reply to

     • Ignas Kiela
     • Phantasm

     @wolf480pl @phnt @ignaloidas Ah, fmt::errorfln is just printing a formatted line to stderr, nothing special in it for error handling.
     And strerror functions takes specific errors in and returns a string, like the C strerror.

   • Embed this notice
     Wolf480pl (wolf480pl@mstdn.io)'s status on Thursday, 20-Nov-2025 08:47:06 JST Wolf480pl

     in reply to

     • Haelwenn /элвэн/ :triskell:
     • Ignas Kiela
     • Phantasm

     @lanodan @phnt @ignaloidas
     I am, but I'm not familiar with what fmt::errorfln does

   • Embed this notice
     mr64bit (mr64bit@p.mr64.net)'s status on Thursday, 20-Nov-2025 08:48:08 JST mr64bit

     in reply to

     • Haelwenn /элвэн/ :triskell:
     • Ignas Kiela
     • Phantasm
     @lanodan @phnt @wolf480pl @ignaloidas It's a common pattern in Rust, and dead simple. You can define an error enum that represents your code's failure modes, as well as errors from other libraries it can call.
     
     https://play.rust-lang.org/?version=stable&mode=debug&edition=2024&gist=bddcfa40e2bd072cc1cd3be5b92c17cd
     
     (there's some boilerplate if you don't use a macro, but thiserror is pretty ubiquitously used)
     Haelwenn /элвэн/ :triskell: likes this.
   • Embed this notice
     Haelwenn /элвэн/ :triskell: (lanodan@queer.hacktivis.me)'s status on Thursday, 20-Nov-2025 09:13:24 JST Haelwenn /элвэн/ :triskell:

     in reply to

     • Ignas Kiela
     • Phantasm

     @wolf480pl @phnt @ignaloidas You'd end up with SDL defining an error type, and a strerror function (although more likely in submodules of SDL, that library is big enough to be a toolkit).

     And callers would match against sdl::error to call sdl::strerror, and still be able to also match against say sdl::no_display error since a type union doesn't erases.

   • Embed this notice
     Wolf480pl (wolf480pl@mstdn.io)'s status on Thursday, 20-Nov-2025 09:13:25 JST Wolf480pl

     in reply to

     • Haelwenn /элвэн/ :triskell:
     • Ignas Kiela
     • Phantasm

     @lanodan @phnt @ignaloidas
     Ok, so the error types from your dependencies get exposed as part of your API?

     What if you wanted to confine a dependency, such that its types are not part of your API?

     Eg. imagine you're writing SDL, and you want to abstract away all the different graphics stacks that you support - how do you do that?

   • Embed this notice
     Wolf480pl (wolf480pl@mstdn.io)'s status on Thursday, 20-Nov-2025 09:13:26 JST Wolf480pl

     in reply to

     • Haelwenn /элвэн/ :triskell:
     • Ignas Kiela
     • Phantasm

     @lanodan @phnt @ignaloidas
     so in which line does the snipped you posted propagate an error from `fs` to the snippet's caller?

   • Embed this notice
     Haelwenn /элвэн/ :triskell: (lanodan@queer.hacktivis.me)'s status on Thursday, 20-Nov-2025 09:13:26 JST Haelwenn /элвэн/ :triskell:

     in reply to

     • Ignas Kiela
     • Phantasm

     @wolf480pl @phnt @ignaloidas This one handles the errors it receives from fs, although it does propagates errors from fmt::errorfln to the caller, the ? right before ; does this.

     Signature of fmt::errorfln is: fn errorfln(fmt: str, args: field...) (size | io::error);

     And that snippet is from fn check_dir(dirname: str) (void | nomem | errors::invalid | io::error) = {

     So caller is aware that it'll get io::error.

     And code around check_dir could also look like so:

     type direrr = !void; // add custom error for sake of example completeness type error = (direrr | nomem | errors::invalid | io::error); fn strerror(err: error) const str = { match(err) { case let err: io::error => io::strerror(err); case direrr => return "directory error"; // handle other cases }; }; fn check_dir(dirname: str) (void | error) = {
   • Embed this notice
     Wolf480pl (wolf480pl@mstdn.io)'s status on Thursday, 20-Nov-2025 09:44:40 JST Wolf480pl

     in reply to

     • Haelwenn /элвэн/ :triskell:
     • Ignas Kiela
     • Phantasm

     @lanodan @phnt @ignaloidas
     ok, so if SDL were to get an fs::error when trying to open a wayland socket, how would it turn that into sdl::no_display?

   • Embed this notice
     Haelwenn /элвэн/ :triskell: (lanodan@queer.hacktivis.me)'s status on Thursday, 20-Nov-2025 09:44:40 JST Haelwenn /элвэн/ :triskell:

     in reply to

     • Ignas Kiela
     • Phantasm

     @wolf480pl @phnt @ignaloidas Assuming you mean throwing the propagation because wayland is an implementation detail but still has effects on the cross-platform function:

     export type no_display = !void; export type error = (no_display); export fn strerror(error) = { match(error) { return no_display => return "No Display"; }; }; export fn open_display() = (io::handle | error) = { let waysock = match(fs::open(…)) { case let f: io::handle => yield f; case let err: io::error => fmt::errorfln("SDL: error: Failed to open wayland socket: {}", io::strerror(err))!; return no_display; }; };
   • Embed this notice
     kc :blobcatheart: (kc@mastodon.dragoncave.dev)'s status on Thursday, 20-Nov-2025 19:50:37 JST kc :blobcatheart:

     in reply to

     • Haelwenn /элвэн/ :triskell:
     • mr64bit
     • Ignas Kiela
     • Phantasm

     @wolf480pl
     On normal enums no, on enums marked with `#[non_exhaustive]`, yes.

     @mr64bit @phnt @ignaloidas @lanodan

     Haelwenn /элвэн/ :triskell: likes this.
   • Embed this notice
     Wolf480pl (wolf480pl@mstdn.io)'s status on Thursday, 20-Nov-2025 19:50:38 JST Wolf480pl

     in reply to

     • Haelwenn /элвэн/ :triskell:
     • mr64bit
     • Ignas Kiela
     • Phantasm

     @mr64bit
     is adding another variant to an enum you return a backwards-compatible change?
     @phnt @ignaloidas @lanodan

   • Embed this notice
     Wolf480pl (wolf480pl@mstdn.io)'s status on Thursday, 20-Nov-2025 19:50:39 JST Wolf480pl

     in reply to

     • Haelwenn /элвэн/ :triskell:
     • mr64bit
     • Ignas Kiela
     • Phantasm

     @mr64bit
     Nice.

     If you were to some day replace std::io with some other IO library that has a different error type, would that change your API?
     @phnt @ignaloidas @lanodan

   • Embed this notice
     mr64bit (mr64bit@p.mr64.net)'s status on Thursday, 20-Nov-2025 19:50:39 JST mr64bit

     in reply to

     • Haelwenn /элвэн/ :triskell:
     • Ignas Kiela
     • Phantasm
     @wolf480pl
     Yes, as the inner enum fields are the same visibility as the enum itself. I guess you could just add another variant in that case.
     
     @phnt @ignaloidas @lanodan Yes,