> Python now uses UTF-8 as the default encoding, independent of the system’s environment.

Nice, not specifying the encoding is one of the most common issues I need to point out in code reviews.

encode()/decode() have used UTF-8 as the default since Python 3.2 (soon, 15 years ago). This is about the default encoding for e.g. the "encoding" parameter of open().

You mean the coding= comment? Where are you shipping your code that that was actually a problem? I've never been on a project where we did that, let alone needed it.

The comment you mention applies to source code encoding and it's obsolete for Python 3 since the beginning. This is about something else: https://docs.python.org/3.15/whatsnew/3.15.html#whatsnew315-...

Makes sense, my bad, but even that is something I've never seen. I guess this is mostly a Windows thing? I've luckily never had the misfortune of having to deploy Python code on Windows.

It's a Linux thing too. It bit me in particular when running a script in a container that defaulted to ascii rather than utf-8 locale.

Have you considered reducing review noise by using static analysis?

Yep, ruff has a warning for this exact issue.

Pylint has had it too for at least a decade.

Ruff's rule is derived from Pylint: https://docs.astral.sh/ruff/rules/unspecified-encoding/

There is a sweet spot for the bass. Lower is better for deep bass, but too low and it stops being a recognizable note, and consumer speakers can't reproduce it. This effect exists though I'm not sure if it is the cause of the pattern here.

They accept Monero too

I find them helpful. It happens semi-regularly now that I read something that was upvoted, but after a few sentences I think "hmm, something feels off", and after the first two paragraphs I suspect it's AI slop. Then I go to the comments, and it turns out others noticed too. Sometimes I worry that I'm becoming too paranoid in a world where human-written content feels increasingly rare, and it's good to know it's not me going crazy.

In one recent case (the slop article about adenosine signalling) a commenter had a link to the original paper that the slop was engagement-farming about. I found that comment very helpful.

Dell XPS used to be like this, but unfortunately Dell discontinued them :'(

Agreed. I got further into this one than usual before I grew suspect, but something felt off.

> We did have three bugs that would have been prevented by the borrow checker, but these were caught by our fuzzers and online verification. We run a fuzzing fleet of 1,000 dedicated CPU cores 24/7.

Remember people, 10,000 CPU hours of fuzzing can save you 5ms of borrow checking!

(I’m joking, I’m joking, Zig and Rust are both great languages, fuzzing does more than just borrow checking, and I do think TigerBeetle’s choices make sense, I just couldn’t help noticing the irony of those two sentences.)

It's not that ironic though --- the number of bugs that were squashed fuzzers&asserts but would have dodged the borrow checker is much, much larger.

This is what makes TigerBeetle context somewhat special --- in many scenarios, security provided by memory safety is good enough, and any residual correctness bugs/panics are not a big deal. For us, we need to go extra N miles to catch the rest of the bugs as well, and DST is a much finer net for those fishes (given static allocation & single threaded design).

I don't think needing to go "the extra N miles" is that special. Even if security is the only correctness concern - and in lots of cases it isn't, and (some) bugs are a very big deal - memory safety covers only a small portion of the top weaknesses [1].

Mathematically speaking, any simple (i.e. non-dependent) type system catches 0% of possible bugs :) That's not to say it can't be very useful, but it doesn't save a lot of testing/other assurance methods.

[1]: https://cwe.mitre.org/top25/archive/2024/2024_cwe_top25.html Also, spatial safety is more important for security than temporal safety. As far as language guarantees go, Zig and Rust only differ on #8 on the list.

I wholeheartedly agree, I wrote about this at https://ruudvanasseldonk.com/2025/llm-interactions.

Your post reminded me how I could tell my online friend was pissed just because she typed "okay." or "K." instead of "okay". We could sense our emotional state from texting. One of those friendships you form over text through the internet. I wouldn't recommend forming these too deeply since some in person nuance is lost, we could never transition to real life friends despite living close by. But we could tell what mood we were in just from typing. It was wild.

Sure, a different database schema may have helped, but there are going to be bugs either way. In my view a more productive approach is to think about how to limit the blast radius when things inevitably do go wrong.

FYI in an emergency you can `git push` to and `git pull` from any SSH-capable host without the need to use GitHub.

FYI in an emergency you can SSH to your server and edit files and the DB directly.

Where is your god now, proponents of immutable filesystems?!

I love when people do that because they always say "I will push the fix to git later". They never do and when we deploy a version from git things break. Good times.

I started packing things into docker containers because of that. Makes it a bit more of a hassle to change things in production.

Depends on the org, the big ones I've worked for regular Devs even seniors don't have anything like the level of access to be able to pull a stunt like that.

At the largest place I did have prod creds for everything because sometimes they are necessary and I had the seniority (sometimes you do need them in a "oh crap" scenario).

They where all setup on a second account in my work Mac which had a danger will Robinson wallpaper because I know myself, far far too easy to mentally fat finger when you have two sets of creds.

It's easier, when the deployed instance on the server is also a Git repo, so you can commit the changes there and pull.

FYI in an emergency, you can buy a plane ticket and send someone to access the server directly.

I actually had the privilege of being sent to the server.

Had a coworker have to drive across the country once to hit a power button (many years ago).

Because my suggestion they have a spare ADSL connection for out of channel stuff was an unnecessary expense... Til he broke the firewall knocked a bunch of folks offline across a huge physical site and locked himself out of everything.

The spare line got fitted the next month.

I'm actually getting "ERROR: no healthy upstream" on `git pull`.

They done borked it good.

If your remote is set to a git@github.com remote, it won't work. They're just pointing out that you could use git to set origin/your remote to a different ssh capable server, and push/pull through that.