athoscouto

It was httpx indeed. i had aiohttp in mind because we ended up replacing that particular client with it

yes. remote exec allows me to attach profilers (e.g. memray) directly into a running process. i'm also excited about the upcoming statistical (cpu) profiler from 3.15

We've been impacted by this. I migrated our services to Python 3.14 so we could attach profilers during runtime.

A couple of services looked like they had a memory leak. Memory was continuously increasing over time. Thanks to Python 3.14, we were able to use memray to understand what was going on. Those services were recreating HTTP clients (aiohttp) for every inbound request, and memory allocated by the downstream SSL lib was growing faster than it was being released.

We ended up rolling back to 3.13, which fixed the issue. I'll try again with 3.14.5.

Cursor can do that well too. Their code review feature usually gives a handful of independent feedbacks. I just trigger agents independently for all of those. Other integrations with Linear and Slack are also very handy to getting into this workflow. Seems like the 3.0 version is aiming at getting better at this use case.

2x intelligence != 2x results

most tasks I can do better and faster with composer 2

a fellow engineer reported a bug on a code I had written a few months back. I used his report as prompt for composer 2, gpt-5.4-high and claude-4.6-opus-max-thinking. composer found the issue spot on. gpt found another possible vector a couple of minutes later, but a way less likely one and one that would eventually self heal (thus not actually reproducing what we observed on production). claude had barely started when the other two had finished

also, i don't have a budget per se. but it is expected that i over deliver if i'm over spending

Cursor has been my main AI tool for over a year now.

I've been trying to use Claude Code seriously for over a month, but every time I do it, I get the impression that it would take me less work to do with Cursor.

I'm on the enterprise plan, so it can get pricey. This is why I used to stick mostly to auto mode.

Now Composer 2 has taken over as my default model. It is not as intelligent as OpenAI's or Anthropic's flagship models, but I feel it has as good as or better intuition. With way better pricing. It can get stuck in more complex tasks though.

Being able to get in the loop, stop and instruct or change models makes all the difference. And that is why I've stayed in the editor mode until now. Let's see if 3.0 changes that.

For big codebases pyright can be pretty slow and memory hungry. Even though ty is still a WIP, I'm adopting it at work because of how fast it is and some other goodies (e.g. https://docs.astral.sh/ty/features/type-system/#intersection...)

Nice! Would love to see Azure Document Intelligence on this

I've seen chefs arguing the other way around. You have to apply more pressure when using duller knives, this means less control and less safety.

Agreed that you can have real individual ownership. Not only that, I think that is the only way to be really "productive".

But I think that is beside the point.

Individuals are not fungible, but team members are - or at least can be, depending on how you structure your teams.

And as your org grows, you want predictability on a team level. Skipping a bunch of reasoning steps, this means having somewhat fungible team members, to give you redundancy.

The engineering parallel here is the tradeoff between resilience and efficiency. You can make a system more reliable by adding redundancy. You make a system more efficient by removing redundancy.

Yes. See update 2 FTA for a 2019 study on go concurrency bugs. Most go devs that I know consider using higher level synchronization mechanisms the right way to go (pun intended). sync.WaitGroup and errgroup are two common used options.

I wonder how keys are assigned to rows and how the adjudicator is shared.

The author also mentions a leader adjudicator, which means there is probably some sort of coordination to pick a leader. This raises the question of how a leader is picked, and if leadership changes based on how hot a key is in a given AZ.

This blog series is a great read. Every day Marc drops excellent content and leaves room for questions, which he ends up answering on the following days. Hope more details come next.

Neat design! The coolest insight, IMO:

> We’ve learned from building and operating large-scale systems for nearly two decades that coordination and locking get in the way of scalability, latency, and reliability for systems of all sizes. In fact, avoiding unnecessary coordination is the fundamental enabler for scaling in distributed systems

I hope there is a follow-up since the points the author only glossed over are important to understanding the architecture and trade-offs. I would like to know about the cross-adjudicator coordination protocol and how the journal works.

From the information available, it seems that DSQL should be pretty fast as long as you keep writes local. Once you add active-active replication and start writing to the same key in different regions the coordination costs should slow the system down significantly (or not - but if that is the case I want to know how they managed to do it).

Nice! Two questions for me to follow up later:

- How the OS knows it can clean up an inode after a hard link is deleted? The post mentioned inodes don't see hard links

- What does it mean to have a dead/dangling soft link?

I grew up finding those glasses the most horrible thing. Even though they were always popular, they became fashionable recently when new sizes were introduced.

I somehow started to find they kind of beautiful when I worked at a company that only had pint-sized American glasses at their office. Now most cups in my house have this design. They are dirty cheap and very easy to replace.

People in Brazil do. In fact, 10°C would make most Brazilians complain that the beer is too warm

I haven't consumed audio and video from files for a while now. Streaming has become so convenient (partly because of internet prices and availability) that I don't see myself coming back.

Wow, that brings back memories! foobar2000 was my go to player. I used to spend hours curating all my folders with albums and playlists. Funny how fast I switched to a streaming platform when they became widely available around here.

I've stopped listening for probably a year now. But other than some already mentioned here I'd go with:

- Soft Skills Engineering: very humorous and light take on the people side of SWE

- StaffEng: interviews with engineers with staff+ roles

- Lenny's: if you are into product, growth and startups in general

It was already mentioned by a sibling comment, but podcasts from the Changelog are also very good.

I think the change makes sense, even though I have workloads running on the regions that got the steepest price changes. I'd rather have more granular pricing than a blanket increase. The why now also makes sense - there was a technical limitation that doesn't exist anymore.

I was expecting a larger grace period from announcement to price change though. You got it right when you started charging for stopped volumes - you overcommunicated and gave users estimates for a few months before you started charging. Smoothing the increase over the next 4 months was nice.

A couple of nits as well: - AFAIK prices increased in all but two regions. The announcement could be clearer or more direct regarding this. - The pricing page could have a clearer from/to. I have to click on the example toggle to know how much machines cost before the change.

This is spot on. Having shadowed my share of interviews, I've found that the attitude of the interviewer is the biggest factor in having a good interview experience.

Making sure interviewers show genuine interest, and are open to different candidate background is one of the most difficult things to guarantee when you have many people interviewing.

Are you referring to GDPR? Does it apply to employees too, or only customers?

From the job posting (https://jobs.careers.microsoft.com/global/en/job/1633482/Pri...):

> guiding technical direction, design and implementation of Rust component libraries, SDKs, and contributing to the building of global scale services in Rust.

Maybe the article misquoted it. Maybe the posting was updated after the article. The only time C# shows up is on the required qualifications section.

From the job posting, the role is to work on M365. This means products like Exchange, SharePoint, and Skype. I'll go out on a limb here and say that this new team will work on replacing existing C++ (not C#) code with Rust.

I'm using it on a few workloads running on Fly.io to back it up to S3. It has generally been a good experience.

I suggest taking a look at the replica settings (https://litestream.io/reference/config/#replica-settings) and making sure the default values work for you.

Using both the default retention (24h) and snapshot (24h) intervals will not give you 24h of data history. This happens because any snapshots older than 24h will be deleted. Granted, you'll have another snapshot ready, but it will only contain a short history of your DBs changes.

Also, test restore times. If you need to restore in a hurry, having to download 24h of wal logs can take a while.

I started using it during a time when it was unmaintained (between v0.3.9 and v0.3.10). There were a few bugs I hit, e.g. memory usage spikes. Shout out to hifi, who created patches and was active at the Slack community. I relied on his fork for a while, nice to see it integrated on main.

Wouldn't that require the reader to finish? Making the reader block the checkpoint from wrapping up?

> Checkpointers do not block writers, and writers do not block checkpointers. This means that, even following the checkpoint, the wal file cannot be overwritten or deleted, and so all subsequent transactions must also be appended to the wal file. The work of the checkpointer is not wasted - SQLite remembers which parts of the wal file have already been copied into the db file so that the next checkpoint does not have to do so again

Probably because of this.

> but it does mean that the wal file may grow indefinitely if the checkpointer never gets a chance to finish without a writer appending to the wal file. There are also circumstances in which long-running readers may prevent a checkpointer from checkpointing the entire wal file - also causing the wal file to grow indefinitely in a busy system.

> Wal2 mode does not have this problem. In wal2 mode, wal files do not grow indefinitely even if the checkpointer never has a chance to finish uninterrupted.

I don't get how wal2 fixes the long-running reader problem though. Maybe they were just referring to the former problem?

I've worked on some companies that used Carta. In some of them, I had access to cap table, preferences, total raised debt, etc. In others, I could see only my number of options and their strike price. Is up to the company how much they want to share, Carta can be used on both ways.

The compiler will avoid unnecessary allocations when possible. For more details, see https://go.dev/wiki/LoopvarExperiment#will-the-change-make-p...

Even though each cluster was single AZ the whole system wasn't, so we weren't bound by the capacity of a single AZ.

Most of the situations where we needed to drastically scale up were known ahead of time as well (e.g. campaign from customer), and we would preallocate instances or even more clusters.

I may be forcing my memory, but if I'm not mistaken, our auto scaling was setup in a way that the system could handle sudden load increases of ~50% without noticeable disruption. Spikes bigger than this could lead to increased latency and/or error rate.