vrnvu

Jujutsu is immutable for public changes by default.

You can force changes with a ‘—ignore-inmutable’ flag.

Brings memories of when I did some chapters of HTDP2 to learn Lisp.

https://htdp.org/2024-11-6/Book/index.html

More accesible than SICP, highly recommended

Related https://www.romaglushko.com/blog/whats-aouth2/

Ditched git for jj a year ago. Never going back.

If anybody is hesitant give it a try!

I really liked the example in OP. I will give Deno and Dax a shot.

It's a cycle, design patterns, TDD, the latest framework or language. We keep chasing the next silver bullet, but there isn't one. There's no easy road.

Made me think. Every time I see a “Postman collection” or similar artifacts, my heart skips a bit. Use curl. Run it interactively in the terminal. When it works, move it into a shell script where you can simply check the status code. Voilà, magic! you’ve got yourself a simple but valuable integration test.

Instead of juggling dashboards and collections of requests, or relying on your shell history as Matklad mentions, you have it in a file that you can commit and plug into CI. Win-win.

At some point, that testing shell script can be integrated into your codebase using your working language and build tooling.

Love this version. I quoted the chapter about Leadership plenty of times at work.

`True leaders are hardly known to their followers.`

First. Love that more tools like Honeycomb (amazing) are popping up in the space. I agree with the post.

But. IMO, statistics and probability can’t be replaced with tooling. As software engineering can’t be replaced with no-code services to build applications…

If you need to profile some bug or troubleshoot complex systems (distributed, dbs). You must do your math homework consistently as part of the job.

If you don’t comprehend the distribution of your data, the seasonality, noise vs signal; how can you measure anything valuable? How can you ask the right questions?

> On the one hand, at lower-levels you want to exhaustively enumerate errors...

> On the other hand, at higher-levels, you want to string together widely different functionality from many separate subsystems without worrying about specific errors...

I feel like the Rust ecosystem of crates has naturally grown to handle these two ideas pretty well. `anyhow` for applications, `thiserror` for libraries.

> Metrics are simple, extremely cheap

You clearly haven’t seen our Datadog invoice :)

Jokes aside, I liked the idea of listing things by level of detail.

One related issue I run into all the time is how context gets lost when moving between layers. You start with host metrics, then Kubernetes wraps the host and overrides the tags, and suddenly you can’t filter host metrics by node anymore. Watch out.

My first thought: Controlling allocations and minding constraints... honestly, that's engineering stuff all services should care about. Not only "high-volume" services.

Sort of related. Jepsen and Antithesis recently released a glossary of common terms which is a fantastic reference.

https://jepsen.io/blog/2025-10-20-distsys-glossary

Everyone can talk and give opinions. The real question is if you can actually make a difference. I tell people there's a gap between knowing how to do something and actually doing it. And that gap is a big part of our engineering skills.

If I'm not going to change something, I'd rather not talk or give opinions.

Related: https://strangestloop.io/essays/things-that-arent-doing-the-...

>> Why is it not more popular?

Property, fuzzy, snapshot testing. Great tools that make software more correct and reliable.

The challenge for most developers is that they need to change how they design code and think about testing.

I’ve always said the hardest part of programming isn’t learning, it’s unlearning what you already know…

> Any time you are making decisions based on information that you know at compile time, you could apply this technique

I’d go further. Most business requirements are known at compile time.

Take the simplest example, dispatching a function based on a condition. If A then do_X, if B then do_Y.

People often reach for elaborate design patterns, dependency injection, or polymorphism here. But why? If the decision logic is static, don’t turn it into a runtime problem.

Inline the code. Move the ifs up. Write clear, specific functions that match your domain knowledge instead of abstracting too early…

Don’t make compile time problems runtime ones.