Structured logging with slog • Hacker News Board

Re: Structured logging with slog

#171

Post by morelisp » Fri, Aug 25, 2023, 5:51 PM UTC

kiitos wrote: post #170

morelisp wrote: post #169

Earlier quoted context omitted.

Reasoning about control flow is much easier when you have so much less control flow because you just let it crash.

What an insane way to think about programming. A service should never crash in response to a runtime error, or any kind of business logic conditional! Crashes are not normal, they signal critical problems and/or programmer errors. A service that crashes in production is a priority-0 bug that needs to be addressed and fixed immediately. More specifically, if you can't trust that calling a function will always return e…

I'll pray for you.

(Consensus protocols are your most bizarre example because they're one of the definitional things that needs to keep working no matter how hard or fast a non-quorum of members dies.)

Re: Structured logging with slog

#172

Post by kiitos » Fri, Aug 25, 2023, 6:36 PM UTC

morelisp wrote: post #171

kiitos wrote: post #170

Earlier quoted context omitted.

What an insane way to think about programming. A service should never crash in response to a runtime error, or any kind of business logic conditional! Crashes are not normal, they signal critical problems and/or programmer errors. A service that crashes in production is a priority-0 bug that needs to be addressed and fixed immediately. More specifically, if you can't trust that calling a function will always return e…

I'll pray for you. (Consensus protocols are your most bizarre example because they're one of the definitional things that needs to keep working no matter how hard or fast a non-quorum of members dies.)

Likewise.

Re: Structured logging with slog

#173

Post by richardwhiuk » Tue, Aug 29, 2023, 2:07 PM UTC

masklinn wrote: post #130

masklinn wrote: post #117

Earlier quoted context omitted.

It can do that because Rust’s macros can have their own mini language at the top level, and can transform that into whatever data structure they want under the cover. For better or for worse, Go doesn’t have that.

Also funny story: in Perl “,” can be spelled “=>” specifically for this sort of use cases, when you write my %hash = ( Foo => “bar”, Baz => “qux”, ); the behaviour is no different than my %hash = ( Foo, “bar”, Baz, “qux”, ); it’s just that a literal plist in a hash context is interpreted as a hash. Hence “=>” being called “fat comma” in perl. Which means you can writer my %h = (a => b => c => d); or my %h = (a, b =>…

That all sounds questionable.

Re: Structured logging with slog

#174

Post by kiitos » Tue, Aug 29, 2023, 9:39 PM UTC

morelisp wrote: post #169

kiitos wrote: post #168

Earlier quoted context omitted.

If you allow arbitrary code to terminate the process, then the control flow of the program is effectively non-deterministic, and impossible to model, or even really understand. Software written in this way is fundamentally unreliable.

Reasoning about control flow is much easier when you have so much less control flow because you just let it crash.

Erlang/OTP expects its processes might crash in response to invalid user input. There, crashing is basically normal and relatively common. In contrast, supervisors like systemd and Docker expect their processes to be generally resilient to bad user input, and to crash only in response to much more critical issues. There, crashing is basically abnormal and uncommon. And assumptions are baked into the entire execution stack of each orchestrator.

Crashing is an error handling strategy only if you know a priori that your code will be running in an execution environment that treats crashes as normal. Such environments are exceptions, not the rule.