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.

> when you can't tell what's blocking and what isn't.

Isn't that exactly why they're making IO explicit in functions? So you can trace it up the call chain.

Shocking to hear this news. I used to watch Danya's videos a lot... RIP

I’ve been using a "no syntax highlight" theme for years. I recommend it. After a while, your brain basically turns into an AST parser and code becomes easier to read.

I've been applying a lot of principles and suggestions from TigerBeetle style lately, mainly in Rust and Go and I can’t recommend it enough.

- single entry point, near-zero deps

- ci locally and tested, one command to runs tests, coverage, lint etc

- property/snapshot/swarm testing, I love writing simulations now and letting the assertions crash

- fast/slow split + everything is deterministic with a seed

- explicit upper bounds + pool of resources. I still dynamically allocate but it makes code simpler to reason about

Thanks to the TB team for the videos and docs they been putting out lately.

Mailing list yes, RSS yes....

Old, boring, simple, works.

No ads.

Worse is better

https://www.dreamsongs.com/RiseOfWorseIsBetter.html

1 Great documentation.

2 Makes you realize how complex async rust is. I can’t believe how many subtle bugs are reported in this report, and how many more are potentially related…

3 I think DST can help spot these cancellation bugs

Honestly, I’d rather just be true to myself.

If you play the game too much, you risk ending up on teams full of “senior software architects” with 20 years of experience in event-driven microservices with TDD + CQRS + AI.

Or these days they’re probably vibe coding and writing RFCs with emojis.

Some thoughts:

Linkedin just deprecated Kafka in favor of Northguard [1]. Curious how this actually compares in practice. Is it worth the effort of building yet another distributed log? Is it worth the effort to mantain Kafka if new alternatives are popping? Jepsen found plenty of issues last year [2], so maybe Linkedin is in the right direction by building from scratch...

Distributed systems are tough to get right, and while it's exciting to see new approaches, the space is definitely getting harder to follow.

[1] https://www.linkedin.com/blog/engineering/infrastructure/int...

[2] https://jepsen.io/analyses/bufstream-0.1.0

Padding in the post refers to memory alignment.

If we had an "array of structs" instead of "struct of arrays" it would be: string(8) + long(8) + int(4) + padding(4) = 24 bytes

Even better, don't discuss them, ever.

I use Apple Notes and Reminders for work.

- Reminders: I just have a few simple lists: TODO, WIP, and BLOCKED (for stuff I'm waiting on others for).

- Notes: I keep daily, weekly, and monthly notes. At the end of each day, I clean up my daily note and move anything important to the weekly one, and then do the same into monthly.

>>This organization corresponds nicely to a idealized human organization of bosses and workers - bosses say what is to be done, workers do stuff. Bosses do quality control and check that things get done, if not they fire people re-organize and tell other people to do the stuff. If they fail (the bosses) they get sacked etc. <<note I said, idealized organization, usually if projects fail the bosses get promoted and given more workers for their next project>>

We miss you Joe :)

It's amazing how coherent Zig's fundamental building blocks are as a programming language, everything fits together like a puzzle.

This post reminds me of one of Andrew's early talks about the type system and the comptime... With the core building blocks, we can achieve elegant solutions without adding unnecessary syntax complexity.